4 ms·

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.

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.

kuschku 1y ago
> 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.
- blacklion 1y ago
  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.
  - kuschku 1y ago
    > 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.
  - rcxdude 1y ago
    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 https://github.com/WICG/private-network-access/issues/23
    - blacklion 1y ago
      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.
- blacklion 1y ago
  > 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.
  - kuschku 1y ago
    I agree that the current situation sucks, but that doesn't mean breaking the existing solutions is any better.

kuschku 1y ago

> 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.

blacklion 1y ago
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.
- kuschku 1y ago
  > 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.
- rcxdude 1y ago
  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 https://github.com/WICG/private-network-access/issues/23
  - blacklion 1y ago
    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.
blacklion 1y ago
> 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.
- kuschku 1y ago
  I agree that the current situation sucks, but that doesn't mean breaking the existing solutions is any better.