Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Referrer attribute and Fetch integration #409

Closed
annevk opened this issue Jun 29, 2015 · 15 comments

Comments

@annevk
Copy link
Member

commented Jun 29, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 6, 2015

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

@mikewest

This comment has been minimized.

Copy link
Member

commented Jul 6, 2015

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...).

@mozfreddyb mozfreddyb added the REFERRER label Jul 6, 2015
@fmarier

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2015

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

This comment has been minimized.

Copy link

commented Jul 6, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 6, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Jul 6, 2015

@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

This comment has been minimized.

Copy link

commented Jul 6, 2015

@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

This comment has been minimized.

Copy link
Member Author

commented Jul 6, 2015

@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

This comment has been minimized.

Copy link

commented Jul 14, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Jul 15, 2015

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 annevk referenced this issue Jul 15, 2015
@annevk

This comment has been minimized.

Copy link
Member Author

commented Jul 15, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Jul 16, 2015

I have now done so. What remains here:

@annevk annevk changed the title Referrer attribute Referrer attribute and Fetch integration Jul 16, 2015
@sc0ttbeardsley

This comment has been minimized.

Copy link

commented Jul 22, 2015

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

@annevk

This comment has been minimized.

Copy link
Member Author

commented Jul 22, 2015

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

@annevk

This comment has been minimized.

Copy link
Member Author

commented Dec 10, 2018

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

@annevk annevk closed this Dec 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.