1730535 - Remove the security.fileuri.strict_origin_policy pref, always require unique origins

Status: NEW

(Core :: DOM: Security, task, P3)

Description

[Daniel Veditz [:dveditz]]

The security.fileuri.strict_origin_policy pref was added as an escape-valve to unbreak folks who were not ready for us to treat file: URLs as unique origins. It's been years now and all the major browsers treat file: urls this way, and no one is worrying about making sure new features work when this is set to false (or worrying how insecure that feature might be in that configuration).

It's also far easier than it used to be for developers to launch a local no-configuration-required web server on your development directory for a site that's simple enough to be developed as a collection of file: urls. For example:

Python 3:
> python -m http.server 8080

Node:
> http-server (after > npm install http-server -g if not already installed)

Comment 1

[Masatoshi Kimura [:emk]]

This pref no longer makes sense because a stricter pref privacy.file_unique_origin has been removed.

Comment 2

[ettavolt]

Attachment: file-origin-Debugger.png

Comment 3

[ettavolt]

Attachment: file-load-localhost.png

Comment 4

[ettavolt]

Attachment: file-load-file.png

Comment 5

[ettavolt]

I'm voting against completely disabling XHR to file://, it is very useful for locally debugging RIAs.

My case is ExtJS-based RIA. While debugging I use a feature of automatic loading based on classes 'requires' definition (ofc, I pack it before deploying). This way I get all the files (see file-origin-Debugger.png), not mangled in the Debugger panel of DevTools. From here I can easily navigate to one of the 500 classes by invoking Ctrl+P (go to file) instead of looking through all the usages with Ctrl+Shift+F (find in files). More over, I don't need to wait while Debugger parses (additionally) source maps or formats 100k+ lines file.

However, even when all files are cached it takes 8-9 seconds for i5-7300HQ+NVMe to reload! (See file-load-localhost, web server is NginX). In contrast to less than a second when loading from file:// (see file-loading-file, second timestamp is output after motd request).

Of course, this is a niche approach, you can't do that with node_modules yet.

With file:// cache is not an issue any more too: no force reloading what has not changed, no confusion why the changes are not there (though must-revalidate might help, but that's additional configuration I must not forget to add in the new project).

As for an ability to run XHRs to file://: this project wants to load a sibling motd file and the other is loading a required sibling JSON file with some runtime configuration.

So, please keep a property to support file:// XHRs.

Do I understand correctly, that security.fileuri.strict_origin_policy allows to XHR-access files outside the HTML file's directory? And the now-removed privacy.file_unique_origin controlled XHR access to sibling files and directories? If so, my vote is to return privacy.file_unique_origin instead of retaining security.fileuri.strict_origin_policy. Bug 1665056 says security.fileuri.strict_origin_policy is used to share top-level directory resources when testing Firefox itself. Maybe test suits could use privacy.file_unique_origin after symlinking those resources as siblings?

P.S. PACE on screenshots is not Parliamentary Assembly of the Council of Europe. ☺

Comment 6

[Masatoshi Kimura [:emk]]

Oh, I didn't think security.fileuri.strict_origin_policy still works.

Comment 7

[Jens Stutte [:jstutte]]

One of the untested effects can still be seen in bug 1536596. I'd really recommend to remove it entirely. See the rationale in bug 1730419 comment 12. Developing a web-app in an untested configuration seems something to be avoided whenever possible.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Note that I think until bug 1511209 is fixed, removing/disabling the pref will break a bunch of reftests.

Comment 10

[travneff]

Came here after long googling how to open saved webpage with proper styles. Some answers advise to run a local web server >_<
Have a lot of messages like this in FF console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///home/andrew/20220711_0055_files/2ccFOXW60ck.js. (Reason: CORS request not http).

Toggling the subject parameter fixed it.
How could I do the same after its removal?

Comment 11

[Jens Stutte [:jstutte]]

(In reply to travneff from comment #10)

Came here after long googling how to open saved webpage with proper styles. Some answers advise to run a local web server >_<

This is indeed also our recommendation, see comment 0.

Comment 12

[travneff]

(In reply to Jens Stutte [:jstutte] from comment #11)

This is indeed also our recommendation, see comment 0.

Developers could do that, but they are 1 of 10 people saving pages, I think. So seems like it will be just a broken feature for average user.
Seems same for Chrome, though.

Saving to PDF is "better than nothing" but not a good alternative since conversion looses a lot of info from the page.

Comment 13

[firefoxbugs]

The premise of this bug is just dumb. The idea is to break a working feature simply because you perceive the only people who might want to open a multi-file project are "developers" (totally false). And what's your solution for these developers? Run a third-party no-configuration local HTTP server. Obviously, as pointed out, this adds a ridiculous level of complication and inefficient overhead, which is undesirable for people working on projects that were never at any point intended to be distributed over HTTP.

Obviously, complexity and inefficiency are not the only problems! Files on a local machine can only be opened according to the file permissions set on them. And your idea of a solution is to just launch an HTTP server so that any account on the entire system can have access to those files? Huh?? Are you solving security problems, or making them?

You're not addressing a security issue; you're just breaking a feature so that people have to figure out the security themselves. With things the way they are currently, it's plenty easy to have one profile for regular browsing that just has security.fileuri.strict_origin_policy set to its default of true and then have another profile for an offline project where it's set to false, and which might even be locked down further with network.online as false. (Good luck setting network.online to false if you you have to run a dang HTTP server just to open a local file.)

All the things that need fixing in Firefox, and you're busy trying to break existing features. I just don't get it.

I'm not saying the behavior couldn't be tweaked. For example, in bug 1565220 comment 2, Benedikt Schindler suggested having a folder whitelist, which is something I'd thought about also. This would allow people to view offline and online projects in the same browser instance without the security issues of a single setting like security.fileuri.strict_origin_policy that breaks security for everything when set to false. It also makes security tighter by not simply allowing access to any file anywhere but only to whitelisted ones. Obviously, like any feature, that would take a bit of resources to implement. But in the meantime, please don't break things that already work.

Comment 14

[Vincent Lefevre]

Starting a local web server with no configuration as suggested in comment 0 would introduce a critical vulnerability: since no authentication is done by default, other users on the machine would be able to read private files!

Comment 15

[Vincent Lefevre]

(In reply to Vincent Lefevre from comment #14)

Starting a local web server with no configuration as suggested in comment 0 would introduce a critical vulnerability: since no authentication is done by default, other users on the machine would be able to read private files!

And even from other machines! (I've just tried.)