So to summarize, localStorage is following strictly the cookie policy,
the Tor Browser does not save it to the disk and has implemented a patch
for this and to fix the FF bug for third party localStorage.
But localStorage is not only about cookie-like uses.
I understand that the philosophy is not to break the sites as far as
possible, now I don't see what is so valuable in DOM storage to desserve
these efforts (given that for cookie-like uses it's useless since it
only works when cookies are activated, for other uses localStorage is
dangerous and anyway indexedDB should be preferred now, and indexedDB is
not active in Tor Browser) and to take the risk to let it active, you
are still at the mercy of a FF bug, so personnaly I would deactivate it
by default and offer an option in the Page Info/permissions (which does
not exist in FF), or a global option (always ask, etc), most of the
users absolutely don't know that things are stored, even if it's on a
temporary basis for the Tor browser.
Le 20/06/2014 16:49, Georg Koppen a écrit :
Aymeric Vitte:
So the logic is: we accept non third party cookies, therefore we accept
localStorage and we suppose localStorage is disabled for third parties.
[snip]
And what's the point of allowing localStorage if you allow non third
party cookies?
That is covered in
https://www.torproject.org/projects/torbrowser/design/#philosophy
See the whole design document for getting our idea(s). Why we are not
allowing 3rd party cookies yet is explained in 4.5.1. DOM Storage is the
subject of section 4.5.4.
The commit I've been talking about is
https://gitweb.torproject.org/tor-browser.git/commit/5392d2ed679eaaa078f5c667573ef0698ec65345
Georg
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
--
tor-talk mailing list - [email protected]
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
