isKnown state

[privacycg]

isKnown state

[melanierichards]

(My comment pertains to API shape + bits of entropy vs an opinion on the need for this proposed API, so feel free to defer until later; just wanted to get my thoughts on paper, so to speak.)

It is often maintained via a fingerprinting process (in the same way that sites attempt to retain the user's login outside of the cookie by profiling and recording information about their device) which is privacy invasive.

In the interest of avoiding fingerprinting behaviors, I wonder if it's possible to further minimize the data this proposal exposes and still address the motivating use case. Reading back a counter and a measure of recency could be pretty helpful in building up the unique-ness of a given user.

Instead of reading back a counter:

1. The site specifies a maximum count
2. The UA stores an internal counter and the maximum value
3. The site tells the UA when to increment the counter
4. In order to determine whether the user has hit the paywall limit, the site could read back a Boolean value (did the user hit the limit or not?)

We'd probably need to design this such that the site isn't setting unique maximum counts, or incrementing the max count continuously.

The time value could be similar. Instead of reading back a number of hours:

1. The site could set an IsKnown timeout
2. The UA could reset the internal IsKnown counter when the timeout is reached

[gffletch]

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]

Paywalls are an interesting case. I think the challenge for them is that I'd imagine sites with paywalls would want said paywall counters to carry over to incognito/private mode as well. Is that right?

Edit: removing bikeshedding comment as it's non-productive at this point.

[samuelweiler]

Why not just do this with a non-identifying cookie or pair of cookies? You write of a 'post-cookie world', but I'm still seeing interest in having some (perhaps limited) persistence for first-party cookies. Is this solving a problem that doesn't need new primitives to solve?

[AramZS]

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.

@gffletch I agree, that isn't the use case I intend this for. That use case is being discussed in privacycg/is-logged-in#9. This is not a case intended to be used to identify the user, but instead an alternative used to understand patterns of access without requiring a lot of knowledge about the user to be stored.

[AramZS]

Paywalls are an interesting case. I think the challenge for them is that I'd imagine sites with paywalls would want said paywall counters to carry over to incognito/private mode as well. Is that right?

Edit: removing bikeshedding comment as it's non-productive at this point.

@jkarlin I mean... haha yeah, we'd love to have the paywall counters carry over to incognito/private mode! There are a lot of publishers out there now who actually block on incognito mode when they can detect it (which is infrequently). If an increased level of anonymity would allow browsers to create a cross-standard/incognito counter to understand a user a returning visitor within X time (and no other data about them) that would be amazing. I'm having a hard time imagining users being ok with that though?

[AramZS]

Why not just do this with a non-identifying cookie or pair of cookies? You write of a 'post-cookie world', but I'm still seeing interest in having some (perhaps limited) persistence for first-party cookies. Is this solving a problem that doesn't need new primitives to solve?

@samuelweiler A lot of paywall management is done with vendors who are third party scripts, something that seems very likely to end up blocked as we increase browser privacy. Beyond that, what forces a cookie to be non-identifying? If the goal is to give users an increasingly private experience over time with something like isLoggedIn (which is also a case that could be stored to a persistent cookie) than I think we might need this as well?

[arthuredelstein]

This counter seems easily spoofable -- the UA just needs to reset the counter to zero and the user can read more free articles, right? So publishers will still have an incentive to fingerprint the user.

[AramZS]

The site specifies a maximum count
The UA stores an internal counter and the maximum value
The site tells the UA when to increment the counter
In order to determine whether the user has hit the paywall limit, the site could read back a Boolean value (did the user hit the limit or not?)

The more I think about it the more sense this makes, I agree, avoiding any exposure to the number value of the counter is a more private design.

The UA could reset the internal IsKnown counter when the timeout is reached

This would seem to me to be the simplest approach!

And I agree we would have to think about the design of how the counter is handled in order to avoid a situation where it becomes a fingerprinting vector.

[AramZS]

This counter seems easily spoofable -- the UA just needs to reset the counter to zero and the user can read more free articles, right? So publishers will still have an incentive to fingerprint the user.

Users already clear cookies, switch browsers, go incognito. Generally the efficacy of trying to fingerprint the user is going down now and going to continue to go down. I think that trying to design a methodology that removes the capability of a limited number of motivated people to avoid pay/reg walls is pretty much impossible. However, clean, non-identifying, recognition of a returning viewer is a useful potential signal and could be used for a lot more than just paywalls, sites can create other incentives as well. Further, we could examine this as a signal to potentially unlock API features in a limited way in the same way isLoggedIn does, but that is a larger conversation.

[AramZS]

An additional factor we should likely discuss is scope: I would prefer to avoid a situation where multiple entities on a page could create different values for isKnown and potentially creating a way to identify a user through that method, but I can also see the argument for embedded entities wanting their own isKnown value to handle their own actions in cases like video or embedded articles, etc...

Not sure what the answer is yet, but wanted to mark this as an issue to discuss if we wish to progress.

[hober]

hi @AramZS, are you still interested in pursuing this? @johnwilander, I wonder if this could be rolled up into the Login Status API?