Replace referrer directive with Referrer-Policy header

[estark37]

@jeisinger @mikewest this specifies the simplest possible Referrer-Policy header, with the idea that we could extend the syntax later to be more complicated if necessary. Also an attempt to specify what happens when a Referrer-Policy header is received on a redirect response. What do you think?

[annevk]

This needs to be integrated into Fetch somehow.

[jeisinger]

where somehow is probably stating what should be added to https://fetch.spec.whatwg.org/#http-fetch step 5.10

[annevk]

The alternative might be to have a step similar to step 7 of https://fetch.spec.whatwg.org/#http-network-fetch. To make the header have an effect each time you get a response from the network and then use that as appropriate.

(It does seem a bit weird that a header used for setting policies for documents and workers also has an effect on redirects for requests of images and the like. But maybe that's okay. CSP seems to do something similar for cookies.)

[estark37]

Following a redirect invokes main fetch (https://fetch.spec.whatwg.org/#concept-main-fetch), which in Step 6 calls into REFERRER determine-requests-referrer (https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer). Is it necessary to add steps to Fetch, given that Fetch already delegates to REFERRER to set the referrer?

[annevk]

I think in HTTP-network fetch we want to have steps that handle processing the Referrer-Policy header, which REFERRER would not have access to otherwise. Does that make sense?

[annevk]

I also don't see where the handling for multiple tokens is defined.

[estark37]

Expanded the syntax to allow multiple tokens per @annevk's suggestion

[annevk]

I think you misunderstood. The #1 syntax already allowed for multiple comma-separated tokens. Your text was however not handling it. Now you introduced new syntax you are not covering what happens if you get multiple headers (which with the #1 syntax are somewhat identical to multiple values).

[estark37]

Hmm, well I think I do want the syntax to be semicolon-separated, not comma-separated (Referrer-Policy: origin; unsafe-url) with multiple headers treated the same as if all the values were concatenated (Referrer-Policy: origin; unsafe-url followed by Referrer-Policy: origin-when-crossorigin should result in enforcing origin-when-crossorigin)... unless there's a reason that it would be better for them to be comma-separated?

Assuming I leave it as semicolon-separated, I should just add text to handle multiple header values then?

[mikewest]

@estark37: We had talked earlier about potentially supporting the syntax @briansmith suggested (e.g. "[keyword] [property] [property] [property]; [keyword2] [property]") in order to allow CSP-like specification of scopes to which particular policies should apply. Is that something you're trying to leave room for here? If so, I wonder if this is a small opportunity to make @mnot, et al. happy by experimenting with a JSON-based syntax. I'm thinking about doing something similar for CSP3.

[briansmith]

Regarding commas vs semicolons, this:

Referrer-Policy: origin
Referrer-Policy: unsafe-url

is equivalent to this (note the comma):

Referrer-Policy: origin, unsafe-url

What would the difference between that and the following (note the semicolon) be?

Referrer-Policy: origin; unsafe-url

The only reason to use semicolons instead of commas is if you need an additional level of grouping to subdivide comma-separated things.

[estark37]

@mikewest: yeah, I am trying to leave room for that. What would the JSON syntax look like for CSP3?

@briansmith: I was basically trying to copy off CSP, which is why I was going for semicolons. But I guess CSP is different...

Content-Security-Policy: script-src http://foo.com
Content-Security-Policy: script-src 'none'

has a different effect than

Content-Security-Policy: script-src http://foo.com; script-src 'none'

Whereas I think

Referrer-Policy: unsafe-url
Referrer-Policy: origin

should be the same as what I have written as Referrer-Policy: unsafe-url; origin right now, so there isn't a need for semicolon separation.

[estark37]

friendly ping to @mikewest: are there any ideas written up anywhere for what CSP3 JSON syntax would look like?

[mikewest]

Nothing for CSP in particular, but http://greenbytes.de/tech/webdav/draft-reschke-http-jfv-latest.html is the draft describing the general notion that I'm considering.

[mozfreddyb]

Well @jonathanKingston, was looking into (de)serialization of CSP policies into JSON at https://gist.github.com/jonathanKingston/5699b440f608960dc089

[mikewest]

Ah, right. I forgot about that doc. Yeah, @jonathanKingston's writeup seems sane. Not sure about the merging bits, but that's a tangential discussion.

Regardless, it might be reasonable to experiment with the referrer-policy header's syntax in this way to give the HTTP WG some data to work with. Something like referrer-policy: { "default": "origin", "unsafe-url": [ "https://specific.example.com" ] } would suit @briansmith's suggestion. It's a bit verbose for this use case, but I think I buy @reschke suggestion that we'd more than make up for it by standardizing on a JSON parser rather than writing one-off parsers for each header type.

[estark37]

Hello! I'm back with some revisions:

1. Attempted an integration with Fetch as @annevk suggested. Not sure if what I did makes any sense. I also added a (brief) Integration with HTML section, which I thought seemed necessary now that it's no longer tied to CSP.
2. Went back to the 1# syntax for handling multiple values in the Referrer-Policy header and added some text explaining how to handle multiple values.
3. I'm torn on the JSON suggestion. I want to leave the door open for @briansmith's suggestion of having a default policy + other policies that apply to particular URLs, but I don't know if it makes sense to actually spec that yet -- I don't see anyone clamoring to use it at this point. And if we're not going to spec it yet, then it seems a little silly to use { "default": "origin" } instead of just origin. Open to being convinced one way or the other. :)

[mikewest]

1. I'll leave the Fetch integration review to @annevk.
2. Regarding JSON, I think the current syntax (e.g. Referrer-Policy: origin) could be extended into JSON in the future if you made it a quoted string rather than a bare keyword. That is, Referrer-Policy: "origin" could enable Referrer-Policy: "origin", { "origin": [ "*" ] , "unsafe-url": [ "https://specific.example.com" ] } in the future because "origin" would be interpreted as legal JSON if we ran with the mechanism in http://greenbytes.de/tech/webdav/draft-reschke-http-jfv-latest.html#rfc.section.4.

On that note, I'm slowly convincing myself that something like that proposal is the right way to go. Ilya and I are running with a JSON format in https://w3c.github.io/reporting/ and I don't feel bad about it. I don't think it's wonderful enough to justify a new syntax for CSP (barring some other breaking change), but I do plan on using it for Clear-Site-Data. Perhaps you could join me here in the kinda verbose and ugly future? :)

/cc @mnot @reschke, who will hopefully be giving me some cover in the HTTP WG shortly. :)

[annevk]

I think for this header that suggested integration with Fetch and HTML looks reasonable. There's also some changes we might have to consider around referrers and redirects if the current steps don't describe that accurately.

[jeisinger]

just to double-check, is it ok to drop the CSP delivery just like this?

[mikewest]

It's y'all's spec. Do whatever you think makes sense.

In this case, we'll need to measure usage in Chrome and drop support after deprecation, but that's on us. The spec doesn't need to maintain the definition.

[jonathanKingston]

Well @jonathanKingston, was looking into (de)serialization of CSP policies into JSON at https://gist.github.com/jonathanKingston/5699b440f608960dc089

Just seen this sorry.

Ah, right. I forgot about that doc. Yeah, @jonathanKingston's writeup seems sane. Not sure about the merging bits, but that's a tangential discussion.

Yeah the whole document is more for porting and merging JSON files which is somewhat unrelated to the CSP header.

I don't think it's wonderful enough to justify a new syntax for CSP

I was hoping the OOB reporting would be enough to do this :(.

The array header mechanism mentioned seems great:
http://greenbytes.de/tech/webdav/draft-reschke-http-jfv-latest.html#rfc.section.4
It would be useful to define that within a spec or similar as a named header type.

It would certainly be nice to have one less format and as @mikewest mentioned this can be mitigated by permitting the array JSON structure and quoting the keyword.