Last Comment Bug 357323 - DOM Storage (sessionStorage) doesn't work in file:// pages
: DOM Storage (sessionStorage) doesn't work in file:// pages
Status: RESOLVED DUPLICATE of bug 507361
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: ---
Assigned To: Honza Bambas (:mayhemer)
: 358886 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-10-19 14:53 PDT by Alfonso Martinez
Modified: 2013-04-04 13:53 PDT (History)
22 users (show)
jonas: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase: it should work here, but will fail loading from localhost or loading it as file:// (2.03 KB, text/html)
2006-10-19 14:56 PDT, Alfonso Martinez
no flags Details
testcase2, using globalStorage[''] (2.11 KB, text/html)
2007-02-02 07:10 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
patch for enableprivilege (7.77 KB, patch)
2007-02-05 07:39 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details | Diff | Review
allow use of storage in chrome (2.99 KB, patch)
2007-02-21 11:12 PST, Neil Deakin
no flags Details | Diff | Review

Description Alfonso Martinez 2006-10-19 14:53:54 PDT
Testing the new Storage system I can't make it work if the page is loaded from a localhost server or loading the file directly, but putting an alias -> in the hosts file makes the page work under that domain, so the code of the page seems to be right

Following a testcase grabbed from

Firefox 2.0RC3
Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1) Gecko/20061010 Firefox/2.0
Comment 1 Alfonso Martinez 2006-10-19 14:56:08 PDT
Created attachment 242807 [details]
testcase: it should work here, but will fail loading from localhost or loading it as file://

testcase, and yes, I forgot to paste the error:
uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://localhost/domstorage.htm Line: 34"]
Comment 2 Alfonso Martinez 2006-10-20 13:29:23 PDT
I've been searching LXR and it's pointing in that this is due to bug 342314, but I'm testing again and it also fails using so I'm not sure about marking this bug blocked by 342314
Comment 3 :Gavin Sharp [email:] 2006-10-31 06:19:13 PST
*** Bug 358886 has been marked as a duplicate of this bug. ***
Comment 4 Jonas Sicking (:sicking) 2007-02-01 12:23:46 PST
One problem here is doing this in a safe way. How do we define domains for file urls such that not any "file://-file" can read data saved by any other "file://-file"?
Comment 5 Alessandro Curci 2007-02-02 02:24:33 PST
(In reply to comment #4)
Obviously locking a globalStorage entry to the file path that originated that entry isn't feasible as the file path could be changed at any time.
So, what about encryption?
As I've seen that any globalStorage entry is available in clear text, using for example, I started hashing data with a username password combo, using the username's MD5 hash as key.
That was done on the JS level merging and customizing a couple of libraries for my purpose:

IMHO The whole domain/crossdomain data access issue and paranoia is being seen from a wrong point of view, as data is pertinent to people, not to domains.

Data encryption could be done better at a lower level, granting that only a particular user has access to it's own data.

my 0.02EU
Comment 6 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-02-02 06:57:49 PST
I tested and that is just working fine for me.

If the script's domain contains no dots (U+002E) then the string ".localdomain" must be appended to the script's domain.
So for http://localhost, you need to use globalStorage['localhost.localdomain'], I tested that, and it works.
See also bug 341524, comment 20.
So I'm removing the 'localhost' part of the summary, because it is working as intended.
Comment 7 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-02-02 07:10:33 PST
Created attachment 253751 [details]
testcase2, using globalStorage['']

This uses var storage = globalStorage[''];, which is basically what the previous testcase is doing on the local computer. This is also raising a security exception.

According to:
If the normalised requested domain  is the empty string, then the rest of this algorithm can be skipped. This is because in that situation, the comparison of the two arrays below will always find them to be the same — the first array in such a situation is also empty and so permission to access that storage area will always be given.
I think this applies to this case.

Unfortunately in nsDOMStorageList::NamedItem, aDomain seems to become suddenly 'length' (?!) when globalStorage[''] is used. Some kind of weird xpconnect conversion?
Comment 8 Jonas Sicking (:sicking) 2007-02-02 14:23:57 PST
I don't see how encryption solves anything. If we encrypt the data when storing it we'll have to decrypt it before returning it so that won't accomplish anything. We could of course require you to supply a crypto key, but if you're trying to hack another websites files saved to disk you can simply look in their source to see what key they use.
Comment 9 Alessandro Curci 2007-02-03 05:03:48 PST
The problem seems rather complex, I can just offer some thoughts:

If I don't miss somenthing, the whole DOM and JS layer is exposed for pubblic consultation to all those libraries included in the XHTML source, so if someone includes a third party API on a page (eg: Google Maps) all that page's domain data is exposed to them. What about FF extensions? Who trust who?

It's not time to sign scripts and grant theme, or not, access to some particular data?

If something like a FF Operator (MozLabs;) collects and stores meaningfull information found while surfing net, who should have access to?

Another thing that comes to my mind about what encrypting data would solve is that data can be stolen from outside Firefox, where FF domain policies doesn't matter. That's the same with many other apps out there, but why not keep moving on a next level of privacy?
Comment 10 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2007-02-05 07:39:00 PST
Created attachment 254027 [details] [diff] [review]
patch for enableprivilege

This patch makes it possible to use enablePrivilege for local files for globalStorage.
I'm not sure if this is really a correct patch, the checks are quite scattered, but it seems to me that when you have system privileges, you should never get a NS_ERROR_DOM_SECURITY_ERR error.
Comment 11 Neil Deakin 2007-02-21 11:10:56 PST
The code in GetStorageForDomain still needs to happen for file/chrome access.

The privileged checks could be moved into IsCallerSecure and a boolean flag for read/write passed to it.
Comment 12 Neil Deakin 2007-02-21 11:12:18 PST
Created attachment 255924 [details] [diff] [review]
allow use of storage in chrome

This patch in a work in progress patch which supports use of storage in chrome, which could be incorporated into the other patch.
Comment 13 Jonas Sicking (:sicking) 2007-02-22 16:33:53 PST
WhatWG needs to come up with a spec for this before we can do anything. Once that's done this'd be nice to have for sure.
Comment 14 Hixie (not reading bugmail) 2007-02-22 16:36:40 PST
I don't really have any intention of trying to come up with a way for this to work for file://, since for file:// interoperability isn't needed (file:// isn't over the network). If people want to come up with something, it can be added non-normatively to the spec, if it's secure. But why not just use http://localhost/?
Comment 15 Jonas Sicking (:sicking) 2007-02-22 17:33:23 PST
using 'localhost' wouldn't solve the problem of all files being able to read anything any other file has stored.

Why is this not needed interoperably? Seems like a lot of people would save stuff to their filesystem that they've seen on the web.
Comment 16 Hixie (not reading bugmail) 2007-02-22 17:36:27 PST
I meant why not serve the relevant stuff straight off localhost.
I am doubtful that an application written for HTTP would work if just downloaded and run on file:// without many other changes.
Interoperability is not needed because once the file is on a single system, only that system is relevant.
If you want to support offline browsing, that's a whole different kettle of fish.
Comment 17 Jonas Sicking (:sicking) 2007-02-22 18:01:37 PST
Yeah, offline browsing is very different. There the files will still be accessed through a http:// uri and so things will work as normal.

In any event. If someone wants this to work please write up a suggested design and submit to whatwg.
Comment 18 Honza Bambas (:mayhemer) 2008-09-19 13:45:03 PDT
As I think of this turning file path to distinct domains is not a solution here. Then we would have two major issues that are far from how pages on server behave:

1. we have to set (and let user confirm on each UA session) UniversalBrowserWrite, what breaks the code when load from an http server
2. there is always different localStorage object for each sub-directory when walking/traversing the structure of local files, what is also quit different from what would be expected when load from a server

Then there is a following inconsistency: nsIPrincipal.origin returns for _any_ file URL just "file://", omitting the path completely. But nsIPrincipal.checkMayLoad, in the default implementation, checks the target file is contained in the codebase directory (or one of its sub-directories).

I personally would more tend to let local files share just a single storage and quota for a whole file system.

WHATWG doesn't say a lot about this, there is also some inconsistency in origin definition:

3. If url does not use a server-based naming authority (that is, doesn't have a [user@]domain[:port], what file:// urls don't have), or [...] then _return a new globally unique identifier_.

6. If scheme is "file", then the user agent may return a _UA-specific value_. 

Step 3 would not allow me to get to step 6, right?
Comment 19 Honza Bambas (:mayhemer) 2008-09-24 03:19:57 PDT
The best would be able to say that a particular file system directory containing an offline application is a distinct domain and all what is located inside this directory or any of its sub-directory belongs to this domain, i.e. has storage bound to that directory and also uses that directory's quota. The rest that is above such directory uses the global file quota and storage - domain is the whole file system.

To achieve such distinction of directories we can use "offline-app" privilege allowed for it. It is currently broken for local files (could not add that privilege, even UI offered to, permission manager fails with NS_ERROR_UNEXPECTED).

Also, why we need to allow UniversalBrowserWrite for local files to write to  localStorage/globalStorage when there is no need for web pages to have that permission?

I would like to work on this all if you agree on this proposal. Otherwise I could post the proposal to WHATWG.
Comment 20 Nickolay_Ponomarev 2009-09-19 13:27:43 PDT
bug 371127 - (FIXED) globalStorage from chrome://
bug 495747 - localStorage from chrome://
bug 507361 - localStorage from file://
bug 357323 - sessionStorage from file://
bug 480366 - sessionStorage from chrome://
bug 495337 - "Make sessionStorage use principals instead of string domains."
Comment 21 Sonny Piers [:sonny] 2011-09-11 15:29:53 PDT
The issue has been resolved, see:
Comment 22 Honza Bambas (:mayhemer) 2011-09-12 13:16:36 PDT
I think we can dup this.

If there are any more demands around this topic, please open new bugs.

*** This bug has been marked as a duplicate of bug 507361 ***

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