-
Notifications
You must be signed in to change notification settings - Fork 139
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
Consider introducing a "same-site" concept that includes scheme. #448
Comments
I guess to be useful we should define this for both origins and URLs. |
I agree. The latter seems reasonably placed in URL. Would you prefer the former to live in HTML? |
Oh that's a good question, I guess so? And have the latter defined in terms of the former? It'll all be rather circular though, hope that's acceptable to people (I guess in practice almost nobody will click through to verify things make sense). |
Indeed. (Note that I haven't asked what RFC6265bis needs to depend on for |
I'll try to send you PRs that we can chat about at TPAC. |
(@annevk: Would you be willing to allow me to upload branches to this repository? It would save me the trouble of forking it again (which, admittedly, isn't much trouble. :)). |
You should have write access now. |
Helpers with whatwg/url#448.
As discussed in w3c/webappsec-fetch-metadata#34, we're slowly tightening the various places that evaluate URLs'/Origins' same-siteness to look beyond the host and require scheme matches as well.
That is,
http://example.com/
andhttps://sub.example.com/
have hosts which are considered"same-site", but many places in the platform have begun considering those contexts "cross-site" as the non-secure scheme creates risk for the secure origin.
To quote from that other thread:
The text was updated successfully, but these errors were encountered: