Re: issues 23 and 34, happy new year's initial text for all...

On the question of why the ISSUE-23 text addresses more than analytics: There appeared to be agreement at both Cambridge (http://www.w3.org/2011/09/22-dnt-minutes.html) and Santa Clara (http://www.w3.org/2011/10/31-dnt-minutes.html) that the rationale for an analytics exception extends to a broader set of outsourcing practices.

On Jan 10, 2012, at 9:50 AM, David Singer wrote:

> Hi Roy
> 
> inline, attempts to answer your questions
> 
> On Jan 10, 2012, at 3:22 , Roy T. Fielding wrote:
> 
>> On Jan 3, 2012, at 3:18 PM, David Singer wrote:
>> 
>>> Issue number: 23
>>> 
>>> 
>>> 
>>> Issue name: Possible exemption for analytics
>>> Suggested retitle: Possible exemption for outsourcing
>>> 
>>> Issue URL:
>>> http://www.w3.org/2011/tracking-protection/track/issues/23
>> 
>> I am confused.  ISSUE-23 is not about outsourcing.
> 
> I thought Issue 23 was about a first party outsourcing analytics to a third party acting solely on behalf of the first party, so it is, in part.  Do you have a better name?
> 
>> 
>>> Note that any data collected by the third party that is used, or may be used, in any way by any party other than the first party, is subject to the requirements for third parties.
>> 
>> I don't understand that sentence.
> 
> If the third party that is acting on behalf of the first party ALSO collects data on its own behalf, that second set of data is still third-party data and subject to third-party rules.  We may be stating the obvious.
> 
>> 
>>> Example:
>>> ExampleAnalytics collects analytic data for ExampleProducts Inc..  It operates a site under the DNS analytics.exampleproducts.com. It collects and analyzes data on visits to ExampleProducts, and provides that data solely to ExampleProducts, and does not access or use it itself.
>>> 
>>> Text that possibly belongs in other sections:
>>> When the third party sends a response header, that header must indicate that that they are a third party and that they are operating under this exception.
>> 
>> Eh?  They are operating as the first party.
> 
> If you take your lawyers to a meeting to represent you and act on your behalf, we expect them to say "Hi, I am Hyacinth acting on behalf of Roy" not "Hi, I am Roy".  Similarly, when a third party acts on behalf of a first party, that's what they say in the response header "I am acting on behalf of the first party", not "I am the first party".
> 
>> 
>>> Note that a third party that operates under a domain name or other arrangement that makes it appear to the user as if they are the first party, or a part or affiliate of the first party, is nonetheless a third party and is subject to the requirements of this clause ("DNS masquerading").
>> 
>> That is confusing.  I think what you mean is that a third party that does not
>> conform to the above conditions cannot operate as a first party even if the
>> data is collected through a shared domain or subdomain of the first party.
> 
> You're addressing a different point;  this one is merely saying "adopting a domain name that makes it look like you're a part of the first party does not make you, per se, the first party;  you're still third-acting-on-behalf-of-first.
> 
>>> Issue number: 34
>>> Issue name: Possible exemption for aggregate analytics
>>> Suggested retitle: Possible exemption for unidentifiable data
>>> 
>>> Issue URL:
>>> http://www.w3.org/2011/tracking-protection/track/issues/34
>>> 
>>> Section number in the FPWD: 3.4 Types of Tracking
>>> Contributors to this text: (Draft) David Singer, (Edit) Jonathan Mayer
>>> 
>>> Specification:
>>> A third party may collect, retain, and use any information from a user or user agent that, with high probability, could not be used to:
>>> 1) identify or nearly identify a user or user agent; or
>>> 2) correlate the activities of a user or user agent across multiple network interactions.
>> 
>> Again, totally confused.  Analytics are defined as correlating the activities of
>> a user across multiple network interactions.  
> 
> Isn't analytics broader than that?  "How many visitors" "How many resulted in a sale" "How many page views" "How many californians" and so on.  Under no-not-track, you're not supposed to "track" *individual users*.  This exception says you can still collect non-identifiable aggregate data.
> 
>> Do you mean tracking the user across
>> multiple sites?  
> 
> No, we mean tracking a single person at all.
> 
>> ISSUE-34 is about sharing analytics data in aggregate form
>> (e.g., a manufacturer might want to obtain aggregate information about
>> both the types of users that purchase their products and the types of
>> users that spend some threshold of time looking at the products but
>> do not result in a purchase.  Is it okay for the shop to share that data
>> with the manufacturer if the data shared is in an aggregate form that cannot
>> be used to identify individual users?
> 
> That is what we are trying to say, yes.
> 
>> 
>> Also, keep in mind that fraud prevention requires at least some data
>> collection and retention by third parties.
> 
> That's a separate exception, that someone else is writing?
> 
>> 
>>> Examples:
>>> 1. A third-party advertising network records the fact that it displayed an ad. 
>>> 2. A third-party analytics service counts the number of times a popular page was loaded.
>>> 
>>> Non-Normative Discussion:
>>> This exception (like all exceptions) may not be combined with other exceptions unless specifically allowed.  A third party acting within the outsourcing exception, for example, may not make independent use of the data it has collected even though the use involves unidentifiable data.  A rule to the contrary would provide a perverse incentive for third parties to press all exceptions to the limit and then use the collected data within this exception.
>>> A potential ‘safe harbor’ under this clause could be to retain only aggregate counts, not per-transaction records.
>> 
>> I don't understand why we care.  Aggregate counts that do not identify users
>> are not a privacy concern and do not amount to tracking in any sense that
>> the user would intend to disable by DNT.
> 
> That's why we allow them, and specifically mention them as a 'safe harbor'.
> 
>> 
>>> Text that possibly belongs elsewhere:
>>> Possible advances in de-anonymization that make previously non-identifiable data, identifiable, should be considered.  
>>> [Maybe need an issue: whose problem is it when data from disparate sources, all but one of which are anonymous, is combined to achieve de-anonymization?]
>> 
>> AFAIK, aggregate data cannot be combined.  Anonymized data can often be
>> combined if it remains in non-aggregated form.
> 
> Right, so if you only retain aggregates and not per-transaction records, you are probably in good shape.
> 
>> 
>> Cheers,
>> 
>> ....Roy
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
>