I was thinking this would be setting referrer to null, but I guess that would conflicts with the idea of getting it of the client instead.

Maybe referrer should be "none", "client", or a URL?

Since the navigate algorithm sets referrer it should be able to keep track of that state for the browsing context it is about to create. Not sure why we need to keep track of that state in the "network" layer.

I think I'd suggest that `noreferrer` override the default referrer policy of an environment. That is, `noreferrer` means an empty referrer header, even in the context of a page that set `<meta name="referrer" value="always">`.

Whether or not we need to push this data into Fetch depends to some extent on whether or not ServiceWorkers should be able to force this behavior for links that didn't opt-in in the markup.

(In reply to Mike West from comment #2)
> I think I'd suggest that `noreferrer` override the default referrer policy
> of an environment. That is, `noreferrer` means an empty referrer header,
> even in the context of a page that set `<meta name="referrer"
> value="always">`.

If referrer is set to "none" we can just skip that policy check. Seems fine.


> Whether or not we need to push this data into Fetch depends to some extent
> on whether or not ServiceWorkers should be able to force this behavior for
> links that didn't opt-in in the markup.

Currently the Request API does not provide referrer control (SW can still use default() to get the behavior). Giving control over that and opener (maybe separately) seems interesting. Maybe v2 features (e.g. once we have something shipping)?

(In reply to Anne from comment #3)
> (In reply to Mike West from comment #2)
> > I think I'd suggest that `noreferrer` override the default referrer policy
> > of an environment. That is, `noreferrer` means an empty referrer header,
> > even in the context of a page that set `<meta name="referrer"
> > value="always">`.
> 
> If referrer is set to "none" we can just skip that policy check. Seems fine.

Maybe I'm misunderstanding what the referrer property is supposed to be. I understood it to be either a global environment or null. Are you suggesting something else, or that we interpret "null" to mean "noreferrer"?

> Currently the Request API does not provide referrer control (SW can still
> use default() to get the behavior). Giving control over that and opener
> (maybe separately) seems interesting. Maybe v2 features (e.g. once we have
> something shipping)?

I guess I'm curious about the interaction between the page's specified referrer policy (you'll have a doc to review in a day or three, until then just pretend that the <meta referrer> wiki page is more complete and integrated with Fetch) and the work that a SW does on its behalf.

Agree that punting the specific 'noreferrer' behavior until later is perfectly reasonable.

I gave a new idea of what referrer could be in comment 1.

That is, specifications set request's referrer to "none", "client", or a URL. It defaults to "client" if it is not set.

Then in Fetch's concept-fetch:

* If request's referrer is "client", I extract a URL from request's client and set request's referrer to that value.
* If request's referrer is not "none", pass it to "referrer policy spec" for adjustment.

Then, going forward, in service workers a Request object could have a referrer property that reflects the adjusted URL (or simply returns the empty string). And we can support a omitReferrer boolean member in RequestInit to achieve request's referrer being "none" for fetch().

(In reply to Anne from comment #5)
> I gave a new idea of what referrer could be in comment 1.
> 
> That is, specifications set request's referrer to "none", "client", or a
> URL. It defaults to "client" if it is not set.
> 
> Then in Fetch's concept-fetch:
> 
> * If request's referrer is "client", I extract a URL from request's client
> and set request's referrer to that value.
> * If request's referrer is not "none", pass it to "referrer policy spec" for
> adjustment.
> 
> Then, going forward, in service workers a Request object could have a
> referrer property that reflects the adjusted URL (or simply returns the
> empty string). And we can support a omitReferrer boolean member in
> RequestInit to achieve request's referrer being "none" for fetch().

Got it.

I think this makes sense, and I'll update the referrer spec accordingly. Should I send a pull request for Fetch, or would you like to take care of that side yourself?

https://github.com/whatwg/fetch/commit/8ab38bf62ace6c221c544add7cc188c799d6acc7

I still need to make it actually set the Referer header on the network. That's for later.

So, what's the right split between referrerpolicy and Fetch?

I wrote http://w3c.github.io/webappsec/specs/referrer-policy/#set-request-referrer to actually set the header (and do the right stripping of values and etc). It seems like that logic should be in referrerpolicy, but it's not clear to me what you'd like to be invoking and where.

http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0154.html has my proposal. I don't want to set the header before this goes to the network or cache. That makes things harder with respect to CORS header checks / CORS cache header checks and whether service workers can influence it or not.

The second part of comment 7 happened as part of

https://github.com/whatwg/fetch/commit/c3f956ac1b4062b7202c066a36464cddc4370600

and was refined in

https://github.com/whatwg/fetch/commit/b473988e658476f4e439b2be614b2d7580f4a34c