Clarify priority of Referrer Policy Delivery about webappsec-referrer-policy

[jeisinger]

it's supposed to say that if you do

var a = document.createElement('a');
a.referrerPolicy = 'origin'; // safe fallback
a.referrerPolicy = 'fancy-new-thing';

and 'fancy-new-thing' isn't implemented, we'll keep using 'origin'

[tungnh28]

Thanks you.
I am more concerned about priority of Referrer Policy delivering in [1](public version)
Questions are
(a) What if the document ships a CSP with a referrer Policy and the worker (called from the document) ships a CSP with a different referrer policy?

(b) Same as (a) but the main document uses but the worker ships with a different referrer policy delivered through CSP. What should be the expected behavior?

(c) What about sub workers? If a main document ships a referrer policy, the workers ships it's own referrer policy through CSP, which one applies to the sub worker? The main document's? The worker's?

[1] https://www.w3.org/TR/referrer-policy/#referrer-policy-delivery

These questions are based on public version. I see CSP is not mentioned anymore in newest draft version, but it may have similar priority concern.
Could you please clarify that? Thank you so much

[jeisinger]

(note that delivery via CSP doesn't exist anymore in the latest draft, but it's a dedicated header now)

in a) the CSP of the worker is applied to the worker

I don't get b)

in c) if the sub-worker doesn't have a CSP it would inherit the policy of the worker that spawned it

[tungnh28]

b) is the mostly the same with a)
Yay! Thank so much for your clarification
Please close it

[domenic]

This is related to #46.

and 'fancy-new-thing' isn't implemented, we'll keep using 'origin'

This isn't how things are currently specced or implemented. The spec follows the same logic as "CORS setting attributes" and other enumerated attributes (like <input type> or <track kind>), where setting to an invalid type falls back to the "invalid value default".

See http://jsbin.com/wehogulohu/edit?html,console,output for a CORS test. https://jsbin.com/tijoxe/edit?html,console,output is a referrer policy test, using the nonstandard chrome referrerpolicy (all lowercase) property; it shows how it falls back to the "" property, which makes sense given the Chrome source code:

[Reflect, ReflectOnly=("","no-referrer","origin","no-referrer-when-downgrade","origin-when-cross-origin","unsafe-url"), ReflectMissing="", ReflectInvalid=""] attribute DOMString referrerpolicy;

[jeisinger]

Well, then that's a bug

Domenic Denicola [email protected] schrieb am Fr., 6. Mai 2016,
16:47:

This is related to #46
#46.

and 'fancy-new-thing' isn't implemented, we'll keep using 'origin'

This isn't how things are currently specced or implemented. The spec
follows the same logic as "CORS setting attributes" and other enumerated
attributes (like or ), where setting to an
invalid type falls back to the "invalid value default".

See http://jsbin.com/wehogulohu/edit?html,console,output for a CORS test.
https://jsbin.com/tijoxe/edit?html,console,output is a referrer policy
test, using the nonstandard chrome referrerpolicy (all lowercase)
property; it shows how it falls back to the "" property, which makes
sense given the Chrome source code:

[Reflect, ReflectOnly=("","no-referrer","origin","no-referrer-when-downgrade","origin-when-cross-origin","unsafe-url"), ReflectMissing="", ReflectInvalid=""] attribute DOMString referrerpolicy;

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#48 (comment)

[domenic]

Hmm. We should figure out how to spec that then. Can you think of any other IDL attribute on the web platform that works that way? Can you figure out a way to reconcile the mismatch between the semantics you want for IDL attributes and the semantics for content attributes, which don't retain a "memory" of their old value?

[estark37]

@jeisinger I don't think we need it to work that way; I think it would only be a convenience, because you could always use feature detection:

var a = document.createElement('a');
a.referrerPolicy = 'fancy-new-thing';
if (a.referrerPolicy == "")
  a.referrerPolicy = 'origin'; // safe fallback

(Unlike the header, where you can't do feature detection before deciding which value to send in the header.)

[jeisinger]

Fair enough. I think the initial text is from when we didn't have feature
detection and you only could blindly thirties l throw things at the meta tag

Emily Stark [email protected] schrieb am Fr., 6. Mai 2016, 18:47:

@jeisinger https://github.com/jeisinger I don't think we need it to
work that way; I think it would only be a convenience, because you could
always use feature detection:

var a = document.createElement('a');
a.referrerPolicy = 'fancy-new-thing';
if (a.referrerPolicy == "")
a.referrerPolicy = 'origin'; // safe fallback

(Unlike the header, where you can't do feature detection before deciding
which value to send in the header.)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#48 (comment)

[jeisinger]

I guess my phone is thirsty or something...

Jochen Eisinger [email protected] schrieb am Fr., 6. Mai 2016, 18:48:

Fair enough. I think the initial text is from when we didn't have feature
detection and you only could blindly thirties l throw things at the meta tag

Emily Stark [email protected] schrieb am Fr., 6. Mai 2016, 18:47:

@jeisinger https://github.com/jeisinger I don't think we need it to
work that way; I think it would only be a convenience, because you could
always use feature detection:

var a = document.createElement('a');
a.referrerPolicy = 'fancy-new-thing';
if (a.referrerPolicy == "")
a.referrerPolicy = 'origin'; // safe fallback

(Unlike the header, where you can't do feature detection before deciding
which value to send in the header.)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#48 (comment)

[estark37]

Hahah that was an excellently nonsensical autocorrect. Anyway yeah I have #46 open to clarify that the fallback behavior applies to the header, not the attribute.

[tungnh28]

Close it, thanks all for helping me