Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible Version 2 #143

Closed
craigfrancis opened this issue Aug 18, 2020 · 2 comments
Closed

Possible Version 2 #143

craigfrancis opened this issue Aug 18, 2020 · 2 comments

Comments

@craigfrancis
Copy link

Following on from #138, the suggestion from Brian Smith, recognising the current list of keywords can be a little confusing (I need to check a table to see what each one does 1, 2), and the limited ability to customise depending on which domain the request is going to...

How about:

Referrer-Policy:
  full-url 'self' https://shop.example.com;
  origin https://ads.example.com;

When using this syntax, the default would be to send no referrer (safe default), then you can choose who gets the full-url or origin, based on a syntax that's similar to CSP.

I think these are how the current policies would be implemented:

no-referrer
  Referrer-Policy: full-url 'none';

no-referrer-when-downgrade (from HTTPS)
  Referrer-Policy: full-url https://;

no-referrer-when-downgrade (from HTTP)
  Referrer-Policy: full-url *;

same-origin
  Referrer-Policy: full-url 'self';

origin
  Referrer-Policy: full-url 'none'; origin *;

strict-origin
  Referrer-Policy: full-url 'none'; origin https://;

origin-when-cross-origin
  Referrer-Policy: full-url 'self'; origin *;

strict-origin-when-cross-origin
  Referrer-Policy: full-url 'self'; origin https://;

unsafe-url
  Referrer-Policy: full-url *;

I am concerned the unsafe-url version would be very easy to copy/paste without realising that it's unsafe (ref the fun that crossdomain.xml allowed, and how Access-Control-Allow-Origin * fails safe by not working for credentialed requests).

And I'll note that a referrerpolicy on <a>/<area>/<img>/<iframe>/<script>/<link> currently allows you to override the header for specific requests (and the very minor security concern, if someone malicious was able to add a link with this attribute, which a HTML sanitiser might allow).

@Malvoz
Copy link
Contributor

Malvoz commented Nov 24, 2020

Commenting only on this part:

referrerpolicy on <a>/<area>/<img>/<iframe>/<script>/<link> currently allows you to override the header for specific requests

There's a WHATWG HTML issue about potentially enabling capping the referrer information in whatwg/html#5041.

@domfarolino
Copy link
Member

Commenting only on this part:

referrerpolicy on <a>/<area>/<img>/<iframe>/<script>/<link> currently allows you to override the header for specific requests

There's a WHATWG HTML issue about potentially enabling capping the referrer information in whatwg/html#5041.

Yes, let's try and separate the two things (a) this proposal, which allows for more granular referrer policy setting per-origin, and (b) the idea that per-request referrerpolicy= attributes can loosen the referrer policy specified in a header or meta tag.

This proposal (a) is interesting, but I think it is unlikely to be pursued by browsers at this point. It would require some complicated changes to this and other specs, and I see most of the impact from referrer policy as having already been achieved. I think a good next step for this would be to post something on https://discourse.wicg.io/ to see if there is a larger community appetite for this, or even interest from other browser vendors.

Thanks a lot for the proposal, feel free to write back here if we come across larger community support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants