Add referrer policy to blob-generated responses

[domenic]

As discussed in whatwg/html#1205 (comment).

Don't have Anolis installed so you'll need to regenerate.

/cc @bzbarsky

[annevk]

So for about:blank we let HTML handle it?

[domenic]

I don't really know. I am just trying to make referrer policy parallel to HTTPS state. I don't understand the issue with about:blank for either of the two.

[bzbarsky]

The issue is this, for referrer policy: If you have a subframe that you never load anything into, and then you inject some elements into it that do loads, what should those loads use as the referrer and why?

[domenic]

The default referrer policy of "" (which in Fetch gets treated the same as "no-referrer-when-downgrade"), because there's no other natural choice?

[bzbarsky]

There is totally a natural choice: the referrer policy of the place where we get the referrer itself from: the parent page.

[bzbarsky]

Or put another way.... Whatever place it is that we propagate the value of referrer to things, we should propagate the value of the referrer policy in those same exact places. Anything else is just broken.

[domenic]

Oh, I see. You are of course right.

Yes, this should presumably be handled in HTML. It'd probably be done as part of w3c/webappsec-referrer-policy#40, since when we figure out how to apply <iframe referrerpolicy="whatever"> for the about:blank, we'll want to handle the fallback case too.

[domenic]

Ah! It's already taken care of, I just had some trouble finding it due to the way navigation has like four different algorithms involved. https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context step 6.

[annevk]

Okay, so we don't have to fix this here? It does make more sense to handle this in HTML since a referrer policy is only relevant for something that ends up creating a document or worker.

[domenic]

No, I meant the about:blank case is taken care of. Blob URLs should still be consistent between HTTPS state and referrer policy...

[bzbarsky]

The initial about:blank case is taken care of by https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-browsing-context

What about non-initial about:blank?

[domenic]

I think as currently specced that will be handled by the navigate algorithm, which will get a "response" for about:blank that doesn't have any Referrer-Policy header, and so it will set the "" referrer policy.

[bzbarsky]

Yes, but what will it use for the referrer?

[domenic]

Presumably it would follow the normal navigate logic, and use the page that it was navigated from? @annevk might know better. But I'm not sure what's tricky about that case...

[bzbarsky]

No, I mean if you navigate your subframe to about:blank and then inject an <img> tag in there, what referrer will the image load use and why?

[domenic]

This is the responsibility of https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer. By my reading it will reach step 3.3.3 (referrerSource = "about:blank"), but then step 4 will set referrerURL to no referrer (since about: is a local scheme), which is what will be returned in step 6 (where the policy is "").

I can't actually find where Fetch invokes https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer; @annevk? The section https://w3c.github.io/webappsec-referrer-policy/#integration-with-fetch seems inaccurate.

[mkruisselbrink]

I can't actually find where Fetch invokes https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer

Main fetch step 8?

[domenic]

Ah yes, thanks. So then, assuming no referrer in Referrer Policy is the same as "no-referrer" in Fetch, I believe the resulting request will not have a referrer.

[bzbarsky]

OK. That seems fine, if it's what browsers do in practice...

[annevk]

Thanks to @antosart policy container will be taking care of this. w3c/FileAPI#142 will track this going forward.