-
Notifications
You must be signed in to change notification settings - Fork 35
note about data: URLs always returning opaque responses seems not quite right #35
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
Comments
See also: whatwg/html#1243 |
I added that note in w3c/webappsec#487 based on a discussion on the webappsec list and a discussion with @annevk. What kind of change would you propose? |
Well, there is no browser agreement about whether to set the "same-origin data-URL flag" for stylesheet loads or not. Firefox essentially set it. I believe @bzbarsky told me Edge essentially sets it. It appears chrome does not set it. So I think the note should not make this sweeping statement about data URI stylesheets. And it seems to me SRI should work on them if the browser sets the "same-origin data-URL flag" when loading stylesheets. |
It's worse than no browser agreement. Not setting that flag but also not shipping some of the bugs Chrome ships in terms of cross-origin stylesheet security checks is probably not web compatible. In other words, the note is based on bogus spec text, and will likely become false once the HTML spec is fixed. |
So in concrete terms, would you revise the note or remove the note entirely? Is the algorithm itself flawed? |
removing the note sounds good to me |
I removed the note in #38. |
Remove the note about data: and blob URLs (fixes #35)
Currently section 3.3.2 has this note:
I don't think this is quite accurate. I can't find a spec that says for
<link rel="stylesheet">
data URLs should not inherit the origin. And in gecko we actually do inherit the origin in this case and treat them as same-origin.The text was updated successfully, but these errors were encountered: