window.localStorage and .sessionStorage deliberately broken for file:// URLs?
I'm working on an application that's distributed as a single HTML file containing JavaScript, intended to be saved locally. The JavaScript then makes various XMLHttpRequests to the network, to provide security properties that a normal web application can't. That's kind of hacky (vs. doing it as a browser extension or whatever), but I was hoping that would make it easy to install in hardened, mostly-read-only OS installations. That works in stock Firefox. It doesn't work in Tor Browser, because window.localStorage (and .sessionStorage) fail for file:// URLs. Is that deliberate? They work for http:// and https:// URLs, so it doesn't seem like a security decision. Thanks.
dev942@sigaint.org:
I'm working on an application that's distributed as a single HTML file containing JavaScript, intended to be saved locally. The JavaScript then makes various XMLHttpRequests to the network, to provide security properties that a normal web application can't. That's kind of hacky (vs. doing it as a browser extension or whatever), but I was hoping that would make it easy to install in hardened, mostly-read-only OS installations.
That works in stock Firefox. It doesn't work in Tor Browser, because window.localStorage (and .sessionStorage) fail for file:// URLs.
Is that deliberate? They work for http:// and https:// URLs, so it doesn't seem like a security decision.
I don't think this is deliberate. Could you file a bug on trac.torproject.org in the Tor Browser component describing the issue there? Adding example code showing the problem would be very helpful as well. Thanks, Georg
participants (2)
-
dev942＠sigaint.org -
Georg Koppen