search

WICG / private-network-access

https://wicg.github.io/private-network-access/
Other
52 stars 21 forks source link

Consider allowing private -> local fetches #96

Closed letitz closed 1 year ago

letitz commented 1 year ago

At least at first, because it's much easier to deploy without breaking the web: https://crbug.com/1234044.

See also https://github.com/WICG/private-network-access/issues/91#issuecomment-1378461533 where this was first mentioned.

We can keep the local/private/public distinction, but simply define a private network request as public -> non-public only.

If we do so, we should open a new issue on the backlog to block these requests again. It would be good to do, if we have the time.

mikewest commented 1 year ago

If we drop it from the intial pass, I'd like for it to move to a "security considerations" section noting the remaining risk, and suggesting that browsers may/should want to close that gap in the future.

letitz commented 1 year ago

Good idea! Mentioning it in the spec means we can avoid having another issue laying around.

I was thinking of saying that private -> local being blocked could be up to the user agent, but if no user agent does that, it's maybe misleading?

mikewest commented 1 year ago

I'd think of this more like Cookie's documentation of known flaws/gaps (e.g. https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#section-8). "Hey, this is a thing that we know about, but haven't addressed yet. User agents should feel free to come up with clever ways of addressing it."

letitz commented 1 year ago

Fair enough!

letitz commented 1 year ago

In the end, I'm not sure it makes sense to remove from the spec right now. In Chromium, local -> loopback (fka private -> local) fetches from non-secure contexts were exempted from deprecation due to rollout difficulties, but they are subject to preflights when sent from secure contexts. It seems better to just have a Chromium bug to track eventually implementing the spec than amending the spec to reflect Chromium's current limitation?

annevk commented 1 year ago

I think adding a warning in the specification that points to this issue reminding people about potential deployment difficulties might be good, but overall that sounds reasonable.