RE: Request for comments on priorities for DNT

We should agree on a set of specific things that servers should not do if
DNT is set. This is important so that there is a way to check for
compliance, either by the UA if users want that, or regulators.

We should also define in plain language what we mean by tracking, so users
know what to expect.

Most people imagine DNT to mean that they will not be identified between
visits to different websites, and so would not expect unique identifiers to
be used. If it is determined that reasonable commercial or security purposes
exist that require unique identifiers we should design a protocol that
enables them, but where they limited to that purpose and constrained so that
they cannot be used to identify people's web history. 

For example unique identifiers could be allowed but deleted after a short
period, and limited in scope to the context of first-party sites. 

Responsibility for acquiring consent is moving to sites with the UA being
enlisted to signal exceptions to third-parties. Sites could also orchestrate
how the UA limits identifiers used by their third-parties.

Mike

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 03 December 2012 11:25
To: Peter Swire
Cc: public-tracking@w3.org
Subject: Re: Request for comments on priorities for DNT

1. Define "tracking" and reduce the scope of compliance to turning off
   that tracking.  We can't expect users to express a preference if we
   can't explain to them what is intended by DNT:1.  We will never
   reach agreement on specific use case requirements if we don't agree
   on the desired effect that those requirements are intended to achieve.
   If we can't agree on a definition, then close the WG or partition
   into multiple groups based on each shared objective.

2. Fix "party" definitions so that they reflect user intent regarding
   tracking (see above) instead of legalistic boundaries of ownership.
   If necessary, use EU definitions of data controller and data processor
   to target compliance requirements that preserve user transparency
   and control, regardless of first/third party status for any given
   interaction.  This will eliminate the need for special requirements
   on contractors ("service providers") and solve the current problem of
   compliance definitions that prevent a company from sharing data with
   its own contractors under NDA.

3. Eliminate compliance requirements that require guessing of user
   intent (e.g., "I am the first party"). Instead, communicate
   statements of fact (e.g., "I comply with DNT's requirements on
   a first party") and require that resource deployment be consistent
   with those statements (e.g., If a resource claims to only comply
   with requirements on a first party, then the resource owner must
   not knowingly allow that resource to be deployed in third-party
   contexts, and must correct any unintentional deployments within
   a reasonable period after being notified).


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Wednesday, 5 December 2012 15:23:41 UTC