User Tracking

From MgmtWiki
Revision as of 08:05, 4 November 2021 by Tom (talk | contribs) (Problems)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.


  • 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
  • Tracking can be a huge benefit to society for problems like epidemic control, until suddenly it become a huge liability when it is used for governmental control of citizens.


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 via the 1P.

Distributed Tracking is, for example, when the user has a device, like a smartphone, that can track the user that is not centralized until an infection individual is identified.


Tracking users on web sites is not simple to correct and maintain value to the users.

  1. The Chromium bug list for Privacy Fingerprinting had 112 entries on 2021-11-11. A large faction of these bugs had not be dealt with.
  2. Privacy CG Navigation-based Tracking Mitigations mins (2021-10)

Problems created by the Solutions

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

Safari Safe from Tracking.png

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