4 ms·

Chrome will limit access to private networks, citing security reasons

27 points by matbilodeau 5y ago

egberts1 5y ago
Will Not Work in: - segregated Enterprise Network - Home Network with custom subnetting for kid-friendly use. - get blocked from configuring WiFi access points - Unable to distinguish between a client on Internal versus the same client homed in via a tunnel. That’s just the beginning of various use cases. Although, it is trying to shift the onus to the interior server(s) to do the selective acceptance, it is not the way to go for enterprise network.
- egberts1 5y ago
  On the other hand, if such a browser has a button to enable such access of “subnet 192.168.0.0” AND such button is NOT accessible from chrome:// URI AND NOT accessible from JavaScript, then this feature of preflight-ing a request for accessing such private IP subnet MIGHT then becomes a palatable and acceptable approach to mainstreaming this feature. - Somehow, I get the feeling that such a button will be foisted using chrome:// or made accessible using JavaScript … by the Chrome development team.
- xg15 5y ago
  Why wouldn't those work? My understanding is that this will only stop public web pages from making requests to private servers via scripts, iframes, images, etc. It won't prevent you from opening a private web page in a browser. It won't prevent a private web page from talking to another private server either. So there is nothing here keeping you from opening your router's admin page in Chrome - however, it will stop some script at evil.com from spoofing requests of that admin page.
  - egberts1 5y ago
    It is a cat-n-mouse game of incremental ratcheting security coverage. Why waste time with all that; just provide a static button on browser for private uses and be done with.
    - xg15 5y ago
      With due respect, but that sounds like a worse UX than what they are implementing right now. With the current update, 99% of private sites will keep working as before, while some people who fall into the edge cases will have to add a header. With your proposal, you'd have to jump through UI hoops to view any site in a local network, wouldn't you?
      - egberts1 5y ago
        As one who views browser activities through a default-deny prism through some ten hundreds of test-instrumentation data points inserted into and throughout the various major browser engines, this horizon of security theatre is getting cloudier.
ur-whale 5y ago
Curious to know how many people on HN haven't ditched Chrome yet, and more importantly, why?

27 points by matbilodeau 5y ago

Will Not Work in: - segregated Enterprise Network - Home Network with custom subnetting for kid-friendly use. - get blocked from configuring WiFi access points - Unable to distinguish between a client on Internal versus the same client homed in via a tunnel. That’s just the beginning of various use cases. Although, it is trying to shift the onus to the interior server(s) to do the selective acceptance, it is not the way to go for enterprise network.

egberts1 5y ago
On the other hand, if such a browser has a button to enable such access of “subnet 192.168.0.0” AND such button is NOT accessible from chrome:// URI AND NOT accessible from JavaScript, then this feature of preflight-ing a request for accessing such private IP subnet MIGHT then becomes a palatable and acceptable approach to mainstreaming this feature. - Somehow, I get the feeling that such a button will be foisted using chrome:// or made accessible using JavaScript … by the Chrome development team.
xg15 5y ago
Why wouldn't those work? My understanding is that this will only stop public web pages from making requests to private servers via scripts, iframes, images, etc. It won't prevent you from opening a private web page in a browser. It won't prevent a private web page from talking to another private server either. So there is nothing here keeping you from opening your router's admin page in Chrome - however, it will stop some script at evil.com from spoofing requests of that admin page.
- egberts1 5y ago
  It is a cat-n-mouse game of incremental ratcheting security coverage. Why waste time with all that; just provide a static button on browser for private uses and be done with.
  - xg15 5y ago
    With due respect, but that sounds like a worse UX than what they are implementing right now. With the current update, 99% of private sites will keep working as before, while some people who fall into the edge cases will have to add a header. With your proposal, you'd have to jump through UI hoops to view any site in a local network, wouldn't you?
    - egberts1 5y ago
      As one who views browser activities through a default-deny prism through some ten hundreds of test-instrumentation data points inserted into and throughout the various major browser engines, this horizon of security theatre is getting cloudier.

ur-whale 5y ago

Curious to know how many people on HN haven't ditched Chrome yet, and more importantly, why?