Skip to content

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

Closed
wanderview opened this issue May 12, 2016 · 7 comments

Comments

@wanderview
Copy link
Member

Currently section 3.3.2 has this note:

Since the response type for data URLs will always be “opaque” for script and link elements, such URLs are never eligible for integrity checks. Blob URLs on the other hand are usually considered same-origin and therefore are eligible for integrity checks.

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.

@wanderview
Copy link
Member Author

See also: whatwg/html#1243

@fmarier
Copy link
Member

fmarier commented May 17, 2016

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?

@wanderview
Copy link
Member Author

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.

@bzbarsky
Copy link

bzbarsky commented May 17, 2016

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.

@fmarier
Copy link
Member

fmarier commented May 17, 2016

So in concrete terms, would you revise the note or remove the note entirely?

Is the algorithm itself flawed?

@devd
Copy link
Contributor

devd commented May 17, 2016

removing the note sounds good to me

@fmarier
Copy link
Member

fmarier commented May 18, 2016

I removed the note in #38.

fmarier pushed a commit that referenced this issue May 18, 2016
Remove the note about data: and blob URLs (fixes #35)
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

4 participants