Same-origin data-URL flag only for fetch and XHR?

[youennf]

AFAIK, this flag is only used by XHR and fetch.
It does not seem to be used by the HTML specification at all.
Is it on purpose or just a lack of synchronization?

Doing a quick test, crossorigin-attribute-enabled scripts seem to load fine with data URLs in Chrome and Firefox.

[annevk]

That's interesting. I would have thought <script crossorigin> to fail. @mikewest, where does Chrome consider data URLs same-origin?

[youennf]

<script> window.onerror = function(message, source, lineno, colno, error) { console.log(message + "\nReceived error from \"" + source + "\". Error location is " + lineno + ":" + colno + "."); } var script = document.createElement("script"); script.crossOrigin = ""; script.src = "data:text/script, throw 'PASS: my error is rich!'"; document.body.appendChild(script); </script>

Firefox, Chrome and WebKit behave differently.

[youennf]

<script>
window.onerror = function(message, source, lineno, colno, error)
{
    console.log(message +  "\nReceived error from \"" + source + "\". Error location is " + lineno + ":" + colno + ".");
}

var script = document.createElement("script");
script.crossOrigin = "";
script.src = "data:text/script,  throw 'PASS: my error is rich!'";
document.body.appendChild(script);
</script>

[mikewest]

@mikewest, where does Chrome consider data URLs same-origin?

The snippet @youennf posted does not enrich the error (though it does load, probably because we're shortcutting through CORS for data: for exciting historical reasons). That is, we don't consider it same-origin, but we're not performing the same checks on it that we would for a network request.

More generally, I know that we allow extraction of pixels from data: from <canvas>, and I wouldn't be surprised if there were one or two other exceptions we've made over the years, but, ideally, Chrome doesn't consider data: URLs same-origin (At this point, I think Firefox is the only browser that does consider them same-origin consistently. Perhaps we should instead align the spec with Blink/WebKit/EdgeHTML? :) ).

[youennf]

Firefox does not seem to fully treat data URLs scripts as same-origin: the error is only partially enriched. Or maybe there is a bug preventing to enrich the error.
WebKit does not authorize to load data URLs in cross origin mode for scripts at the moment, but it could be changed.

Another example is ShapeOutside CSS property which must be "potentially CORS-enabled fetch"ed in "anonymous" mode. In WebKit, we recently set the same-origin data-url flag for this one.

I don't know the historical reasons of the same-origin data URL flag.
It seems to me data URL resources and inlined resources have a lot in common.
Since the origin of a data-url resource is well defined, shouldn't we simplify the fetch spec by removing the same origin data url flag? Or making it set by default? That would allow "potentially CORS-enabled fetch" to better match what browsers are doing.

[annevk]

@mikewest the specification is largely aligned with Chrome already. That is why it has the flag to make data URLs same-origin in a limited number of contexts. The problem here is that Chrome is not consistent. E.g., not failing the load for <script crossorigin> is really weird behavior as the contract for opting into CORS is that either you get same-origin or failure. So it doesn't really help to hand-wave about the exceptions, we need to know them or Chrome needs to remove them.

[mikewest]

the specification is largely aligned with Chrome already.

I was being flippant. By "the spec", I was talking more about HTML "origin of a document" than Fetch.

The problem here is that Chrome is not consistent.

Yup. I said "ideally" because I agree with you that Chrome's current behavior is weird in some places. I suspect that data: images in <canvas> is the only exception that's probably baked in for web compatibility purposes. I don't have much data to back that up, of course.

@tyoshino might know more about Chrome's CORS exceptions for data: in general, as he's been working in that code more recently.

[annevk]

I was talking more about HTML "origin of a document" than Fetch.

Is there an issue on that? I'm not sure what this is referring to.

[tyoshino]

I enabled data URL support for XHR in Chrome by a bit tricky way (changed WebURLLoaderImpl to virtually issue "Access-Control-Allow-Origin: *" to blink) 2 years ago (http://crbug.com/308768). It's not making data URLs handled as same-origin, but as cross-origin resource but with the CORS header to allow access.

<script> being allowed might be side-effect of the fix.

At the layer of checking same/cross-origin-ness, there could be some special treatment for data scheme, but I'm not so much familiar with.

[youennf]

This solution might cause issues with credentials then, not particularly important but still.
Also, it should make the data URL resource CORS-SameOrigin.

If there is no good reason for preventing data URLs to be same-origin, let's make them same-origin.

[mikewest]

@annevk: Filed whatwg/html#1753 for discussion.

[annevk]

@youennf Blink is opposed to making data URLs same-origin. https://bugzilla.mozilla.org/show_bug.cgi?id=255107 has some of their rationale. However, Blink does treat data URLs as same-origin in certain contexts (when not the result of a redirect): XMLHttpRequest, fetch(), and I guess <img> (not yet specified). Apparently the way that is implemented is suboptimal, but hopefully they can fix that.

I think my takeaway from this issue is that we should use this flag for <img>. Not sure if there's an issue on that already. @zcorpan?

[youennf]

Thanks for the pointer, I'll check that. It would be good to set that flag for <img>. It was very recently done so in WebKit.

[zcorpan]

It was added in whatwg/html#499 ... but img-environment-changes also needs it. :-( (Yes, we should factor out the common bits.)

[youennf]

Great, does it cover also https://drafts.csswg.org/css-shapes/#propdef-shape-outside?

[annevk]

@youennf no, it would not cover that necessarily. CSS doesn't define how it fetches resources, so it's unclear what code paths CSS would (re)use.

[youennf]

This spec says:
User agents must use the potentially CORS-enabled fetch method defined by the [HTML5] specification for all URLs in a shape-outside value. When fetching, user agents must use "Anonymous" mode, set the referrer source to the stylesheet’s URL and set the origin to the URL of the containing document.

In WebKit, the SameOrigin data URL flag is also set.

[annevk]

@youennf I guess they need to update to integrate with Fetch then.

[bzbarsky]

Blink is opposed to making data URLs same-origin. https://bugzilla.mozilla.org/show_bug.cgi?id=255107 has some of their rationale.

All of that only applies to navigation and maybe worker loads, not any other fetches, afaict.

[annevk]

Yeah, given whatwg/html#1243 (comment) onwards perhaps we should remove this flag and just special case navigation and workers.

[youennf]

Sounds like a good plan to me.

[annevk]

Created a PR, review appreciated.

[annevk]

Note that in whatwg/html#1243 (comment) @bzbarsky proposes a plan different from what I expected. Namely to allow data URLs for (I assume just dedicated) workers, but make them create a worker in an opaque origin.

[annevk]

So I won't be landing this right now until the details of that alternative plan are sorted, which I guess will take a while given all the timezone issues.