Hacker News Reader

Comment by mentat | Hacker News Reader

How is the browser supposed to reason about "local"?

> How is the browser supposed to reason about "local"?

That isn't even the issue. It's that there is nothing inherently wrong or unusual with mixing local and internet requests.

Look at IFPS -- it runs a webserver on localhost which you can request content from by using content hashes. There is nothing wrong with a website on the internet which anticipates that you to have IFPS installed and uses it to request page elements. It can even use javascript to detect that you have it and use a different (e.g. slower or more expensive) source for the content if you don't, or show a message explaining how to install it.

Or you have a company with some internal servers where some of them have public addresses (or public IPv6 addresses) while some don't, but they arbitrarily access resources on the others because they're all managed by the same people.

This isn't a browser problem. Browsers are supposed to work this way.

Yes, exactly. This should be a top-level comment. The uninformed delirium over intentional and useful browser features moves us in a slow crawl towards a sad husk of what the Web used to be in the name of 'security'.

The web has changed. It has become a vastly more hostile environment. In my view, the appropriate way of acknowledging this change is to prioritize security over features. Whether a feature is useful or not is no longer the primary consideration.

A denial of service doesn't improve security. All you do is get users to mash whatever knobs they can find until it starts working again regardless of the implications, or disable updates so they can keep using the old version that works instead of the new version that doesn't.

You need to fix the things that are broken instead of breaking the things that are working.

How does prioritizing security equate to "denial of service"? A securely designed system can be user friendly.

There are 3 well defined private network ranges, 1 loopback range and a few other random things. It's not silly to ask whether an address outside of them should be able to initiate connections to them. (In the context of a browser running on that network that is)

So, when a company decides to run internal services for its non-technical employees on its internal network, now they have to make sure that all the user’s devices on the LAN (including BYOD devices) are configured properly?

Cool, so make it drivable via policy files like e.g. client cert pinning in Chrome. Industry has solved these problems, making excuses for fixing it is not good at this point.

I don't see how that use case is affected. Could you post a specific example you think would be broken?

I would suggest that all requests must require a DNS lookup. No requests directly to IP addresses, full stop.

This prevents LAN enumeration from random websites. This is not a big deal for most home networks, but I shudder to think of the damage one could do in a standard corporate network.

It doesn't help with routers with well-known config URLs.

Yes, I realize that this will break a bunch of stuff.

(Edit: OK, DNS rebinding mostly breaks this proposal. Let me think about this harder.)

How would this help at all? You could just have your domain return LAN various LAN ips for different domains... there are already a ton of domains that return 127.0.0.1 for you. It would be trivial to make your own to do every possible IP.... something like 127.0.0.1.myfakedomain.com, where it dynamically extracts the IP and returns it.

https://en.wikipedia.org/wiki/Private_network

What if your DHCP doesn't give you a private IP address? When I was at the University of Michigan, my personal laptop always received a public IP address. Or if I'm in a pure-IPv6 setup, using prefix delegation/SLAAC? This problem is a lot harder than "just use the RFC1918 list of reserved private IP ranges".

Fixing the issue for people on properly configured networks is already an improvement worth doing.

The UMich network isn't "improperly configured". NAT-less networks have been around since the beginning of the Internet, and IPv6 networks don't use NAT (unless they're accessing IPv4-only targets, but that's CGNAT). I think you'll find a great deal of university/research settings have networks configured without NAT. If you can come up with a solution that works in all cases, I'd love to hear it.

127.0.0.1/localhost are kind of obvious no?

Bogons?

Reply on news.ycombinator.com