RE: High-level text on third-party responsibilities (ACTION-38, ISSUE-19)

Jonathan,

If you feel by not adding user agent that this somehow creates a loop-hole that companies will attempt to thwart to avoid DNT, then I'm okay (reluctantly) putting user agent back in the language although this feels wasteful.

Retention "period" in this context feels like an overreach to solving larger privacy issues and would recommend we continue to put forth "collection and use" oriented language at this time.

V3 Proposed Language:  A 3rd Party may not collect or use information related to communication with a User or User Agent outside of explicit Exceptions as defined within the standard.  Supported Exceptions are:

Note - 3rd Party, User, User Agent, and Exceptions will all be defined terms.

Thoughts?

- Shane


-----Original Message-----
From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
Sent: Friday, December 09, 2011 2:22 AM
To: Shane Wiley
Cc: <public-tracking@w3.org> (public-tracking@w3.org)
Subject: Re: High-level text on third-party responsibilities (ACTION-38, ISSUE-19)


On Dec 7, 2011, at 10:02 PM, Shane Wiley wrote:

> Jonathan,
> 
> User vs. User Agents:  It was my understanding that we'd define "User" to cover user agents as well rather than continually needing to list out both.  If everyone agrees, this will shorten and simply the language we use through-out the document.

I'd prefer to not conflate the terms "user" and "user agent."  It seems likely that some parts of the standard will use the term user to refer to an individual and not a user agent (e.g. user understanding, user expectations, user experience, user perception, ...).  And setting aside that, redefining user to include user agent would deviate the meaning of the text from a plain reading, possibly confusing some readers and implementers.

> Data Retention:  If data isn't collected, it cannot be retained.  It would appear the addition here is attempting to address previously collected data which is being addressed in Issue 71 (http://www.w3.org/2011/tracking-protection/track/issues/71).  <Personal opinion: DNT signal MUST be applied prospectively and MAY also be applied retrospectively.>

I included "retention" and "use" for two reasons.  First, they are a backstop for the exceptions we enumerate: if an exception does not specifically allow the collection, retention, *and* use involved in a practice, then the practice is disallowed.  The terms require each exception to explicitly state what information may be collected, how long (and in what form) it may be retained, and how it may be used.  Second, they clarify that in case a third party comes into contact with covered information it did not collect from the user or user agent itself (i.e. information that was shared by a first party or another third party), the third party may not retain or use that information.

The inclusion of "retention" is not intended to address retroactivity.  I have no objection to language clarifying that (e.g. "communication" -> "the present communication").

> Exception Clarity:  I agree that this should not be interpreted as an "open to interpretation" exception clause - and believe the current proposal addresses that perspective.  I've have taken another pass at the statement to attempt to address your concern that exceptions as a class are somehow nebulous within the previous wording.
> 
> Updated Recommended Language:  A 3rd party may not collect or use information related to communication with a user outside of explicitly expressed exceptions as defined within the standard.  Supported exceptions are: ....  
> 
> Thoughts?

I'd like to see the document drafted as tightly as possible (here, unambiguously linking the enumerated exceptions to the discussion below).  Ambiguities in language have already sidetracked several conversations in this process; I'd like to prevent that from happening again.  Furthermore, this document will have to stand the test of time.  We're developing a consensus that reflects compromises around the table; the last thing I'd want is a future stakeholder misinterpreting that consensus and upsetting the balance we had so carefully struck.

> - Shane
> 
> -----Original Message-----
> From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
> Sent: Wednesday, December 07, 2011 11:41 AM
> To: Shane Wiley
> Cc: <public-tracking@w3.org> (public-tracking@w3.org)
> Subject: Re: High-level text on third-party responsibilities (ACTION-38, ISSUE-19)
> 
> A few design considerations from my version of the high-level rule:
> 
> -Do Not Track should address communication with user agents in addition to users since in many (if not most) cases the user will be unaware of and have no explicit interaction with a third party.
> 
> -In my view of the key terms, data collection is bits arriving at a third party, data retention is a third party keeping bits, and data use is a third party applying logic to bits.  I think Do Not Track should, at a high level, prohibit all three; each exception should narrowly define a set of permissible collection/retention/use practices.  (We may also want to address data sharing, when a third party hands bits to another party.)
> 
> -Exceptions in the high-level rule should be explicitly linked to the subsequent exception definitions.  We might otherwise create ambiguity about the scope of exceptions and, in particular, might suggest there are broad use-based exceptions.
> 
> On Dec 7, 2011, at 9:13 AM, Shane Wiley wrote:
> 
>> Proposed Update:
>> 
>> A 3rd party may not collect or use information related to communication with a user outside of supported exceptions.  Supported exceptions are: ....
>> 
>> - Shane
>> 
>> -----Original Message-----
>> From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
>> Sent: Wednesday, December 07, 2011 10:10 AM
>> To: <public-tracking@w3.org> (public-tracking@w3.org)
>> Subject: High-level text on third-party responsibilities (ACTION-38, ISSUE-19)
>> 
>> A third party may not collect, retain, or use any information related to communication with a user or user agent.  There are exceptions to this general rule for _____, _____, and _____ as defined in the following sections.
>> 
>> 
>

Received on Wednesday, 14 December 2011 04:57:27 UTC