It would be really annoying if this use case was made into an unreasonable hassle or killed entirely. (Alternatively, browser developers could've offered a real alternative, but it's a bit late for that now.)
Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests.
And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-origin request, so should likewise be allowed?
It seems like you're thinking of a specific application, or at least use-case. Can you elaborate?
Once you're launching an application, it seems like the application can negotiate with the external site directly if it wants.
Sure you can make a fully cloud-reliant PW manager, which has to have your key stored in the browser and fetch your vault from the server, but a lot of us like having that information never have to leave our computers.
This allows you to use a single centrally hosted website as user interface, without the control traffic leaving your network. e.g. Plex uses this.
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.
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.
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.
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.
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.
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.
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
> 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.
> 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).
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~~~)...
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.
if that software runs with a pull approach, instead of a push one, the server becomes unnecessary
bonus: then you won't have websites grossly probing local networks that aren't theirs (ew)
Note: this is why the viewers for these tools will spin up a local web server.
With local LLMs and AI it is now common to have different servers for different tasks (LLM, TTS, ASR, etc.) running together where they need to communicate to be able to create services like local assistants. I don't want to have to jump through hoops of running these through SSL (including getting a verified self-signed cert.), etc. just to be able to run a local web service.
For instance, my interaction with local LLMs involves 0 web browsers, and there's no reason facebook.com needs to make calls to my locally-running LLM.
Running HTML/XML files in the browser should be easier, but at the moment it already has the issues you speak of. It might make sense, IMO, for browsers to allow requests to localhost from websites also running on localhost.