Describe a possible ISSUE, and an additional security consideration.

[noncombatant]

Some typos fixed.

[mikewest]

In the current algorithm, that would depend upon the state of the Document or Worker which initiated the request. That is, if https://public.example.com/ loads the printer's script via <script src="https://printer.local/script.js"> and that script initiates a request to https://whatever.local/, the request would be CORSified.

If, on the other hand, the user navigates to https://printer.local/ directly (or that page allows itself to be framed or loaded as a worker), then the request to https://whatever.local/ would work the way it does today by requiring a preflight for unsafe requests, and not requiring a preflight for "safe" requests.

It's not clear that we could change the behavior of intranets in general to require CORS when talking to other intranet servers. That seems like a bit much to ask for.

[mikewest]

Thanks! Happy to pull this in as-is, but it's probably worth talking a bit about the issue first. The question isn't clear to me, nor is what you'd like the answer to be. :)

[noncombatant]

I'd suggest pulling it as-is, so we can all mull it over.

Basically, perhaps we shouldn't think of it is as "a private service should opt in to being contacted by the public", but rather, "a private service should opt into being contacted by anyone other than itself and the 1st party UA".

I am not sure what the answer is, but I do lean toward changing the proposal so that private services must always opt in to being contacted by anyone other than themselves and the 1st party UA.

[mikewest]

Ok. Merged. I'll poke at the issue text a bit to clarify what I think you're getting at. Thanks!

[thw0rted]

The current version of the document still includes an open question (marked "Issue 2") about whether "private to private" requests should always be opt-in, with a link here. I see that this PR hasn't had activity in 5 years, but I don't see any other open issues about it, so I'd like to contribute a thought, and it can be moved to a separate issue if need be.

I think there is more cost than benefit here. Yes, you should be concerned about requests from evil-printer to innocent-router, but the far more common case will be requests from old-toaster:443 to old-toaster:12345. Plenty of devices host additional services on nonstandard ports, and an opt-in model for cross-origin requests is going to break things. Vendors will be on the hook to update the service to add the ACA-Allow-Private header, but what incentive do they have to do that for last year's model? Users will keep devices on their network long after they stop receiving updates, so the end result is going to be a bunch of angry users complaining that Browser N+1 "broke" their toaster's web control panel.

If you're going to think about requiring opt-in, it would have to be on a long time horizon, like the rollout of SameSite enforcement for cookies.

[letitz]

That's fair, thanks for chiming in!

I agree that breaking public websites is easier than breaking IoT devices and the like, for the very reasons you give.

I'm keeping this issue here in our back pocket because I'd be interested in tackling it later. It is a strict add-on to the current proposal, so there should be no wasted work if we first break public -> private and then concern ourselves with private -> private.

[letitz]

I've filed issue #39 to continue the discussion on this topic. This PR is not the best forum.