41–50 of 392 posts
Earlier quoted context omitted.
I have this today from macOS. To me it feels more appropriate to have the OS attempt to secure running applications.
No you don’t - you get a single permission prompt for the entire browser. You definitely don’t get any permission-site permission options from the OS
Earlier quoted context omitted.
Can you define "local network"? Probably not. Most large enterprises own publicly-routable IP space for internal use. Internal doesn't mean 192.168.0.0/24. foo.corp.example.com could resolve to 9.10.11.12 and still be local. What about IPv6? It's a nonsense argument fraught with corner cases.
> Can you define "local network"? Sure - a destination is "local" if your machine has a route to that IP which isn't via a gateway. If your network is large enough that it consists of multiple routed network segments, and you don't have any ACLs between those segments, then yeah, you won't be fully protected by this browser feature. But you aren't protected right now either, so nothing's getting worse , it's just not…
Fantastic. Well, Google doesn't agree
The proposal defines it along RFC1918 address space boundaries. The spitballing back and forth in the GitHub issues about which imaginary TLDs they will or won't also consider "local" is absolutely horrifying.
Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost. 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?
I like this on the first glance. The idea of a random website probing arbitrary local IPs (or any IPs for that matter) with HTTP requests is insane. I wouldn't care if it breaks some enterprise apps or integrations - enterprises could reenable this "feature" via management tools, normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny".
> normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny". MacOS currently does this (per app, not per site) & most users just click yes without a second thought. Doing it per site might create a little more apprehension, but I imagine not much.
I like this on the first glance. The idea of a random website probing arbitrary local IPs (or any IPs for that matter) with HTTP requests is insane. I wouldn't care if it breaks some enterprise apps or integrations - enterprises could reenable this "feature" via management tools, normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny".
> normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny". MacOS currently does this (per app, not per site) & most users just click yes without a second thought. Doing it per site might create a little more apprehension, but I imagine not much.
Besides that, approximately zero laypersons will have even the slightest clue what this permission means, the risks involved, or why they might want to prevent it. All they know is that the website they want is not working, and the website tells them to enable this or that permission. They will all blindly enable it every single time.
Earlier quoted context omitted.
> normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny". MacOS currently does this (per app, not per site) & most users just click yes without a second thought. Doing it per site might create a little more apprehension, but I imagine not much.
problem is: without allowing it webUIs like synology won't work, since they require your browser to connect to the local network... as it is, it's not great
I guess if the permissions dialog is sensibly worded then the user will allow it.
I think this is probably a sensible proposal but I'm sure it will break stuff people are relying on.
Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost. 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.)
Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? 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-or…
While this will help to block many websites that have no business making local connections at all, it's still very coarse-grained. Most websites that need this permission only need to access one local server. Granting them access to everything violates the principle of least privilege. Most users don't know what's running on localhost or on their local network, so they won't understand the risk.
I wish there were an API to build such a firewall, e.g. as a part of a browser extension, but also a simple default UI allowing to give access to a particular machine (e.g. router), to the LAN, to a VPN, based on the routing table, or to "private networks" in general, in the sense Windows ascribes to that. Also access to localhost separately. The site could ask one of these categories explicitly.