Consider allowing private -> local fetches

[letitz]

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

See also #91 (comment) 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]

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]

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]

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]

Fair enough!

[letitz]

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]

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.