[tor-dev] [GSOC16] Fingerprint Central - Cookies and localStorage

[Georg Koppen]

Pierre Laperdrix:
> Hello everyone,
> 
> I know the next status report is not due until next week but I wanted to
> get some feedback on how I use cookies and localStorage on FP Central.
> 
> Right now, due the very short lifespan of cookies in the Tor browser, I
> don't use cookies as an identification mechanism but as an
> expiration/anti-pollution mechanism.
> 
> Here is how it works:
> - For users without JavaScript, I put a cookie the first time a
> fingerprint is sent. This means that in the same session, no new
> fingerprint from the same user will be stored if he or she wants to see
> his or her own fingerprint again. If the user generates a new identity,
> he will be able to store a new fingerprint since no cookie will be present.
> - For users with JavaScript, I add a cookie when the test suite is run
> and I use localStorage to store data generated during the collection
> process. When the user sees his complete fingerprint with the percentage
> for each attribute, all the values are stored in localStorage. If the
> user gets back to the FP page page, it won't have to contact the server
> and the fingerprint will appear instantaneously by getting the stored
> copy from localStorage.
> The presence of data in localStorage prevents the user from sending his
> fingerprint a second time.
> The presence of the cookie acts as an expiration mechanism. If the
> cookie is still present, I consider the data in localStorage to be valid
> and the user cannot perform the collection process again. If the cookie
> has expired, I remove data present in localStorage and allow the user to
> execute the whole process again.
> 
> I don't know if my approach is a good one but I wanted to use what is
> available to me in the browser to prevent too many fingerprints from
> being stored and to lessen as much as possible the server load. If
> anyone has suggestions on my use of cookies and localStorage, I'll
> gladly take them.
> 
> Now, what I'm not really sure is: what about users who want to play with
> their browser and see the modifications done to their fingerprint? The
> way the site is built now prevents that. There are no buttons to force
> the collection process again. I see two alternatives here: add a "Force
> fingerprinting" button even though the database could be polluted or add
> a sort of "playground" webpage that is not connected to the database
> where the user can rerun the test suite as many times as he wants.

I actually like the playground idea. We might even be able to learn
something about user behavior if confronted with results deemed bad for
fingerprinting/tracking resistance. Not sure how time-consuming to
implement this will be, though. I guess we can keep it at least on the
back-burner as one interesting idea to enhance fp-central further.

Georg

> Hopefully, if everything goes well on my end, I'll be able to launch a
> beta version of the website next week. We could see from there if
> everything is working well and if the limitations imposed on users are
> not too important.
> 
> Have a great week-end,
> Pierre
> 
> 
> 
> 
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160630/e1e80c0f/attachment-0001.sig>