search

privacycg / storage-access

The Storage Access API
https://privacycg.github.io/storage-access/
209 stars 27 forks source link

Storage Exists API #11

Closed dickhardt closed 4 years ago

dickhardt commented 4 years ago

Apologies if there has already been discussion on this topic, I'm late to the discussion.

An API that allows the 1P to query if a 3P cookie exists would allow a 1P to only offer options to a user where the user has previously done something with the 3P site. The API would return a boolean value. For the social.example use case, the social button would only show up if there was a cookie at social.example.

The only abuse I can think of is a 1P site checking many 3Ps and using the results as a fingerprint.

othermaciej commented 4 years ago

The abuse you mention is exactly why we won't do it. It would enable the same types of privacy leaks as described in this paper.

hober commented 4 years ago

Given the potential for abuse, I'm going to go ahead and close this issue. Please let me know if we should re-open it.

laughinghan commented 4 years ago

@dickhardt Have you seen #8 and the WebKit strawman proposal, IsLoggedIn? I think it's what you're asking for, except the 3P site itself has to do the check in its iframe, and the user has to explicitly click yes on a permission prompt during the prior visit to what you're calling "the 3P site" (it was first-party during that visit, of course). This helps mitigate the potential for abuse: 3Ps that set cookies for their own purposes can't be unknowingly used as fingerprinting bits by 1P (because the 3P iframe has to choose to communicate with 1P), and a tracker would find it difficult to convince a user to visit-and-click-yes-to-the-permission-prompt on enough cooperating 3P sites to collect useful amounts of fingerprinting bits.