HTML spec changes about data: URIs and origins

[Frederik Braun]

Firefox treats iframes pointing to a data URL as same-origin. This is
all well-known, was part of the HTML spec and has been discussed before
[1,2]

What has changed now is the HTML spec text[3]: Given that EdgeHTML,
Webkit and Blink violated this requirement, the standard now turned
around and assigns them a unique opaque origin.
I'll gladly accept the fact that we are not the violator, given the
security implications [1].

The GitHub related issue[4] included a discussion with some of our DOM
folks, but did not come to a conclusion as to what we plan to do here.

Is back compat the main concern? I'd be happy to add a telemetry probe
and a devtools warning if someone is willing to point me in the right
direction.


Thanks,
Freddy


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=255107
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1018872
[3]
https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f
[4] https://github.com/whatwg/html/issues/1753

[Anne van Kesteren]

On Tue, Sep 13, 2016 at 2:31 PM, Frederik Braun <fbr...@mozilla.com> wrote:
> Is back compat the main concern? I'd be happy to add a telemetry probe
> and a devtools warning if someone is willing to point me in the right
> direction.

As I understand it the main potential problem is addons, coupled with
internal tests that need to be rewritten by someone.


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 9/13/16 8:31 AM, Frederik Braun wrote:
> Is back compat the main concern?

Yes. Both for websites and addons.

There's also a largish amount of work involved in auditing our tests to
make sure the change doesn't make a bunch of security tests stop testing
what they're trying to test, plus fixing tests that actually start
failing, etc. But that's at least under our control.

> I'd be happy to add a telemetry probe

For what, exactly? What do you propose to measure?

-Boris

[Frederik Braun]

First of all, just to see how much breakage to expect when doing this
on the web.
So I wonder, is there a code path that we'd always call for DOM access
to other window objects than the current global scope (e.g., iframes,
popups), which have a data URL?

I assume the mere creation of those iframes/popups is possibly less useful.

[Boris Zbarsky]

On 9/13/16 3:15 PM, Frederik Braun wrote:
> First of all, just to see how much breakage to expect when doing this
> on the web.

Right, but my question is how you plan to measure that.

> So I wonder, is there a code path that we'd always call for DOM access
> to other window objects than the current global scope (e.g., iframes,
> popups), which have a data URL?

There's a code path that we always call for access across windows, yes.
See cross-compartment proxies.

That codepath knows nothing about data URLs and is rather
performance-sensitive.

You _could_ perhaps subclass them in the case when the target
compartment comes from a data: URL and get somewhere that way. Again,
you'd need to do that without regressing peformance for all cross-window
access.

> I assume the mere creation of those iframes/popups is possibly less useful.

Probably; we know they get created; what we don't know is how they're used.

-Boris

[Daniel Veditz]

On Tue, Sep 13, 2016 at 12:25 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> Probably; we know they get created; what we don't know is how they're used.

​Since Gecko is the only engine that behaves this way we can be reasonably
sure we won't find public "must use Firefox" web sites depending on this
behavior​. Internal corporate/educational apps maybe, add-ons almost
certainly, and our tests definitely.

-
​Dan Veditz​

[Boris Zbarsky]

On 9/14/16 2:01 AM, Daniel Veditz wrote:
> ​Since Gecko is the only engine that behaves this way we can be reasonably
> sure we won't find public "must use Firefox" web sites depending on this
> behavior​.

I wish that were true. In practice, I will be pleasantly surprised if
we don't find such sites, or rather sites that browser-sniff and have
different codepaths (e.g. using data: in Firefox and blobs otherwise).

-Boris

[smaug]

Just to get some idea how many tests would be broken:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b

[smaug]

On 11/07/2016 10:41 PM, smaug wrote:
> Just to get some idea how many tests would be broken:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b
>

The results show that quite a few tests need to be fixed, if we want to change data: handling.
Should we start doing that? I think we should since eventually we should become compatible with other engines.

(I'm still busy fixing browser chrome tests to work with proper Promise scheduling, so can't help here quite yet)


-Olli