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.
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
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi,
Pierre Laperdrix: a "playground" where the user can rerun the test suite
It would be dope to have a playground where users can visit and actively be attacked, a purposely malicious .onion, if you will.
Rerunning the tests in a sandboxed environment is a step toward this, it seems (:
Wordlife, Spencer
-
Georg Koppen -
Pierre Laperdrix -
Spencer