Parameterised Referrer Policy

[Jxck]

Current Spec has lots of policies which are not easy to understand how they actually work. And If other policies are added to, increasing the new policy name for them, might be longer.

So how about Parameterise policies ?

Currently spec has variation for destination and value like below.

• Destination (where to send)
  • Same-Origin
  • Cross-Origin
• Value (what to send)
  • Full URL
  • Origin
  • None
  • Allow Downgrade Flag

For example, origin-when-cross-origin are build upon these parameter like this

Origin-when-cross-origin: {
    Same-Origin: URL,
    Cross-Origin: Origin,
    Allow-Downgrade: true
}

parameterization is open for extension, so if new parameters will be added to, all you need is to add a parameter. not finding something-something-something-something name.

For example, Same-Site & Same-Party (see first party sets) are potentially candidates for Destination. And Split Full URL into Query (origin+path+query) and Path (origin+path) are more granular control.

Full lists are below

Default for value are all “none”, and downgrade are “false” (none for downgrade)

alias	same-origin	same-site	same-party	cross-origin	downgrade
no-referrer
unsafe-url	query	query	query	query	true
origin	origin	origin	origin	origin	true
strict-origin	origin	origin	origin	origin
same-origin	query				true
n-r-w-d	query	query	query	query
o-w-c-o	query	origin	origin	origin	true
s-o-w-c	query	query	query	origin

I think Structured Field Value for HTTP seems fit for encoding(I know some problems happened around UA-CH).

* and override for a specific destination. Downgrade default are false (send none when downgrade)

ex) (not-normalized)

o-w-c-o

Referrer-Policy: *=”origin”, same-origin=”query”, downgrade=?1

s-o-w-c

Referrer-Policy: *=”query”, cross-origin=”origin”

strict-origin

Referrer-Policy: *=”origin”

Not named, but full URL for same-origin, only Path for same-site/same-party, none for cross-origin can be

Referrer-Policy: *=”path”, same-origin=”query”, cross-origin=”none”

[fmarier]

I suggested something like that in https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0085.html, but at the time, it looked like the easiest way forward was to simply add the three useful policy states that were missing (strict-origin, strict-origin-when-cross-origin and same-origin).

Given https://github.com/w3c/webappsec-referrer-policy/pull/124, it seems like we are more likely to remove policies in the future than add new ones.

[domfarolino]

I agree with @fmarier in that I don't think we're planning on adding enough policies to where the current way of doing things becomes problematic. If there any major limitations I'd be open to hearing them but I think the policies are relatively clear, and I haven't heard of many large developer pain points to justify a big change here. Plus we'd have to talk about backwards compatibility as well.

For now I'll close this since I don't think the interest / need is there, but feel free to re-open or discuss if you disagree.