Difference between revisions of "User Tracking"

Revision as of 17:05, 28 September 2020

Full Title or Meme

Nearly all sites track users at some level. There is generally some level at which users object which is dependent on the site's behavior.

Context

• This wiki page deals exclusively with the User Experience (UX) of a web browser chosen by the user to navigate the web.
• Some comments and terminology my need to be framed in terms of the behavior of the web site in that User Experience in order to understand the entirety of the problem.
• REST, or representative State

Terminology

Just to be sure we are all talking about the same thing for at least the durations of this wiki page. The designation for first party (1P) is very web centric, but seems common, so let's stick with it.

1. First Party (1P) - the web site the user navigated to.
2. Second Party (2P) - actions by a native app on the user's device.
3. Third Party (3P) - some other web site brought onto the UX by the 1P.

Problems

Web sites have not been able to distinguish between ad tracking and authentication tracking. The following images shows the impact of the Apple (webkit) Tracking Prevention Policy

This does not effect sites that use redirection to allow OpenID Connect for first party web site authentication. But when related sites attempt to use cross site authentication they will be blocked.

Potential Solutions

First try to understand what the user knows, what the browser knows and what the site knows as a result of cookies or of back-end account store.

1. Nothing about the site but its name and perhaps a recommendation by the link that send the user there.
2. User forms an opinion about whether the site is interesting. - Site puts a cookie on the user's computer to remember if the user comes back and what the user saw last time.
   1. If the user never goes back the cookie times out and is deleted. Timing here is interesting - lets say it is 30 days. For some reason the exact time the user was there seems to be called PII?
3. User goes back while cooke still valid. The site know that the user is interested and may be willing to continue to offer paywall content for (say) 3 times in 30 days. Then they dmand money. ( The user is "KNOWN".)
4. For one reason or another the user decides to create an account an sign into the web site. Now thinks get interesting. If Notification is triggered the user needs to supply a call-back method. ("The user is "SIGNEDIN".)
5. After some time the use is signed out for inactivity. (The user is "ACCOUNT" at site the user name and password may be retained by the browser.)
6. The user goes to the web site again and the site can perform several actions. A request to sign into the site can be intercepted by the browser and auto signing. ("The user is "SIGNEDIN".)
7. The user is asked for demographics besides the call-back. The is now a PII CONTROLLER and assumes lots of responsibility. (The user state in the web site changes to "PII PRINCIPAL", browser doesn't understand.)
8. The user asked to have the account closed. - unknown impact.

OpenID impact

• As written OpenID Connect has not problems with the elimination of user tracking as it is all 1P.
• For related party authentications where 3P connections are used there appears to be now way for the browser is to know difference between tracking for authN and just ads.
• Web sites wish to continue offering an SSO capability for their websites will need to move to a solution that relies on sending a user to a centralized login page for authentication which can then track a session with a 1st party cookie.
• The alternate for OpenID is to convince the browser manufacturers to enable some means of either (1) determining what a authN tracking looks like, or (2) at least getting the browser to track when a site agrees to authN and remember that as part of their existing log on service.

References