Consider being less draconian in conflict resolution about webappsec-referrer-policy

[mikewest]

@devd suggested that deploying new policy keywords is difficult to do in a backwards-compatible way, and that it would be simpler if we allowed the policy to be overwritten by the last-delivered header. That makes sense to me, and matches what we do for <meta> delivery.

[estark37]

Isn't this what the spec already says? I see https://w3c.github.io/webappsec-referrer-policy/#set-referrer-policy that seems to describe the less-draconian version, and I don't see anywhere describing the draconian version.

[estark37]

Oh wait, now I see that https://w3c.github.io/webappsec-referrer-policy/#determine-policy-for-token returns No Referrer for an unknown value.

Though it does still seem to me that conflicting valid values would result in the latest header taking precedence, according to the current spec.

[devd]

Unfortunately, an older browser will see a new keyword as invalid and fall
back to none.
On Nov 11, 2015 6:49 AM, "Emily Stark" [email protected] wrote:

Oh wait, now I see that
https://w3c.github.io/webappsec-referrer-policy/#determine-policy-for-token
returns No Referrer for an unknown value.

Though it does still seem to me that conflicting valid values would result
in the latest header taking precedence, according to the current spec.

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[estark37]

I think this can be closed now; let me know if there's more work to do here.

[jeisinger]

can you send a patch for blink?

[estark37]

Yep, will do

On Wednesday, November 18, 2015, jeisinger [email protected] wrote:

can you send a patch for blink?

—
Reply to this email directly or view it on GitHub
#4 (comment)
.

[estark37]

https://codereview.chromium.org/1454823004/

[estark37]

oops didn't mean to reopen