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 - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk