Referrer attribute and Fetch integration

[annevk]

As I said on blink-dev I'm not convinced this attribute with only a limited set of values is the way to go. We need to be able to set arbitrary (same-origin) URLs if we want referrers to remain a useful feature in the world of service workers.

E.g. if you have a worker at URL A and a service worker at URL B, the service worker needs to be able to override the referrer to be A for its outgoing requests as otherwise when a site migrates to service workers all its referrers will be B, which would be different from what it had before.

[jeisinger]

I think we should remove it from the draft, @mikewest wdyt

[mikewest]

Sure. No one's implemented it, the only partial implementation had negative feedback on blink-dev@, etc. I think it's fine to drop the feature from the current spec, and come up with something that suits the actual use-cases this is supposed to serve.

/cc @fmarier, who added it in the first place (in #175). It would be worth poking at https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0228.html since some folks there were enthusiastic (including me, but I'm enthusiastic about too many things these days...).

[fmarier]

On the gecko side, @franziskuskiefer has already landed support for the attribute in <img> and has patches for <a> and <area> and <iframe> in review.

[briansmith]

I don't think it's desirable for a ServiceWorker to set the referrer attribute on any request, given the advertising use cases for Referer that Mike West gave on the mailing list a few months ago. In particular, didn't Mike say that it was important that an advertisement be able to get the full referrer URL without any tampering? Otherwise, a ServiceWorker could be used to trick the ad network into showing an ad on a page that the ad network doesn't want to show an ad on. It seems like the path information, at least, in a Referer header isn't useful, in general, when a ServiceWorker is involved.

Anyway, the referrer attribute is essential for allowing pages and browsers to default to sending no referrer, while still allowing the page to send the referrer for specific advertisements that need it. We could (ab)use link relations for this purpose, but most elements that need such referrer control do not currently have a rel attribute.

[jeisinger]

we already have rel=noreferrer. also, adding a referrer attribute doesn't cover programmatic navigations.

Currently, a page can default to no referrer, and if an ad click happens just change the policy.

[annevk]

@briansmith per the current set of specifications, when you use a service worker the referrer will always be that of the service worker, for any request. That's clearly undesirable so we need a way out of sorts. Until we have explained the low-level plumbing of how that should work, it's irresponsible to add new high-level features, imo.

[briansmith]

@annevk As you said, ServiceWorker is already defined in such a way that whether or not we have a referrer attribute is irrelevant to it. We don't need to block progress on making referrer control safer and easier on improving ServiceWorker's referrer handling, and we shouldn't block progress on making referrer control safer and easier. The interaction of ServiceWorkers and referrer control, in general, should be figured out separately from the issue of whether or not we specify a referrer attribute. It seems to me that the programmatic control that ServiceWorkers offers and the assumptions of lack of tampering of the Referer header--even without any referrer control mechanism--are greatly at odds with each other, as far as advertising is concerned.

@jeisinger That's the workaround Facebook uses, but even Facebook doesn't (at least didn't) like doing it that way. It would be safer to keep the mechanism declarative and avoid the need to mutate global state (the value of meta referrer). In particular, it seems likely to be easy to make a mistake in the JS code that manipulates meta referrer that would cause it to not get reset to the safe default. It would also be better for responsiveness if we didn't have to run a JS event handler just to reset the meta referrer value. Also, for prefetching we need a declarative way to control the referrer that is used for the prefetch. Again, I think a declarative mechanism like the referrer attribute would make it easier to keep the in sync with the or or whatever.

[annevk]

@briansmith strongly disagree. We should first figure out what the underlying principles of referrer are, which definitely includes how they work with service workers at this point, before introducing new syntax. We might very well end up wanting different syntax.

[sc0ttbeardsley]

A primary use case for the attribute delivery mechanism (@fmarier and I discussed it at the time) was to have a different policy for a subset of page navigations. We (Yahoo) have cases where we want to send the origin only to certain destinations and the unsafe url to other destinations. It would be unmaintainable for us to maintain an exhaustive list of these destinations and send them with each document so we don't want this in CSP, for example. Instead we wanted to tag specific links which override the page-level policy.

So far our requirements do not apply to service workers which may be why it was left unaddressed. I'm worried about removing the referrer delivery mechanism from the draft until there is a proposed alternative which meets these requirements.

[annevk]

Well first of all some kind of processing model for this attribute needs to be defined (it's an open issue), which requires defining how it interacts with Fetch (and what Fetch' interface for referrer should be), which requires solving the service workers issues.

[annevk]

So in http://krijnhoetmer.nl/irc-logs/whatwg/20150715#l-431 it was suggested to rename this attribute to referrerpolicy="" (referrerPolicy for the IDL attribute) for consistency with Fetch.

I will update Fetch to provide the infrastructure so this can be specified properly in the above-referenced issue.

[annevk]

I have now done so. What remains here:

• Rename the attribute to referrerpolicy.
• Rename the IDL attribute to referrerPolicy and specify it to be an enumerated attribute limited to only known values: https://html.spec.whatwg.org/multipage/infrastructure.html#limited-to-only-known-values
• Make sure that this attribute sets request's referrer policy.
• Define in the Fetch integration section that request's referrer policy is more important than environment settings object's referrer policy.
• Ideally, reference https://fetch.spec.whatwg.org/#concept-referrer-policy for the policy values. (We could maybe move this into Referrer Policy if you wish.)

[sc0ttbeardsley]

"referrerpolicy" instead of "referrer" seems fine to me! Do we need to generate a PR for this in the spec docs?

[annevk]

If you could do that, I think @jeisinger would appreciate it. (I would too.)

[annevk]

This has all been resolved, as far as I know. \o/