Open Bug 1730535 Opened 1 year ago Updated 5 months ago

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


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





(Reporter: dveditz, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: [domsecurity-backlog2])


(3 files)

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

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

Priority: -- → P3
Whiteboard: [domsecurity-backlog2]
See Also: → 1730419
Attached image file-load-localhost.png
Attached image file-load-file.png

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. ☺

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

No longer depends on: 1732052
See Also: → 1732052

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.

See Also: → 1536596

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

Depends on: 1511209

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?

(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.

(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.

You need to log in before you can comment on or make changes to this bug.