Bug 1566172 (file-fallout)

Compare file:// behavior of all places that use same-origin-only or cors-only loads to other browsers

RESOLVED FIXED

Status

()

defect
P1
normal
RESOLVED FIXED
Last month
14 days ago

People

(Reporter: bzbarsky, Assigned: baku)

Tracking

(Depends on 4 bugs, Regression, {regression, site-compat})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox-esr6868+ fixed, firefox68+ fixed, firefox69+ fixed, firefox70+ fixed)

Details

(Whiteboard: [domsecurity-active])

Attachments

(1 obsolete attachment)

STEPS TO REPRODUCE:

  1. Download https://mdn.mozillademos.org/files/7775/webfont-sample.html to a file named "test.html" on local disc.
  2. Download https://mdn.mozillademos.org/files/2468/VeraSeBd.ttf to a file named "test.ttf" in the same directory.
  3. Edit "test.html" so the CSS url() bit says url("test.ttf")
  4. Load "test.html" in Firefox.

EXPECTED RESULTS: The text is bold like is is on https://mdn.mozillademos.org/files/7775/webfont-sample.html

ACTUAL RESULTS: The text is not bold.

ADDITIONAL INFORMATION:

  • In Firefox 67, this worked as long as the font file was a sibling, or under a sibling, of the HTML (or CSS?) file, due to the way our same-origin policy worked. It did not work if the font was a child of some unrelated or ancestor dir (e.g. if the font file is placed in /tmp and the HTML in ~, it does not work in 67).
  • In Firefox 68, this does not work due to the changes in bug 1558299
  • I just tested Chrome and Safari, and they allow linking from any file:// to any other file:// for fonts, afaict. Presumably a legacy of them not doing CORS enforcement at all for web fonts? (Or do they still not do CORS enforcement there?)

Anyway, this is causing compat issues; see bug 1500453 comment 14.

I had assumed we had audited all consumers of SEC_REQUIRE_SAME_ORIGIN* and SEC_REQUIRE_CORS* in bug 1558299 to see how other browsers behave for them for file:// URLS, but apparently not. Those consumers are:

  • SVG external resources
  • fetch()
  • HTML <track> elements
  • font-face rules (this bug)
  • <a ping> bits
  • Service worker script cache bits of some sort
  • DOM workers
  • XMLDocument.load (not supported in other browsers, iirc)
  • Offline cache manifests
  • EventSource
  • Navigator.sendBeacon
  • HTML media elements with crossorigin attr set
  • ChannelMediaResource
  • HTML <script> elements with crossorigin attr set
  • Module scripts
  • Various XSLT stuff (maybe not supported in other browsers?)
  • Stylesheet linking elements with crossorigin attr set
  • Various image-loading element with crossorigin attr set
Flags: needinfo?(dveditz)
Flags: needinfo?(amarchesini)

OK, looks like bug 1565942 tracks the file:// thing already. Mutating this to cover auditing the rest of the list.

Depends on: 1565942
Summary: @font-face has stopped working over file:// URIs; works in other browsers → Compare file:// behavior of all places that use same-origin-only or cors-only loads to other browsers

broken xslt stuff got reported a number of times after the 68 release (bug 1565261 and dupes)

Posted file replay to a comment... (obsolete) —
Comment on attachment 9078262 [details]
replay to a comment...

I don't know why bugzilla decided to create an attachment...
Attachment #9078262 - Attachment is obsolete: true
Flags: needinfo?(amarchesini)
  • HTML <script> elements with crossorigin attr set: No CORS. No loading. Same on other browsers.
  • Module scripts: Basically impossible to test...
  • fetch(): No CORS: The requests fail. Same on other browsers.
  • <a ping> bits: No CORS. Ping attribute fails the loading. What's the point of loading a file: URLs, btw?
  • Service worker script cache bits of some sort: Not interesting. ServiceWorkers are exposed just for http and https.
  • DOM workers: No CORS supported here. DOM Workers are basically disabled for file: URLs. Tested in other browsers.
  • EventSource: Basically disabled. No CORS supported. Tested in other browsers.
  • Navigator.sendBeacon: Exposed just for http/https. Same on other browsers.
  • HTML media elements with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.
  • Various image-loading element with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.
  • XMLDocument.load (not supported in other browsers, iirc): Untested.
  • Various XSLT stuff (maybe not supported in other browsers?): Untested.
  • ChannelMediaResource: Not an issue. We use FileMediaResource if the channel implements nsIFileChannel: https://searchfox.org/mozilla-central/rev/07f7390618692fa4f2a674a96b9b677df3a13450/dom/media/BaseMediaResource.cpp#49-50
  • HTML <track> elements: We don't load the media element... this cannot be tested.
  • Offline cache manifests: Only for HTTPS...
  • Stylesheet linking elements with crossorigin attr set: This works in firefox and in other browsers...
  • SVG external resources: Blocked by CORS. Same for other browsers.
  • font-face rules (this bug): This bug...
  • Various XSLT stuff (maybe not supported in other browsers?): No CORS. Similar to other browsers.

Module scripts: Basically impossible to test...

Why can't this work as a test, loaded from file:/// ?

  <script type="module">
    import "./test.js";
  </script>

What's the point of loading a file: URLs, btw?

Probably none. I was just going through the tree listing all the places that do CORS-only or same-origin-only loads.

HTML media elements with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.
Various image-loading element with crossorigin attr set: Similar to <script> no CORS. Same on other browsers.

OK, so these don't get loaded in both Firefox and other browsers? Or does get loaded? For <script> you said it does not get loaded?

Stylesheet linking elements with crossorigin attr set: This works in firefox and in other browsers...

I don't think it works (in the sense of being loaded) in Firefox, on trunk. Testcase, with test.css containing * { color: green}:

<link rel="stylesheet" crossorigin href="test.css">
Is this green?

Looks like this does not load in other browsers either.

SVG external resources: Blocked by CORS. Same for other browsers.

Those don't use CORS at all that I am aware of... They're just restricted to same-origin.

Various XSLT stuff (maybe not supported in other browsers?): No CORS. Similar to other browsers.

It's not CORS; it's restricted to same-origin, right? Does it load in other browsers, or not? That is, what is the right disposition for bug 1565261 and its duplicates?

Flags: needinfo?(amarchesini)

Ah, I guess bug 1565261 says the XSLT case does not work in other browsers. Amazing how many duplicates we have from people who only did that in Firefox....

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #9)

Ah, I guess bug 1565261 says the XSLT case does not work in other browsers. Amazing how many duplicates we have from people who only did that in Firefox....

IE 11 and Edge on Windows do load and apply an XSLT stylesheet referenced via xml-stylesheet in an XML documents loaded from the local file system if the stylesheet is also on the local file system.

Module scripts: Basically impossible to test...
Why can't this work as a test, loaded from file:/// ?

oh! right. I was thinking about 'import' module directive, and because a script cannot be loaded, 'import' doesn't run.

  <script type="module">
    import "./test.js";
  </script>

This is handled by the same ScriptLoader component. It behaves like a 'script' loading and it's not supported because of CORS.

Stylesheet linking elements with crossorigin attr set: This works in firefox and in other browsers...

Correct: it doesn't work with 'crossorigin' attr set. Without it works. And I confirm we have the same behavior of chrome.

Various XSLT stuff (maybe not supported in other browsers?): No CORS. Similar to other browsers.
It's not CORS; it's restricted to same-origin, right? Does it load in other browsers, or not? That is, what is the right disposition for bug 1565261 and its duplicates?

Correct. And XSLT do not apply on file: URLs in firefox. And in Chrome too. Both block the loading of the XSLT resources.

Flags: needinfo?(amarchesini)

IE 11 and Edge on Windows do load and apply an XSLT stylesheet

Does that include Chromium-based Edge?

Anyway, it sounds like bug 1565942 definitely needs fixing, bug 1565261 is likely wontfix (though it sure has a lot of dups), and we need to sort out what to do with bug 1565509. I had missed the bug 1565509 codepath in my audit because I had not noticed that CSS images can end up doing CORS....

Flags: needinfo?(martin.honnen)
Alias: file-fallout
Flags: needinfo?(dveditz)
Assignee: nobody → amarchesini
Priority: -- → P1
Whiteboard: [domsecurity-active]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #12)

IE 11 and Edge on Windows do load and apply an XSLT stylesheet

Does that include Chromium-based Edge?

Sorry, I haven't used that so far, the tested version is Microsoft Edge 44.18362.1.0/Microsoft EdgeHTML 18.18362 on Windows 10 1903.

Flags: needinfo?(martin.honnen)

Keywords: site-compat

dubious, we're talking about local file:// urls which are by definition NOT sites on the web. "DevAdvocacy" maybe? We don't seem to have a "tool-compat".

Yeah, technically it’s not site compatibility but I’ve already documented this: https://www.fxsitecompat.dev/en-CA/docs/2019/local-files-are-now-each-given-a-different-origin/ (will add more examples as mentioned in Comment 5)

I think we can close this bug. The only open issue was about font, fixed with bug 1565942. For XSLT we have a separate bug too.
bz, are you OK with closing this?

Flags: needinfo?(bzbarsky)

Yep.

Status: NEW → RESOLVED
Closed: 26 days ago
Flags: needinfo?(bzbarsky)
Resolution: --- → FIXED
Type: defect → task
Depends on: 1570629
Depends on: 1565672
You need to log in before you can comment on or make changes to this bug.