4 ms·

> While the specification has some suggestions, I'm not sure that it would allow our specific situation even if we could get all of the people with web servers

> While the specification has some suggestions, I'm not sure that it would allow our specific situation even if we could get all of the people with web servers that are possibly affected by this to make changes to them. Wouldn't this be as simple as an `Access-Control-Allow-Origin: *` (plus all the other junk mentioned in the opt-in section[1] of the draft spec). I'm having a hard time of thinking what wouldn't be workable in the author's situation (assuming he gets all the people with webservers to add headers to them). And yes... understanding CORS should absolutely be a requirement for writing local webservers that people can poke from the public internet; being able to stumble your way through writing a CORS policy is basic web security at this point. [1] https://wicg.github.io/private-network-access/#example-opt-in https://wicg.github.io/private-network-access/#example-opt-i...

EvanAnderson 5y ago
The author is in a large University context where getting everybody who runs all the web servers (various departments, schools, etc) to add headers probably is really difficult (especially when you consider potentially closed-source applications or embedded devices that aren't easily updated).
- jabbany 5y ago
  It's not that hard though given we're working with HTTP... Since they control the network (DNS and all) couldn't they just wrap non-compliant devices behind a forwarding proxy that adds those headers? Like rather than resolve to the device, resolve to a proxy that adds those headers.
  - EvanAnderson 5y ago
    No, it's not particularly hard, but it is complicating the plumbing. We have to make the Internet safe for manufacturers of devices who can't be bothered to incorporate a modicum of security in their devices.
    - jabbany 5y ago
      I do agree with this. It's too much mollycoddling from browsers and in fact dis-incentivizes manufacturers to fix the real CSRF vulnerabilities... Heaven forbid if someone joins your LAN with a device running an old/weird browser that doesn't do this preflighting and your intranet just gets caught with its pants down...

EvanAnderson 5y ago

The author is in a large University context where getting everybody who runs all the web servers (various departments, schools, etc) to add headers probably is really difficult (especially when you consider potentially closed-source applications or embedded devices that aren't easily updated).

jabbany 5y ago
It's not that hard though given we're working with HTTP... Since they control the network (DNS and all) couldn't they just wrap non-compliant devices behind a forwarding proxy that adds those headers? Like rather than resolve to the device, resolve to a proxy that adds those headers.
- EvanAnderson 5y ago
  No, it's not particularly hard, but it is complicating the plumbing. We have to make the Internet safe for manufacturers of devices who can't be bothered to incorporate a modicum of security in their devices.
  - jabbany 5y ago
    I do agree with this. It's too much mollycoddling from browsers and in fact dis-incentivizes manufacturers to fix the real CSRF vulnerabilities... Heaven forbid if someone joins your LAN with a device running an old/weird browser that doesn't do this preflighting and your intranet just gets caught with its pants down...