Referrer policy: Should request's referrer policy be updated in the main fetch?

[yutakahirano]

The spec says:

If request's referrer is not "no-referrer", set request's referrer to the result of invoking determine request's referrer.

The "determine request's referrer" algorithm combines request's referrer policy and environment's referrer policy, and then use it to calculate the referrer string. Is it reasonable to update the request's referrer policy to the combined referrer policy? That change is observable when the request is intercepted by the service worker.

@mikewest @jeisinger

[jeisinger]

@estark37

[annevk]

A service worker can only cause it to leak less, right, not more? I think this is okay as-is.

[yutakahirano]

If I understand the redirect behavior correctly, there are cases where the current behavior is less restrictive.

Assume request's original referrer is https://example.com/example.html.
Assume request's referrer policy is null.
Assume request's redirect mode is "follow".

request URL	main page's referrer policy	SW's referrer policy	referer (existing)	referer (update the policy)
https://example.com/example.html	null	no-referrer	no-referrer	no-referrer
https://example.com/example.html	origin only	no-referrer	no-referrer	https://example.com/
https://example.com/example.html	origin only when cross-origin	no-referrer	no-referrer	https://example.com/example.html
https://example.com/redirect.html => https://example2.com/example.html	null	origin only when cross-origin	https://example.com/	https://example.com/
https://example.com/redirect.html => https://example2.com/example.html	origin only when cross-origin	null	https://example.com/example.html	https://example.com/
https://example.com/redirect.html => http://example.com/example.html	origin only when cross-origin	null	no-referrer	https://example.com/
https://example.com/redirect.html => http://example.com/example.html	no referrer when downgrade	unsafe URL	https://example.com/example.html	no-referrer
https://example.com/redirect.html => http://example.com/example.html	no referrer when downgrade	origin only	https://example.com/	no-referrer

[annevk]

I'm not sure what you mean with "existing" and "update the policy". But the "referrer" is actually set at the beginning of Fetch to the result of applying the referrer policy. And then that "referrer" is passed on to the service worker. So once the page policy is applied, the service worker never sees the original referrer, it only gets a trimmed down one (potentially even a "no-referrer" one). It won't be able to turn that back into a full referrer as far as I can tell.

In other words, as long as the policy only has an effect on the referrer of the request, you can't really make more of less.

[yutakahirano]

I'm not sure what you mean with "existing" and "update the policy".

Sorry for not being clear.
"referer (existing)" means the HTTP referer header going to the network with the current specified behavior.
"referer (updating the policy)" means the HTTP referer header going to the network if we pass the combined referrer policy to the service worker. "Combined referrer policy" means the combined referrer policy from the request's referrer policy and the environment referrer policy.

But the "referrer" is actually set at the beginning of Fetch to the result of applying the referrer policy. And then that "referrer" is passed on to the service worker.

So once the page policy is applied, the service worker never sees the original referrer, it only gets a trimmed down one (potentially even a "no-referrer" one). It won't be able to turn that back into a full referrer as far as I can tell.

I agree that the service worker only sees the referrer string applied the referrer policy. It can see the original referrer if the referrer policy allows it, right?

What I'm talking about is the referrer policy passed to the service worker and the referrer calculation running in the service worker if the script calls fetch on the passed request.

[annevk]

The service worker does not get the original referrer. There's three parts in play:

1. The request's referrer (a URL, or a special value "client" or "no-referrer")
2. The request's referrer policy (a policy)
3. The request's client's referrer policy (a policy)

Then you have the two times this request goes through Fetch. The first time the client will be that of the page, the second time it will be that of the service worker.

The first time it goes through Fetch request's referrer will be set to whatever the Referrer Policy specification decides. It is now either the same as it was before, or less, and definitely no longer "client".

This means that the second time this request through Fetch, the Referrer Policy specification only has whatever request's referrer is set to to work with. So it cannot possibly reveal more, only less or the same amount.

And note that if request's referrer is "no-referrer", the Referrer Policy specification isn't even consulted.

[yutakahirano]

I think now I understand. I misunderstood "more" and "less" in your comments. I used them as more / less compared to the existing behavior, but you used them as more / less compared to the referrer string which is the result of the (first) referrer calculation, right?

Let me confirm one thing: If redirect is involved, I think it's possible that the HTTP "referer" header reveals more information than when the redirect were processed in the main page (the last two rows in the table). In other words, even if you're sure that the page's referrer policy is default and you don't give a referrer policy attribute to an element, a redirected request originated from the element to a downgraded URL might reveal the referrer. Is that correct?

[annevk]

You are correct. I used more/less in reference to how request's referrer is modified along the way.

A cross-origin redirect somewhere could indeed be problematic for the main page since it can only affect the initial request's referrer, so if it was not restrictive there (e.g., because for same-origin the full URL is fine) that might lead to the service worker revealing more than the main page had intended. But then if the service worker and the main page don't cooperate you have a whole lot of other issues too.

[yutakahirano]

I don't know what the other issues are, so this may be a silly question, but is it possible / desirable to update request's referrer policy after the referrer calculation in the main fetch? I mean, putting the below statements, for example.

1. If request's referrer policy is empty, set request's referrer policy to the value of environment’s referrer policy.
2. If request's referrer policy is still empty, set request's referrer policy to "no-referrer-when-downgrade".

It looks simpler to me - the referrer of a request originated from a page will not be affected by the service worker script's referrer policy. It's also consistent with the redirect behavior. "determine request referrer policy" algorithm has a special term (2) for it, but we will be able to remove the item. (Updated: this is wrong, never mind). Additionally, as an implementer I would be more comfortable with it for some reason.

[annevk]

I kinda like that. @estark37 @jeisinger, thoughts on that?

[jeisinger]

As long as it doesn't result in the implementation having to track two policies for requests that's fine :)

[annevk]

Also paging @ehsan about this potential change, since we just shipped this in Firefox. @ehsan, you only need to review the last couple comments.

[estark37]

@yutakahirano are you saying that we would remove step 2 of http://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer? When we receive a redirect response we want to apply the Referrer-Policy header in the redirect response while following the redirect, which is what step 2 is trying to accomplish. I guess instead we could specify in HTTP-redirect fetch that if actualResponse has a Referrer-Policy header, we update request's referrer policy to the policy from the header.

[yutakahirano]

@estark37 Ah, sorry, I was wrong. Thank you for correcting me.

[annevk]

@estark37 yeah, we should probably do that. If you search for "Execute set response's CSP list on actualResponse." you'll find how we integrated CSP, I guess we need to have similar things for the Referrer-Policy header (and not just during redirects I guess). Having said that, does Referrer Policy want to update for each fetch or only navigation fetches? If the latter it might be better to do this in HTML.