4 ms·

Fuck this. It increases the complexity of browsers and servers and erects yet another burden for makers. And for what? So orgs with broken infrastructure (an

Fuck this. It increases the complexity of browsers and servers and erects yet another burden for makers. And for what? So orgs with broken infrastructure (and budgets for running it) and device manufacturers (with budgets of their own) can keep up their garbage practices instead of fixing them? And they can push their costs onto a deep-pocketed company like Google who's willing to subsidize them? Here's to hoping that WebKit and Mozilla say "No."

cratermoon 6y ago
It's probably wrong to consider any 'private' network to be secure any more. With zero-trust principles in mind, you wouldn't necessarily believe every device or system on your network is trusted, so you ensure that what is able to send and receive traffic on your network has other mechanisms in place for trust and authenticity.
- xg15 6y ago
  I mean, you have to hand it to them that the point of this change is to strengthen the security of "everything in LAN is trusted" networks: Using the browser as a gateway to access internal services is one of the most important ways to break into local networks.
duskwuff 6y ago
Huh? I think you may have a very incorrect idea about who is being burdened here. A major effect of these changes is to make it simpler for anyone ("makers" included) to securely implement devices which expose web services, by making web browsers refuse to allow external web sites to send arbitrary requests to those devices. Most network devices have no need to receive such requests. No action is necessary on their part; these changes will make those devices stop receiving those requests. The few network devices that do need to receive those requests can opt in to receiving them by responding to a CORS probe (an OPTIONS HTTP request) with a specific HTTP header. This is not complicated to implement. Web browsers already implement complex CORS policies. Adding this is not a huge burden upon them, and may actually obviate the need for other more complex defenses.
- janci 6y ago
  The whole DNS rebinding thing makes this very complicated to implement correctly in browsers. (I.e. the public/private status of a domain name can change in time under attacker control)
- pwdisswordfish4 6y ago
  > I think you may have a very incorrect idea about who is being burdened here Convenient stance, but no. It's possible to have a decent grasp on the proposal (thanks) and to mean what was written in the comment you're responding to above. Your response belongs to a class of responses that can be called "well, you can just…" responses. The problem with these is that they tend to diminish what the just part is out of some lack of awareness and failure to truly take stock. (HN's infamous Dropbox comment can be considered an instance of a "well, you can just…" response.) And in your case, apparent unawareness that the response can be just as easily applied in the opposite direction—orgs with staff setting up insecure private networks can just do things the right way; device manufacturers who have software engineers but cheap out and take shortcuts can just stop doing that and commence with doing the thing they're getting paid for. And it turns out those justs make a lot more sense than the one that says ordinary people should deal with an even more complicated and hostile landscape that raises the barrier to entry for pulling off small accomplishments _without_ funding—just because some folks wanted to be able to offload their job duties. And there was no suggestion that implementing this is a "huge burden" for _existing_ browser vendors. The fact that you seque there from a point about how browsers "already implement complex CORS policies" shows your failure to grasp the point that was being made.

cratermoon 6y ago

It's probably wrong to consider any 'private' network to be secure any more. With zero-trust principles in mind, you wouldn't necessarily believe every device or system on your network is trusted, so you ensure that what is able to send and receive traffic on your network has other mechanisms in place for trust and authenticity.

xg15 6y ago
I mean, you have to hand it to them that the point of this change is to strengthen the security of "everything in LAN is trusted" networks: Using the browser as a gateway to access internal services is one of the most important ways to break into local networks.

duskwuff 6y ago

Huh? I think you may have a very incorrect idea about who is being burdened here. A major effect of these changes is to make it simpler for anyone ("makers" included) to securely implement devices which expose web services, by making web browsers refuse to allow external web sites to send arbitrary requests to those devices. Most network devices have no need to receive such requests. No action is necessary on their part; these changes will make those devices stop receiving those requests. The few network devices that do need to receive those requests can opt in to receiving them by responding to a CORS probe (an OPTIONS HTTP request) with a specific HTTP header. This is not complicated to implement. Web browsers already implement complex CORS policies. Adding this is not a huge burden upon them, and may actually obviate the need for other more complex defenses.

janci 6y ago
The whole DNS rebinding thing makes this very complicated to implement correctly in browsers. (I.e. the public/private status of a domain name can change in time under attacker control)
pwdisswordfish4 6y ago
> I think you may have a very incorrect idea about who is being burdened here Convenient stance, but no. It's possible to have a decent grasp on the proposal (thanks) and to mean what was written in the comment you're responding to above. Your response belongs to a class of responses that can be called "well, you can just…" responses. The problem with these is that they tend to diminish what the just part is out of some lack of awareness and failure to truly take stock. (HN's infamous Dropbox comment can be considered an instance of a "well, you can just…" response.) And in your case, apparent unawareness that the response can be just as easily applied in the opposite direction—orgs with staff setting up insecure private networks can just do things the right way; device manufacturers who have software engineers but cheap out and take shortcuts can just stop doing that and commence with doing the thing they're getting paid for. And it turns out those justs make a lot more sense than the one that says ordinary people should deal with an even more complicated and hostile landscape that raises the barrier to entry for pulling off small accomplishments _without_ funding—just because some folks wanted to be able to offload their job duties. And there was no suggestion that implementing this is a "huge burden" for _existing_ browser vendors. The fact that you seque there from a point about how browsers "already implement complex CORS policies" shows your failure to grasp the point that was being made.