Clarify when checks are performed

[letitz]

The private network request checks are performed after a connection is obtained. Notably, this is later than when DNS responses are received. Indeed, if a.example resolves to both a public and a private IP address, whether the request will be blocked or not depends on which IP address the browser actually connects to.

We should make this very clear, in both the spec and the explainer, since it is important for site operators to understand.

cc @sleevi

[annevk]

So what I've been wondering about (see also #32) is if we can do this as part of "obtain a connection", before returning a connection to the caller. And returning failure if the check fails. It seems that would be the most principled solution.

[sleevi]

So WebRTC doesn’t use the same “obtain a connection” step, so if the goal is #32 , that may not work sufficiently for that case, although it may for this specific issue.

That said, I’m not sure I follow the “principled” remark. There’s a host of surprising edge cases either way, so I don’t think it necessarily improves predictability for developers. There is something to be said about the simplicity of the current approach, but just needing to call out the logical consequences explicitly for developers who may not have thought through the implications.

[annevk]

It doesn't yet, but it probably should: w3c/webrtc-extensions#73. We keep running into policy mismatches and such.

[letitz]

Above commit adds this warning to the spec. Remaining: add it to the explainer also.