1324406 - Treat 'data:' documents as unique, opaque origins

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P1)

Description

[Christoph Kerschbaumer [:ckerschb]]

Change the handling of 'data:' URLs to which user agents
navigate. Rather than inheriting the origin of the settings object
responsible for the navigation, they will be treated as unique,
opaque origins.

This aligns the spec with the behavior found in Chrome, Safari,
Opera, and Edge.

See also:
https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f
https://github.com/whatwg/html/issues/1753

Comment 1

[Frederik Braun [:freddy]]

Olli did a test run in November to see how much tests fail once you do the change:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b

Comment 2

[Anne (:annevk)]

Duplicate of bug 1018872?

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Anne (:annevk) from comment #2)
> Duplicate of bug 1018872?

Indeed, I would like to keep this new bug anyway since the spec has changed and hence we could have this bug to track implementation effort.

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

We are going to track work also within this etherpad:
  https://public.etherpad-mozilla.org/p/datauri

Comment 5

[Boris Zbarsky [:bzbarsky]]

Just so we're clear on the test bugs: the problem is not just tests that _fail_ with the pref flipped.  It's also tests that stop testing what they should be testing completely and always pass instead.

Comment 6

[Frederik Braun [:freddy]]

Some tests can be repaired by replacing data with actual resources, as they rely on the resource being in the same origin.
Other tests use data URIs for images or scripts, in which case the functionality shouldn't be hampered through the change.

What scenario do you have in mind, exactly?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, say we had a test that did:

  <iframe sandbox src="data:whatever">

and was then checking that the "sandbox" attribute actually made the load different-origin.  Then we make data: always different-origin.  Then we break the behavior of the "sandbox" attribute so it doesn't work anymore and don't notice.

Yes, I know we probably have tests for @sandbox that don't use data:, so this _specific_ scenario is ok.

What we should probably do if we want to do this right is MOZ_CRASH if data: is being loaded in a docshell, and then go through all the test failures resulting from _that_.

Comment 8

[Jonathan Watt [:jwatt]]

Note that to provide motivation for sites to switch to HTTPS there's been a push to have all new features require a secure context, whether the features are in any way security related or not. If we prevent data: URI documents inheriting the security context'edness of the opener we will find data: URI pages increasingly hobbled in ways we may not foresee yet. Then again, once we've killed off plain-HTTP I guess the concept of Secure Contexts can die and we can unhobble them. ;)

Comment 9

[Chris Mills [:cmills]]

This probably needs a mention somewhere on MDN.

Comment 11

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Should we treat data:image as cross origin? as I am working in one of the tests, I found that Chrome treats data:image/ as the same origin
But if we turn on the pref in Firefox, it will throw Security Error.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1368895#c2

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Should we treat data:image as cross origin?

No.  Nor should you block data: fonts.  And data: stylesheets should probably be considered same-origin too.  Not sure what the state is for data: workers.  Some of these things already use one of our *_DATA_INHERITS security flags, but I expect the current implementation of the pref completely breaks those across the board, which is wrong.

Note that the specs may or may not properly spec all of this, depending.  File spec bugs as needed.

Comment 13

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-) from comment #12)
> > Should we treat data:image as cross origin?
> 
> No.  Nor should you block data: fonts.  And data: stylesheets should
> probably be considered same-origin too.  Not sure what the state is for
> data: workers.  
> 
Thanks, I'll file bugs.

One question, what if we do
<iframe src="data:image/png..."></iframe>
What should this be?

Per spec,
"If the Document was generated from a data: URL

    A unique opaque origin assigned when the Document is created.
"

it should be cross origin, right?

Comment 14

[Boris Zbarsky [:bzbarsky]]

The document should be cross-origin, yes, with the pref flipped.  The image in that document should be same-origin with that document.

Comment 15

[Boris Zbarsky [:bzbarsky]]

That is, the handling of data: basically depends on the loading _context_, not the MIME type of the response.  If you do:

  <iframe src="data:text/css,stuff"></iframe>

That should likewise not be same-origin with the parent, with the pref flipped.

Comment 16

[Ben Kelly [:bkelly, not reviewing]]

> Not sure what the state is for data: workers.

Its treated as an opaque null principal origin.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Right, but it's still allowed to load, yes?

Comment 19

[Henry Chang [:hchang]]

Just got an idea and not sure if has been discussed:

For those fixes which requires replacing data:uri requests, can we just
have a "echo server" which just parse/echo what's carried in the data:uri?

For example, for
 
<iframe src="data:text/html,<iframe></iframe>">

instead of creating a new file and replacing with that file,

we can just change it to

<iframe src="https://mochi.test/echo/" + encode("data:text/html,<iframe></iframe>"))

and the echo sever would respond data based on what the data:uri specified.

I can imagine people who are fixing this kind of test cases have been suffering
from creating new files and modifying .ini files.

Comment 20

[Anne (:annevk)]

That might be okay for mochitests. I don't think it's good enough for web-platform-tests. But also, simple cases like that can be written as <iframe srcdoc="<iframe></iframe>">.

Comment 21

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Anne (:annevk) from comment #20)
> That might be okay for mochitests. I don't think it's good enough for
> web-platform-tests. But also, simple cases like that can be written as
> <iframe srcdoc="<iframe></iframe>">.

I am rather for rewriting those tests if needed. Also for future changes within our codebase and testing infrastructure we might run ourselves into a corner where it's hard to get out of. Adding such changes were content dynamically gets modified is hard to follow and reason about. I think it's better to keep it as simple as possible.

Comment 22

[Christoph Kerschbaumer [:ckerschb]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=37554efc3fb036d426fed8b8aca58148fcb8a4da

Comment 23

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Christoph Kerschbaumer [:ckerschb, back on Aug 16] from comment #21)
> (In reply to Anne (:annevk) from comment #20)
> > That might be okay for mochitests. I don't think it's good enough for
> > web-platform-tests. But also, simple cases like that can be written as
> > <iframe srcdoc="<iframe></iframe>">.
> 
> I am rather for rewriting those tests if needed. Also for future changes
> within our codebase and testing infrastructure we might run ourselves into a
> corner where it's hard to get out of. Adding such changes were content
> dynamically gets modified is hard to follow and reason about. I think it's
> better to keep it as simple as possible.

I think my comment was not completely clear. To be precise, we should add new files and rewrite one test at a time instead of dynamically changing content on a simulated server.

Comment 24

[Christoph Kerschbaumer [:ckerschb]]

 https://treeherder.mozilla.org/#/jobs?repo=try&revision=d9cfb1584d74b0f4afaae06a52076ecd83583434

Comment 25

[Christoph Kerschbaumer [:ckerschb]]

 https://treeherder.mozilla.org/#/jobs?repo=try&revision=2026ca31d384dac236f364648f66f2828aaa080b

Comment 26

[Christoph Kerschbaumer [:ckerschb]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ca5a6b268ccc2559cf5bf0246965631caf05e84

Comment 27

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=7ca5a6b268ccc2559cf5bf0246965631caf05e84

Carsten, we are about to flip the pref |security.data_uri.unique_opaque_origin| and push to inbound within the next couple days and hence we also pushed to TRY a couple times over the last few days. The link within this comment (see above) contains a few errors, but we *think* all of those errors are intermittents. Any chance you could take a look at the provided link and let us know if we forgot to update a test? It seems that wpt10 on OS X Stylo opt/debug fails permanently. Do you think we can still consider that to be intermittent? Thanks.

Comment 28

[Christoph Kerschbaumer [:ckerschb]]

Attachment: bug_1324406_treat_data_documents_as_unique_opaque_origins.patch

Smaug, I think we are ready to flip the pref (assuming all of the errors we encounter on TRY can be attributed to be intermittents). Do we need an additional reviewer to sign off on this or are we good? What do you think?

Comment 29

[Christoph Kerschbaumer [:ckerschb]]

Here is another TRY run with the changesets from Bug 1392095 and Bug 1390434 applied:
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=21dc6a91ebc407326ecf42c1cd77ba7d0dcddb54

Comment 30

[Olli Pettay [:smaug][[e-mail]]]

Intent-to-ship to dev.platform would be good.

Comment 31

[Olli Pettay [:smaug][[e-mail]]]

ah, it is there.

Comment 32

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8899265 [details] [diff] [review]
bug_1324406_treat_data_documents_as_unique_opaque_origins.patch

Are there tests to ensure we have same data: handling also in workers as other browsers?

Comment 33

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Olli Pettay [:smaug] from comment #32)
> Are there tests to ensure we have same data: handling also in workers as
> other browsers?

I browsed through the workers wpt-tests; none of them are disabled (see grep for data: underneath).

@Ben, are there any other worker tests we should make sure to run correctly before we flip the pref so that data: URIs are treated cross origin with the including context?

@Anne, do you happen to know if there are any other tests we need to make sure we run correctly? Otherwise I think we are ready to go.

ckerschb@ckerschbdesktop:~/source/mc/testing/web-platform/tests/workers$ grep -r "data:" .
./data-url-shared.html:    var w = new SharedWorker(`data:${mime_type},onconnect = function(e) { port = e.ports[0]; ${worker_code}}`);
./data-url-shared.html:// 'data:' workers are cross-origin
./data-url-shared.html:// 'data:' workers have opaque origin
./constructors/Worker/same-origin.html:  var worker = new Worker('data:,postMessage(1);');
./constructors/SharedWorker/same-origin.html:  var worker = new SharedWorker('data:,onconnect = function(e) { e.ports[0].postMessage(1); }', '');
./interfaces/WorkerUtils/importScripts/006.html:  importScripts('data:text/javascript,x=1',
./interfaces/WorkerUtils/importScripts/006.html:                'data:text/javascript,throw 2',
./interfaces/WorkerUtils/importScripts/006.html:                'data:text/javascript,z=3');
./interfaces/WorkerUtils/importScripts/005.html:  importScripts('data:text/javascript,x={',
./interfaces/WorkerUtils/importScripts/005.html:                'data:text/javascript,}');
./interfaces/WorkerUtils/importScripts/009.html:importScripts('data:text/javascript,function run() { for(var i = 0; i < 1000; ++i) { if (i == 500) log(true); } return 1; }');
./interfaces/WorkerUtils/importScripts/007.html:importScripts('data:text/javascript,postMessage(1)');
./interfaces/WorkerUtils/importScripts/003.html:  importScripts('data:text/javascript,x+="b"',
./interfaces/WorkerUtils/importScripts/003.html:                'data:text/javascript,x+="c"');
./interfaces/WorkerUtils/importScripts/004.html:  importScripts('data:text/javascript,x+="first script successful. "',
./interfaces/WorkerUtils/importScripts/004.html:                'data:text/javascript,x+="FAIL (second script). "; for(;) break;', // doesn't compile
./interfaces/WorkerUtils/importScripts/004.html:                'data:text/javascript,x+="FAIL (third script)"');
./interfaces/WorkerUtils/importScripts/002.worker.js:    importScripts('data:text/javascript,ran=true','http://foo bar');
./interfaces/WorkerUtils/importScripts/008.html:importScripts('data:text/javascript,function run() { log(true) }');
./semantics/structured-clone/worker-common.js:        if (check_ImageData(input, {width:1, height:1, data:[0,0,0,0]})) {
./semantics/structured-clone/worker-common.js:        if (check_ImageData(input, {width:1, height:1, data:[100, 101, 102, 103]})) {
./semantics/structured-clone/worker-common.js:            check_ImageData(input[0], {width:1, height:1, data:[0,0,0,0]})) {
./semantics/structured-clone/worker-common.js:            check_ImageData(input[0], {width:1, height:1, data:[100, 101, 102, 103]})) {
./semantics/structured-clone/worker-common.js:              check_ImageData(input['x'], {width:1, height:1, data:[0,0,0,0]})) {
./semantics/structured-clone/worker-common.js:              check_ImageData(input['x'], {width:1, height:1, data:[100, 101, 102, 103]})) {
./semantics/structured-clone/worker-common.js:        if (check_ImageBitmap(input, {width:1, height:1, data:[0, 0, 0, 0]})) {
./semantics/structured-clone/worker-common.js:        if (check_ImageBitmap(input, {width:1, height:1, data:[100, 101, 102, 103]})) {
./semantics/structured-clone/worker-common.js:            check_ImageBitmap(input[0], {width:1, height:1, data:[0, 0, 0, 0]})) {
./semantics/structured-clone/worker-common.js:            check_ImageBitmap(input[0], {width:1, height:1, data:[100, 101, 102, 103]})) {
./semantics/structured-clone/worker-common.js:              check_ImageBitmap(input['x'], {width:1, height:1, data:[0, 0, 0, 0]})) {
./semantics/structured-clone/worker-common.js:              check_ImageBitmap(input['x'], {width:1, height:1, data:[100, 101, 102, 103]})) {
./semantics/navigation/001-1.html:<a href='data:text/html,<title>foo</title><script>onload=function(){window.parent.postMessage({title: window.document.title}, "*")}</script>'>link</a>
./data-url.html:    var w = new Worker(`data:${mime_type},${worker_code}`);
./data-url.html:    var w = new Worker(`data:${mime_type},${worker_code};postMessage("PASS")`);
./data-url.html:// 'data:' workers are cross-origin
./data-url.html:// 'data:' workers have opaque origin

Comment 34

[Anne (:annevk)]

In web-platform-tests there's these:

  workers/data-url-shared.html
  workers/data-url.html

Those were written as part of https://github.com/whatwg/html/pull/1782 which points to various issues where we agreed on data: URL handling across the board and across the various browsers (insofar they participated). Since it was in 2016 I don't think browser bugs were necessarily filed, we only started doing that consistently recently.

Comment 35

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #27)
> (In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)
> > https://treeherder.mozilla.org/#/
> > jobs?repo=try&revision=7ca5a6b268ccc2559cf5bf0246965631caf05e84
> 
> Carsten, we are about to flip the pref
> |security.data_uri.unique_opaque_origin| and push to inbound within the next
> couple days and hence we also pushed to TRY a couple times over the last few
> days. The link within this comment (see above) contains a few errors, but we
> *think* all of those errors are intermittents. Any chance you could take a
> look at the provided link and let us know if we forgot to update a test? It
> seems that wpt10 on OS X Stylo opt/debug fails permanently. Do you think we
> can still consider that to be intermittent? Thanks.

Checked with Aryx on IRC, he looked at this TRY push [1] and said that |Windows 7 debug (c2)| looks suspicious. We were already investigating that failure within Bug 1390434 but concluded that even without our changes that test seems to fail, see [2].


[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ca5a6b268ccc2559cf5bf0246965631caf05e84
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1390434#c10

Comment 36

[Ben Kelly [:bkelly, not reviewing]]

I guess I would look for uses of data: in dom/workers/test:

http://searchfox.org/mozilla-central/search?q=data%3A&case=false&regexp=false&path=dom%2Fworkers%2Ftest

And I think we might run this on workers as well:

http://searchfox.org/mozilla-central/source/dom/tests/mochitest/fetch/test_fetch_basic.js

Comment 37

[Christoph Kerschbaumer [:ckerschb]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f81d4a9a6137350d5eb98460a42e68a5b27dd7b4

Comment 38

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #27)
> (In reply to Christoph Kerschbaumer [:ckerschb] from comment #26)
> > https://treeherder.mozilla.org/#/
> > jobs?repo=try&revision=7ca5a6b268ccc2559cf5bf0246965631caf05e84
> 
> Carsten, we are about to flip the pref
> |security.data_uri.unique_opaque_origin| and push to inbound within the next
> couple days and hence we also pushed to TRY a couple times over the last few
> days. The link within this comment (see above) contains a few errors, but we
> *think* all of those errors are intermittents. Any chance you could take a
> look at the provided link and let us know if we forgot to update a test? It
> seems that wpt10 on OS X Stylo opt/debug fails permanently. Do you think we
> can still consider that to be intermittent? Thanks.

Carsten, in the end that ni? is not needed anymore. I checked with Aryx and we have pushed to TRY several times. This is ready!

Comment 39

[Christoph Kerschbaumer [:ckerschb]]

We are still investigating Bug 1392006, but we think we shouldn't wait with the pref flip. We will go ahead and push that change within this bug to inbound, but keep investigating Bug 1392006 at the same time.

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e8d712f190ba
Treat 'data:' documents as unique, opaque origins. r=smaug

Comment 41

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for failing talos tpaint test:

https://hg.mozilla.org/integration/mozilla-inbound/rev/498614f0f0658046ca51dd7feb9df90a7d5d4da6

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=e8d712f190baf68efa3d0ad45424a3092d1531ec&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=125324164&repo=mozilla-inbound

14:50:00     INFO -  TEST-START | tpaint
14:50:00     INFO -  Initialising browser for tpaint test...
14:50:00     INFO -  Application command: /builds/slave/test/build/application/firefox/firefox  http://localhost:36765/getInfo.html -profile /tmp/tmpy0JRJg/profile
14:50:00     INFO -  TEST-INFO | started process 15394 (/builds/slave/test/build/application/firefox/firefox  http://localhost:36765/getInfo.html)
14:50:05     INFO -  TEST-INFO | 15394: exit 0
14:50:05     INFO -  Browser initialized.
14:50:05     INFO -  Running cycle 1/1 for tpaint test...
14:50:05     INFO -  TEST-INFO | started process 15570 (/builds/slave/test/build/application/firefox/firefox -profile /tmp/tmpy0JRJg/profile -tp file:/builds/slave/test/build/tests/talos/talos/tests/tpaint/tpaint.manifest.develop -tpchrome -tpmozafterpaint -tpnoisy -tpcycles 1 -tppagecycles 20)
14:50:06     INFO -  PID 15570 |
14:50:06     INFO -  PID 15570 | (/builds/slave/test/build/application/firefox/firefox:15620): Pango-WARNING **: error opening config file '/home/cltbld/.pangorc': Permission denied
14:50:06     INFO -  PID 15570 |
14:50:07     INFO -  PID 15570 |
14:50:07     INFO -  PID 15570 | (/builds/slave/test/build/application/firefox/firefox:15675): Pango-WARNING **: error opening config file '/home/cltbld/.pangorc': Permission denied
14:50:07     INFO -  PID 15570 |
14:50:07     INFO -  PID 15570 | __metrics	Screen width/height:1600/1200
14:50:07     INFO -  PID 15570 | 	colorDepth:24
14:50:07     INFO -  PID 15570 | 	Browser inner width/height: 1024/768
14:50:07     INFO -  PID 15570 | __metrics
14:50:16     INFO -  PID 15570 | RSS: Main: 177057792
14:50:16     INFO -  PID 15570 |
14:55:05     INFO -  Timeout waiting for test completion; killing browser...
14:55:05     INFO -  Terminating psutil.Process(pid=15570, name='firefox')
14:55:05     INFO -  PID 15570 | ExceptionHandler::GenerateDump cloned child 15745
14:55:05     INFO -  PID 15570 | ExceptionHandler::SendContinueSignalToChild sent continue signal to child
14:55:05     INFO -  PID 15570 | ExceptionHandler::WaitForContinueSignal waiting for continue signal...
14:55:05     INFO -  TEST-UNEXPECTED-ERROR | tpaint | timeout
14:55:05    ERROR -  Traceback (most recent call last):
14:55:05     INFO -    File "/builds/slave/test/build/tests/talos/talos/run_tests.py", line 279, in run_tests
14:55:05     INFO -      talos_results.add(mytest.runTest(browser_config, test))
14:55:05     INFO -    File "/builds/slave/test/build/tests/talos/talos/ttest.py", line 61, in runTest
14:55:05     INFO -      return self._runTest(browser_config, test_config, setup)
14:55:05     INFO -    File "/builds/slave/test/build/tests/talos/talos/ttest.py", line 201, in _runTest
14:55:05     INFO -      if counter_management else None),
14:55:05     INFO -    File "/builds/slave/test/build/tests/talos/talos/talos_process.py", line 127, in run_browser
14:55:05     INFO -      raise TalosError("timeout")
14:55:05     INFO -  TalosError: timeout

Comment 42

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) from comment #41)
> Backed out for failing talos tpaint test:

Thanks - I filed Bug 1393350 to get that test updated.

Comment 43

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cd36476dd8b3
Treat 'data:' documents as unique, opaque origins. r=smaug

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/cd36476dd8b3

Comment 45

[Kohei Yoshino]

Given that this behaviour matches other browsers, it shouldn't break sites IIUC. But extensions are apparently affected, as reported in Bug 1392006.

Comment 46

[Chris Mills [:cmills]]

To document this, I've added a note to the Data URLs page

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs

and a note to the Fx57 rel notes:

https://developer.mozilla.org/en-US/Firefox/Releases/57#Other

Do these look OK?

Comment 48

[Ethan Tseng [:ethan]]

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #46)
> To document this, I've added a note to the Data URLs page
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
> and a note to the Fx57 rel notes:
> https://developer.mozilla.org/en-US/Firefox/Releases/57#Other
> Do these look OK?

Thanks for adding these.

In my opinion, this should fit in the Security section (in the release notes).
This change fixed a vulnerability in Firefox.
Before we treated data: URL scheme as a unique opaque origin, attackers might be able
to launch cross-site scripting (XSS) attacks using data: URL scheme.

Comment 49

[Chris Mills [:cmills]]

(In reply to Ethan Tseng [:ethan] - 57 Regression Engineering Support from comment #48)
> (In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #46)
> > To document this, I've added a note to the Data URLs page
> > https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
> > and a note to the Fx57 rel notes:
> > https://developer.mozilla.org/en-US/Firefox/Releases/57#Other
> > Do these look OK?
> 
> Thanks for adding these.
> 
> In my opinion, this should fit in the Security section (in the release
> notes).
> This change fixed a vulnerability in Firefox.
> Before we treated data: URL scheme as a unique opaque origin, attackers
> might be able
> to launch cross-site scripting (XSS) attacks using data: URL scheme.

No worries - that makes sense. I've moved it.

Comment 52

[Aleksey F.]

Thus you broke XML-XSL-SVG applications that used a simple JS stub for processing internal requests into xml requests and put them directly to window.location. And what is more important, those applications worked locally and via a web server using a web browser as an ordinary viewer for local files like Adobe Acrobat Reader. Please see the result of your interpretation of the same origin policy regarding data protocol in the bug 1676008.

So, why don't just acknowledge that the idea of the same origin policy is completely wrong and just break required things instead of achieving its declared purposes? Why to follow wrong decisions making benefits just for corporations like Google that force users to migrate to their online infrastructure and stop using any local and independent data/applications? Security is useless when there is nothing to defend when security means made the target things impracticable.