Re: [fetch] Mechanism to indicate "destination context" (#64)

RE referrer: First, consider the mixed content case: Referrer should NEVER be sent for mixed-content subresources. But, with referrer control, we may opt into sending Referrer for HTTP->HTTPS navigations. More generally, pages should be able to control referrer separately for subresource and navigation loads; see https://briansmith.org/referrer-01 for what I'm shooting for.

RE predicting type: I think we should be able to initialize appropriate request headers without predicting the type. For example, preload for foo.png where foo.png may be WebP or PNG depending on the user-agent. I guess your thinking is that you can say type=image/png and it will work out OK even if it is actually WebP, however that seems quite hacky. The important thing is the intended context, in this case ```<img src>```, not the type of the response, but ```<link type>``` is about the type of the response. 

Re CSP: If people don't define CSP controls when they add new features then that effectively breaks CSP every time such a new feature is added. For example, it is should be possible to use CSP to prevent any accidental/automatic HTTPS->HTTP leakage using ```default-src 'self' https wss```. This only works if anything that can (automatically) load something over non-secure HTTP is controlled by CSP, and this is an important use case for CSP. Adding features and then figuring out later how CSP affects them just doesn't work for that use case.

In particular, here's a very reasonable use case: Using CSP on my HTTPS page, I want to ensure that I only prefetch/prerender linked HTTPS pages, to minimize the infoleak of the contents of the links on my HTTPS page. I understand that Google SERPs don't seem to want to do this, but I think a lot of HTTPS sites will want to do this.

I understand why it is tempting to overload ```type``` instead of defining a new attribute and new flags. But, it seems like whenever we do such overloading, we end up creating future problems for ourselves. The things I mentioned above where overloading ```type``` for (partially) orthogonal purposes causes problems are just the examples I could think of off the top of my head. That means there are probably more and that there will probably be more in the future. I understand the desire to keep things simple, but it seems like overloading ```type``` is at best just deferring complexity for later.

Anyway, I'm surprised by the "fetch could bypass connect-src" argument. The browser knows (and could keep track of) whether the fetch was triggered by a ```<link>``` or by a JS call to ```window.fetch()``` and/or whether ```window.fetch()``` was called in a service worker or outside of a service worker. In any use of service workers I can think of, I want to have connect-src work differently for ```fetch()``` within my service worker (e.g. connect-src `self` https:```) vs. ```fetch()``` outside my service worker (e.g. ```connect-src `none````). It seems like the fact that we haven't figured out how that would work is starting to cause lots of things to go wrong. Further, I think a lot of sites would like to have a CSP directive to control whether a service worker can ever be registered, because service workers are very special (notably higher risk) as far as security is concerned. I don't mean to be creating stop energy, but it's hard to see how this issue can be properly resolved wi
 thout having first having at least a general plan for resolving the CSP-related stuff.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/64#issuecomment-120204839