I don't think this proposal will stop you visiting the management UI for devices like switches and NASes on the local network. You'll be able to visit http://192.168.0.1 and it'll work just fine?
This is just about blocking cross-origin requests from other websites. I probably don't want every ad network iframe being able to talk to my router's admin UI.
That's not what I'm talking about.
A common example is this:
1. I visit ui.manufacturer.tld
2. I click "add device" and enter 192.168.0.230, repeating this for my other local devices.
3. The website ui.manufacturer.tld now shows me a dashboard with aggregate metrics from all my switches and routers, which it collects by fetch(...) ing data from all of them.
The manufacturers site is just a static page. It stores the list of devices and credentials to connect to them in localStorage.
None of the data ever leaves my network, but I can just bookmark ui.manufacturer.tld and control all of my devices at once.
This is a relatively neat approach providing the same comfort as cloud control, without the privacy nightmare.
If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally.
It has a multitude of benefits comparing opening it from vendor site each time:
1) It works offline.
2) It works if vendor site is down.
3) It works if vendor restrict access to it due to acquisition, making it subscription-based, discontinuation of feature "because fuck you".
4) It works if vendor goes out of business or pivot to something else.
5) It still works with YOUR devices if vendor decides to drop support for old ones.
6) It still works with YOUR versions of firmwares if vendor decides to push new ones, with features which are user-hostile (I'm looking at you, BambuLab).
7) It cannot be compromised, as copy on vendor site can be If your system is compromised, you have bigger problems than forged UI for devices. Even best of vendors have data breaches this days.
8) It cannot upload your data if vendor goes rogue.
Downsides? If you really need to update it, you need to re-download it manually. Not a big hassle, IMHO.
> If it is truly static site/page, download it and open from local disk. And nudge vendor to release it as archive which can be downloaded and unpacked locally.
Depending on the browser, file:/// is severely limited in what CORS requests are allowed.
And then there's products like Plex, where it's not a static site, but you still want a central dashboard that connects to your local Plex server directly via CORS.
Why local Plex which you need to install & run (it is already Server) cannot provide its own UI to browser, without 3rd party sites? It is absurd design, IMHO. I'll never allow this in my network. It looks security nightmare. Today it shows me dashboard (of what? Several my Plex servers?), tomorrow it is forced to report pirated movies to police. No, thanx.
> of what? Several my Plex servers?
People commonly use this to browse the collections of their own servers, and the servers of their friends, in a unified interface.
Media from friends is accessed externally, media from your own server is accessed locally for better performance.
HTTPS, basically. I've gone around and around in circles on this for a device I work on. You'd like to present an HTTPS web UI, because a) you'd like encryption between the UI and the device, and b) browsers lock down a lot of APIs, sometimes arbitrarily, behind being in a 'secure context' (ironically, including the cryptography APIs!). But your device doesn't control it's IP address or hostname, and may not even have access to the internet, so there's no way for it to have a proper HTTPS certificate, and a self-signed certificate will create all kinds of scary warnings in the browser (which HTTP will not, ironically).
So manufacturers create all kinds of crazy workarounds, like plex's, to be able to present an HTTPS web page that is easily accessible and can just talk to the device. (Except it's still not that simple, because you can't easily make an HTTP request from an HTTPS context, so plex also jumps through a bunch of hoops to co-ordinate some HTTPS certificate for the local device, which requires an internet connection).
It's a complete mess, and browsers really seem to be keen on blocking any 'let HTTPS work for local devices' solution, even if it were just a simple upgrade to the status quo that would otherwise just be treated like HTTP. Nor will they stop putting useful APIs behind a 'secure context' like an HTTPS certificate implies any level of trust except that a page is associated with a given domain name.
(Someone at plex seems to have finally gotten through to some of the devs at Chrome, and AFAIK there is now a somewhat reasonable flow that would allow e.g. a progressive webapp to request access to a local device and communicate with it without an HTTPS certificate, which is something, but still way to just host the damn UI on the device without limiting the functionality! And it's chrome-only, maybe still in preview? Haven't gotten around to trying to implement it yet)
See this long, painful, multi-year discussion on the topic: https://github.com/WICG/private-network-access/issues/23
It is all very wired.
> a) you'd like encryption between the UI and the device
No, I don't. It is on my local network. If device has public IP and I want to browse my collection when I'm out of my local network, then I do, but then Let's encrypt solved this problem many years ago (10 years!). If device doesn't have public IP but I punch hole in my NAT or install reverse proxy on gateway, then I'm tech-savvy enough to obtain Let's Encrypt cert for it, too.
> b) browsers lock down a lot of APIs, sometimes arbitrarily
Why does GUI which is served from server co-hosted with mediaserver needs any special APIs at all? It can generate all content on server side and basic JS is enough to add visual effects for smooth scrolling, drop-down menus, etc.
Its all look over-engineered in the sake of what? Of imitating desktop app in browser? Looks like it creates more problems than writing damn native desktop app. In QT, for example, which will be not-so-native (but more native than any site or Electron) but work on all 3 major OSes and *BSD from single sources.
Even on a local network, you should probably not be sending e.g. passwords around in plaintext. Let's encrypt is a solution for someone who's tech-savvy enoug to set it up, not the average user.
> Its all look over-engineered in the sake of what? Of imitating desktop app in browser?
Pretty much, yeah. And not just desktop app, but mobile app as well. The overhead of supporting multiple platforms, especially across a broad range of devices, is substantial. Wep applications sidestep a lot of that and can give you a polished UX across basically every device, especially e.g. around the installation process (because there doesn't need to be one).
> Even on a local network, you should probably not be sending e.g. passwords around in plaintext.
Why not? There is only me, my wife and my cat. Guests has separate network, of course :) If my network is compromised I have much bigger problems than password to video collection.
> Let's encrypt is a solution for someone who's tech-savvy enoug to set it up, not the average user.
caddy (web server) can provision Let's Encrypt cert transparently for user. I don't say Plex user should install caddy, but Plex server can have same mechanism built-in. If user is tech-savvy enough to install Plex.
> And not just desktop app, but mobile app as well
To be good they should have completely different structure and screen layouts for Mobile and Desktop no matter which "toolkit" is used, though — different screen sizes, different screen orientation, different input devices (touch and mouse are VERY different in UX and decent Desktop UI needs good keyboard controls, OH WAI~~~)...
> Depending on the browser, file:/// is severely limited in what CORS requests are allowed.
And it is strange to me too. Local (on-disk) site is like local Electron app without bundling Chrome inside. Why it should be restricted when Electron app can do everything? It looks illogical.
I agree that the current situation sucks, but that doesn't mean breaking the existing solutions is any better.
That absolutely is a privacy nightmare.
How so? It's certainly better than sending all that traffic through the cloud.
While I certainly prefer stuff I can just self-host, compared to the modern cloud-only reality with WebUSB and stuff, this is a relatively clean solution.