gffletch
commented
4 years ago For publishers with pay-walls I can see where this would be extremely helpful. However, from a security perspective for identity providers this isn't sufficient as the Identity Provider needs to know that a specific identity (user) has used this browser to login in the past. The identity data can be encrypted so that only the identity provider can access the information and the data can be written on the fully qualified identity provider domain so as to not leak to other sites within the root domain.
jkarlin
samuelweiler
AramZS
melanierichards
arthuredelstein
hober
This builds off of the conversation around the isLoggedIn proposal by @johnwilander at https://github.com/privacycg/is-logged-in
This is a rough sketch here but I think we would like to create a more private way to understand a user as a repeat visitor to the site without having to invade the user's privacy by requiring they identify themselves.
I will explain with the use case I am most familiar with, paywalls. This is one case, but I do not think it is the only case. It is a distinct case from the one I see being discussed at https://github.com/privacycg/is-logged-in/issues/9 which is a reaction to a logged in state. The isKnown state, as I am currently proposing it, would not require a user to log in.
Many publishers use paywalls, these are important to maintain a profit for many publishers. The way this works right now is a site lays out a cookie, that cookie records the number of visits and when the number of visits exceeds the number we wish to allow freely then we can trigger a paywall and block access to content.
This process suffers from potentially the same issues that maintaining a logged in state does (which is why the isLoggedIn is a useful reference):
It contains an additional threat to privacy in that maintaining a connection with the user outside of login that requires tracking the user without their explicit consent (in UI terms, not diving into the legal side of this right now), which opens up problems that don't gel well with the future privacy-first web.
What I would like to have instead is a very simple non-invasive way to handle this, one not dependent on cookies or storage. This is important because, as we are already starting to see in anticipation of the post-cookie world, sites that feel they do not have some ability to meter access to content will push users to annoying UI on their first visit, asking them to log in to read even the first page they arrive on.
In a best-case scenario I'd imagine the isKnown state to be composed of two parts.
The first property is a single number which can be either incremented or reset one time per pageview by the site the user has landed on. This will prevent the site from trying to use the value for tracking or fingerprinting, but allow the site to own its definition of "known user" in a way consistent with how it is currently being done in the wild.
The second property is a single number that represents the period of hours (not seconds, not milliseconds, to avoid fingerprinting) since the last Known access.
Some potential flows:
New users:
Returning users (short time period):
Returning user (long period):
By having a way to measure access reliably while not relying on privacy invasive methods like fingerprinting we can better support an open web and legitimate publishers who would like to maintain users' privacy while also remaining profitable.
We've discussed this in calls a few time and I keep promising to write something up, but generally have been low on time to do so, so I'll keep this brief and try to hash it out via Q&A to see if it makes sense to advance this idea further.