-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
Commenting only on this part:
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 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. |
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:
When using this syntax, the default would be to send no referrer (safe default), then you can choose who gets the
full-url
ororigin
, based on a syntax that's similar to CSP.I think these are how the current policies would be implemented:
I am concerned the
unsafe-url
version would be very easy to copy/paste without realising that it's unsafe (ref the fun thatcrossdomain.xml
allowed, and howAccess-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).The text was updated successfully, but these errors were encountered: