ابحث في الدعم

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Unable to share local storage beween pages loaded from the file system using file protocol

  • 4 ردود
  • 1 has this problem
  • 14 views
  • آخر ردّ كتبه traktor

more options

In previous versions of Firefox I was able to save items in local storage in one HTML file and read them back in another HTML file when both files were loaded from the same file system directory of the local machine.

Version 92 seems to have implemented a breaking change where separate local storage tables are created for pages loaded from the file system based on their file path - meaning a page can only access local storage items set from the same window location used to open the file from disk

As far as I can tell the change has not been mentioned in release notes , nor does it appear to be part of a bug or enhancement request filed on Bugzilla (that I was able to find in searching), nor are local page names entered as "sites" to allow management of their storage under security and privacy settings.

I have a workaround for my particular needs - rename a local system main page to something else, rename a setup page to the main page, make setup changes and store them from within the renamed setup page, then undo the file renames so the main page can load updated setup data, but t qhe phrase "ugly hack" comes to mind.

Before launching on a major rewrite in search of a better solution, or helping friends set up a node/express server on their devices, is there any way to re-enable sharing of local storage between HTML pages loaded from the file system?

In previous versions of Firefox I was able to save items in local storage in one HTML file and read them back in another HTML file when both files were loaded from the same file system directory of the local machine. Version 92 seems to have implemented a breaking change where separate local storage tables are created for pages loaded from the file system based on their file path - meaning a page can only access local storage items set from the same window location used to open the file from disk As far as I can tell the change has not been mentioned in release notes , nor does it appear to be part of a bug or enhancement request filed on Bugzilla (that I was able to find in searching), nor are local page names entered as "sites" to allow management of their storage under security and privacy settings. I have a workaround for my particular needs - rename a local system main page to something else, rename a setup page to the main page, make setup changes and store them from within the renamed setup page, then undo the file renames so the main page can load updated setup data, but t qhe phrase "ugly hack" comes to mind. Before launching on a major rewrite in search of a better solution, or helping friends set up a node/express server on their devices, is there any way to re-enable sharing of local storage between HTML pages loaded from the file system?

All Replies (4)

more options

If you have a lot of bandwidth, you can run a Mozregression to pinpoint the patch that changed the behavior. You probably want to choose the "reuse profile" option so you only have to store the local data once.

https://mozilla.github.io/mozregression/


But based on a hunch, I discovered it is linked to a longstanding privacy preference:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.

(2) In the search box above the list, type or paste privacy.file_unique_origin and pause while the list is filtered

(3) Double-click the preference to switch the value from true to false

This preference was introduced in Firefox 68 to address CVE-2019-11730 (https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730) to resolve the issue that all local files in the same folder had "same-origin" privileges to one another's content and data.

If you disable this protection, here is how you can mitigate the vulnerability this patch addressed:

Save pages from untrusted sites in a completely separate folder, e.g., Downloads\Untrusted. That would make it difficult for an attacker to find any valuable content using local file links. You also can save pages from sensitive sites in a their own folders, e.g., Downloads\MyBank, Downloads\MyEHR, etc., to minimize unintended data sharing.

more options

Thank you for your reply - the preference is not something I would have found myself.

Unfortunately changing the privacy.file_unique_origin setting in `about:config` had no effect: after copying a test page and pasting it in the same folder (Windows gives it a "- Copy" file name suffix), the local storage values of one page could no be seen in the other: they stayed using their own separate db tables. The configuration item may be obsolete in any case - the project pages of concern were using each others' local storage up until version 92 was pushed to Australia a few days ago.

Since posting I discovered MDN's local storage article (at least as of yesterday) includes coverage of the lack of standards surrounding file:// protocol pages' use of local storage, ending with the sentence "So it’s possible that browsers may change their file: URL handling for localStorage at any time. In fact some browsers have changed their handling for it over time" (without mentioning Firefox did so a day or so ago).

For myself I will press on with changes to make the project a single page app at the cost of marrying parts that are still under separate development and testing.

The only real solution I can think of would be for browsers to offer an option to "map folder to origin" so by default pages would not be able to read each others storage unless the user placed them in a folder explicitly set up to do so - complete with management tools that didn't involve uses opening about:config of course ;-)

more options

That preference worked like a switch for me. I don't know what else might be different between our configurations.

more options

My experience is that

Under Firefox 90.0(32 bit) under Window7, the switch isn't needed - privacy.file_unique_origin is true and file:// URL pages share the same local storage (table).

Firefox 90.0(64 bit) under Windows 10 behaved the same way - I had not even heard of this configuration option. After two recent updates, Firefox 92.0(64 bit) under Windows 10 will not share local storage no matter what the privacy option is set to.

If readership is interested I've uploaded a test page (localstore.html) to GitHub to determine actual browser behavior.