Closed dickhardt closed 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.
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.
@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.
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.