redact location.ancestorOrigins according to parents referrer policies #1917
Conversation
… ancestorOrigins for a Location
|
Addresses #1918 |
| <li><p><i>Loop</i>: If <var>current</var> has no <span>parent browsing context</span>, jump to | ||
| the step labeled <i>end</i>.</p></li> | ||
|
|
||
| <li><p>Let <var>current</var> be <var>current</var>'s <span>parent browsing | ||
| context</span>.</p></li> | ||
|
|
||
| <li><p>Let <var>referrer</var> be the result of executing the steps to | ||
| <dfn data-x="determine-requests-referrer">determine a request's referrer</dfn>, using:</li> |
There was a problem hiding this comment.
This isn't an appropriate algorithm to use, as it takes a request, but there is no request in sight here. I think you need to create some algorithm, either here or in Referrer Policy, named "origin censored according to a referrer policy" that takes an origin and a referrer policy. Then pass it current's active document's referrer policy and current's active document's origin.
Also, what happens if it's completely censored? Does the array get a null in it? If so the IDL needs to change to FrozenArray<USVString?> and the prose needs to deal. Or does that entry simply not end up in the array?
domenic
added
normative change
needs implementer interest
|
Although we should finish the discussion in #1918 first, this seems like something that it would be really good to have web-platform-tests for, before merging. |
consider parent browsing context referrer policy state when assignin ancestorOrigins for a Location