Allow control over dns-prefetch and preconnect

[annevk]

Raising this separately from #107 as that is mostly focused on the other types (which go through Fetch).

See @samuelhorwitz's comment at whatwg/fetch#658 (comment).

If we do this it might make CSP a natural place to also define the X-DNS-Prefetch-Control header (see w3c/resource-hints#75); again, in cooperation with HTML most likely.

[mikewest]

Talked with @yoavweiss about this today. I think what we agreed on was something like the following:

1. Add something to CSP that answers the question "Would a request to |url| be allowed by fetch directives?". That algorithm would walk through all the fetch directives specified in the each active policies, and return true if a request to |url| would be allowed by any of them. e.g. default-src https://site.example; img-src https://images.cdn would return true for https://site.example and https://images.cdn.

2. Hook into this algorithm from Fetch's Obtain a connection (which I'm going to charitably assume is part of the preconnect flow).

3. Figure out some way of establishing this algorithm's control over dns-prefetch.

4. Call it a day.

WDYT?

[mikewest]

/cc @andypaicu, @dveditz, @ckerschb

[annevk]

Sounds good to me. (The only thing that's still unclear to me is how WebRTC's algorithms tie into all this, but I guess we'll track that as part of #92.)

[mikewest]

Sounds good to me. (The only thing that's still unclear to me is how WebRTC's algorithms tie into all this, but I guess we'll track that as part of #92.)

Short answer: connect-src seems reasonable. Long answer: I'll go look at that bug.

[ianopolous]

Hi folks, I just wanted to ask if there are any plans to progress this?

This is super important for our use case - being able to stop data exfiltration from a sandbox that is used to render private data.

[yoavweiss]

/cc @noamr - as it's related to the resource hints processing model work

[noamr]

I don't think connect-src is right here. You could have an images CDN that you want to download images from, and obtain an early connection to that domain for performance. image-src should suffice in that case.

I suggest that if there is any directive that allows fetching from a particular origin, then dns-prefetch and preconnect should be allowed. So if an origin is allowed to be accessed for images or scripts or what not, it should also be allowed to be accessed via preconnecting or DNS prefetching to speed things up.

btw I think this should also be the case for prefetch but I'm not keen on reopening that.

[noamr]

I added some thoughts in #542.
I think that if we don't want to relax restrictions like I'm proposing, we should go with prefetch-src for dns-prefetch and preconnect rather than connect-src.

[mikewest]

@noamr: connect-src was only my suggestion for WebRTC. I think we're on the same page with dns-prefetch and preconnect, both of which I'd suggested should look at all the fetch directives (see #282 (comment) above). That hasn't been a high-enough priority for anyone to actually implement, but I still think it's a reasonable approach to the problem.

[noamr]

@noamr: connect-src was only my suggestion for WebRTC. I think we're on the same page with dns-prefetch and preconnect, both of which I'd suggested should look at all the fetch directives (see #282 (comment) above). That hasn't been a high-enough priority for anyone to actually implement, but I still think it's a reasonable approach to the problem.

Oh, I guess I missed that and ended up suggesting the same thing.
btw I think the same algorithm should apply to prefetch and not just to preconnect, as prefetching has no observable effect on the document.