Privacy/TPWG/Discussion of ensuring DNT signal validity

From W3C Wiki
< Privacy‎ | TPWG

Goals:

  • Enable site to determine whether a DNT;1 signal is "valid", i.e., collected from an actual (human) user as an explicit preference

Signals that are not valid:

  • Set by most tools (excelt the "Do Not Track Me" plugin and the likes)
  • Set by user agents with insufficient user interface ("say yes")
  • Would enable site to follow "valid" signals while rejecting others

Challenges to address:

  • User agents with inappropriate UI
  • Pre-set "DNT;1" preferences
  • Intermediaries modifying the DNT signal (e.g., a ISP inserting DNT;0 or DNT;1 without sufficient consent).
  • Plugins modifying the DNT signal
  • Any SW modifying the registry to trigger a browser to sent DNT;1 signals (IMHO this is how some virus scanners trigger the sending of the DNT;1 signal)

The remainder discusses some options and their pro/cons.

Signed Signals

Idea: User agent signs signals to authenticate them.

Pro:

  • Allows site to determine whether a signal came from a specific user agent (assuming only the UA has access to the key)
  • Ensures that the DNT signal is not modified in transit (unless ISPs are certified, too).

Cons:

  • Is unlikely to solve the problems with plugins or registry changes
  • Hard / expensive to implement

HTTPS for Signal Validation

Idea: Site switches to https to validate a signal

Pro:

  • Ensures that the DNT signal is not modified in transit.
  • Can be added "on top" of current consensus

Cons:

  • Is unlikely to solve the problems with plugins or registry changes
  • Unless you continue browsing via https, preferences can no longer managed by page (because the DNT preference for the https-page determines the behavior for the rest of the site).

Use UGE

Idea: The site does not trust the initial DNT;1 signal and always asks for an UGE (unless one has been registered; which is singaled by DNT;0) Pro:

  • Easy to implement on top of current consensus
  • May lead to a certain number of users that say "yes" to tracking

Cons:

  • Renders everything we did for DNT;1 largely obsolete ;-)

Remarks:

  • Currently, the TPE requires consent standards beyond the EU practices (implied consent).
  • If we allow to register "implicit consent" as a UGE, this option should be OK for the industry?

External Repository

Idea: A repository where users register their DNT setting there in a secure and validated manner (similar to the current opt-in/opt-out programmes)? Pro:

  • Aligned with today's programme

Cons:

  • Course-grained Yes/no

On Mobile: JSON Objects

Idea: Authenticated object with tracking preference passed from OS to mobile App; this contains marketing ID and tracking preference

Pro:

  • May work
  • Contractual enforcement though EULA

Cons:

  • Per-platform implementation; proprietary
  • Only high-level compliance statements

Would work for browsers? - JavaScript API with "locked" signal and "frozen" semantics (that does not allow extensions to moderate this call)

No change

Idea: DNT header is sent; UA string can be used to guess the UA used. Can Javascript be used to determine the active plugins?

Pro:

  • Easy to implement & current consensus

Cons:

  • User agent determination is not reliable (UA strings can be forged)
  • Signals can be modified in transit
  • Is unlikely to solve the problems with plugins or registry changes
===================================

NOTES/DISCUSSION:

  • HTTPS usually sufficient to protect the signal in transit (or a proprietary protocol for signal transmission, e.g. local javascript sends SLJDKLJDE for 1 and JHWEGHG for 0)
  • Challenge: How to prevent plugins and antivirus to change or inject signals
  • On mobile, browser should get their preference from the OS preference (or at least ensure that both preferences are in sync.
  • Important element: Lock the signal to prevent tampering by plugins.
  • Alternative: Signal as OS tamper-protected preference. E.g. URL to OS preference

Solution 1: - Client-side Call + special encoding/https - Rules for browser to ensure that client-side call contains the correct signal

Solution 2:

  • DNT;1 + HTTPS
  • Rules for browser to ensure that client-side call contains the correct signal

Open Question:

  • How can a site obtain a "valid" preference if a untrusted browser is visiting?
 ** User-granted exceptions stored in browser
 ** Out of band exceptions stored elsewhere (DNT repository)
Retrieved from "https://www.w3.org/wiki/index.php?title=Privacy/TPWG/Discussion_of_ensuring_DNT_signal_validity&oldid=74321"