Difference between revisions of "User Tracking"
From MgmtWiki
(→Potential Solutions) |
(→Terminology) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
* 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. | * 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 | * 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. | ||
| + | ** [https://www.youtube.com/watch?v=xjn36ZMMTpI&feature=emb_logo See the ethongraphic study of COVID-19.] | ||
===Terminology=== | ===Terminology=== | ||
| Line 11: | Line 13: | ||
# Second Party (2P) - actions by a native app on the user's device. | # Second Party (2P) - actions by a native app on the user's device. | ||
# Third Party (3P) - some other web site brought onto the UX by the 1P. | # Third Party (3P) - some other web site brought onto the UX by 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. | ||
| + | |||
| + | ==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) [https://webkit.org/tracking-prevention-policy/ Tracking Prevention Policy] | ||
| + | |||
| + | [[File: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== | ==Potential Solutions== | ||
| − | First try to understand what the user knows, what the browser knows and what the site knows. | + | 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. |
# Nothing about the site but its name and perhaps a recommendation by the link that send the user there. | # Nothing about the site but its name and perhaps a recommendation by the link that send the user there. | ||
# 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. | # 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. | ||
| Line 19: | Line 29: | ||
# 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".) | # 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".) | ||
# 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".) | # 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".) | ||
| − | # After some time the use is signed out for inactivity. (The user is "ACCOUNT" at site | + | # 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.) |
# 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".) | # 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".) | ||
| − | # The user is asked for demographics besides the call-back. The is now a PII CONTROLLER and assumes lots of responsibility. ( | + | # 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.) |
# The user asked to have the account closed. - unknown impact. | # The user asked to have the account closed. - unknown impact. | ||
===OpenID 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 [https://blogs.akamai.com/2020/01/cookies-single-sign-on-and-you.html 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== | ==References== | ||
Revision as of 17:50, 16 October 2020
Contents
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
- 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.
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.
- First Party (1P) - the web site the user navigated to.
- Second Party (2P) - actions by a native app on the user's device.
- Third Party (3P) - some other web site brought onto the UX by 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.
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.
- Nothing about the site but its name and perhaps a recommendation by the link that send the user there.
- 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.
- 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?
- 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".)
- 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".)
- 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.)
- 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".)
- 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.)
- 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.
