RE: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

Jeff,

As part of the community attempting to implement P3P, it failed due to difficultly to implement (no flexibility, no response structure, etc.).  It absolutely protected privacy when implemented correctly.

- Shane

From: Jeffrey Chester [mailto:jeff@democraticmedia.org]
Sent: Monday, February 06, 2012 9:24 AM
To: Alan Chapell
Cc: Jonathan Mayer; Sean Harvey; Matthias Schunter; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

Alan:  As you know, the long tail practices reflect and are mediated by the general business practices (and increasingly facilitated by them via ad exchanges, etc.).  P3P failed because it didn't really protect privacy, not because it was a standard difficult to implement.   A reasonable and effective standard can be implemented by all.


Jeffrey Chester
Center for Digital Democracy
1621 Connecticut Ave, NW, Suite 550
Washington, DC 20009
www.democraticmedia.org<http://www.democraticmedia.org>
www.digitalads.org<http://www.digitalads.org>
202-986-2220

On Feb 6, 2012, at 8:44 AM, Alan Chapell wrote:


Thanks Jonathan. I'll take a look at donottrack.us<http://donottrack.us>. I was merely reacting to your assertion that client-side frequency capping would work everywhere because it worked for a small game network. Perhaps I misunderstood your point on this issue when you raised it in Brussels.

Regarding my larger point - I'm concerned that this group may not have adequate representation from the long tail of industry. And while our seven invited experts certainly bring a significant level of talent and experience, it does not appear that their collective expertise extends into the the business side of the long tail. Given that one of the chief criticisms of the P3P standard was that its complexity made it difficult to implement correctly, I think its worth asking the question whether or not we are at risk of repeating those mistakes. I can't speak to wether or not MSFT or Google's technology teams will be able to implement this standard - but I can say they have significantly more technology resources than a mid-sized publisher or ad network. When Commissioner Neelie Kroes makes her decision whether or not to support this framework, the ability of small to mid-sized digital companies located in the EU to implement would be a consideration in that decision.

It seems like this is worth raising as a formal issue - please let me know if any of you disagree.

Cheers,

Alan Chapell
Chapell & Associates
917 318 8440


From: Jonathan Mayer <jmayer@stanford.edu<mailto:jmayer@stanford.edu>>
Date: Sun, 5 Feb 2012 14:54:04 -0800
To: Sean Harvey <sharvey@google.com<mailto:sharvey@google.com>>
Cc: Matthias Schunter <mts@zurich.ibm.com<mailto:mts@zurich.ibm.com>>, Jeffrey Chester <jeff@democraticmedia.org<mailto:jeff@democraticmedia.org>>, "public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)" <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)
Resent-From: <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Sun, 05 Feb 2012 22:57:20 +0000

My notions of "minimization" and "balancing" encompass consideration of alternatives to a blanket use-based exception.  There are infinite possible exceptions for any particular business purpose, with countless permutations of collection and retention limits.  Those limits could be as straightforward as a retention period; they could be as complex as a privacy-preserving alternative technology.

As for client-side frequency capping and other privacy-preserving web technologies: my lab is far from alone in developing these alternatives.  See the annotated bibliography on donottrack.us<http://donottrack.us/> for some of the other work in the field.  These approaches are not mere lab studies; much of the finest work has been done by Microsoft Research, using data and technology from deployed systems.  I can't speak to what DoubleClick was capable of in 2007 and earlier, but I am very skeptical that these technologies are out of reach in 2012.

All of that said, let's take the position you (and others) have articulated at face value: client-side privacy-preserving technologies won't work.  Seeing as client-side storage is a fundamental component of just about *any* privacy-preserving system, then all we're left with are unique ID cookies.  The balance is, then, between frequency capping (where there is undoubtedly some economic value) and collection of a user's browsing activity across websites (the *central* concern in the Do Not Track debate for me and many others).  As you rightly noted in Brussels, taking the balance seriously, that means no frequency capping for DNT users.

And so, to circle back to privacy-preserving technologies: I am trying to extend an olive branch to the advertising industry representatives in the group.  I am trying to find ways for you to accomplish your business aims while giving user privacy the deference it deserves.  As between no frequency capping and an admittedly more challenging privacy-preserving frequency capping technology, I should imagine the latter is preferable.

Jonathan


On Feb 5, 2012, at 1:57 PM, Sean Harvey wrote:


I want to comment on Jonathan's original email on this chain, in the context of his later response below. Jonathan's thoughts are in general well thought out. To my mind the main stumbling block is his elaboration of #5, which was titled "Minimization" but focused on the use of "privacy enhancing alternatives".

In light of our both our meeting in Brussels and Jonathan's later post to this email chain, it's clear that Jonathan is speaking of his own personal version of client-side frequency capping, and so I feel forced to address this issue, though it seems tangential to our goals.

To put it simply, client-side frequency capping does not work at scale.

There were two separate initiatives at DoubleClick prior to its acquisition by Google that attempted to move functionality like frequency capping onto the client-side. Both looked nice when you did a little demo of them. But none of the worked at scale across a system -- like the ones that will be most directly impacted by these discussions -- that transact tens of billions of events per day. Discussing in further detail would be inappropriate in the context of this list because of proprietary technology concerns, but suffice it to say that client-side frequency capping and other such ad serving capabilities crap out at scale.

This is not to say that Jonathan is not extremely intelligent or that his idea isn't a good one, but he does not have the hard experience of many years spent building & maintaining massively scaleable software systems that must never go down at risk of the financial viability of tens of thousands of businesses across the web. And we do have many other women & men who are every bit as intelligent running our ad serving & other systems.

I am also unconvinced that retaining such data on the client side is a data privacy & security improvement for physical security reasons, because clients (e.g. browsers on laptops) are far more easily stolen than servers on data farms. While it's true that there would be no human readable values on the client side that an individual could leverage, the same remains true of the frequency cap ticks that are currently stored on the server-side.

I think it is entirely valid & useful for us to discuss openly the merits of a frequency cap exception, but do not think it is legitimate for us to make potentially disastrous technical implementation requirements in the context of this W3C compliance process.

sean








On Sat, Feb 4, 2012 at 1:17 AM, Jonathan Mayer <jmayer@stanford.edu<mailto:jmayer@stanford.edu>> wrote:

Here are a few exceptions that I believe could clear the hurdle.

-Content serving
-Contextual personalization
-Outsourcing
-Protocol logs for debugging
-Unidentifiable data (including aggregated data and client-side frequency capping)
-View fraud prevention through a stepped response

On Feb 2, 2012, at 7:06 AM, Matthias Schunter wrote:

> Hi Jonathan/Jeff,
>
> what exeptions do you see at this point that are likely to satisfy this
> catalogue?
> what are viable candidates where only  more data/input/answers is needed?
>
> Regards,
> matthias
>
>
>
>
> |------------>
> | From:      |
> |------------>
>> -----------------------------------------------------------------------------------------------------------------------------------------|
>  |Jeffrey Chester <jeff@democraticmedia.org<mailto:jeff@democraticmedia.org>>                                                                                               |
>> -----------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To:        |
> |------------>
>> -----------------------------------------------------------------------------------------------------------------------------------------|
>  |Jonathan Mayer <jmayer@stanford.edu<mailto:jmayer@stanford.edu>>,                                                                                                    |
>> -----------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc:        |
> |------------>
>> -----------------------------------------------------------------------------------------------------------------------------------------|
>  |"public-tracking@w3.org<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto:public-tracking@w3.org>)" <public-tracking@w3.org<mailto:public-tracking@w3.org>>                                                               |
>> -----------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date:      |
> |------------>
>> -----------------------------------------------------------------------------------------------------------------------------------------|
>  |02/02/2012 03:34 PM                                                                                                                      |
>> -----------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject:   |
> |------------>
>> -----------------------------------------------------------------------------------------------------------------------------------------|
>  |Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31,  ISSUE-34, ISSUE-49)                                                    |
>> -----------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
> I agree with Jonathan's thoughtful discussion of the exemption issue.  I
> recognize this is a delicate matter, and it will require continued dialogue
> to properly balance the goal's of DNT with traditional digital marketing
> (and advertising generally) business practices.  I believe that if we
> follow Jonathan's outline, we can achieve our collective goals.
>
> Jeff
>
> On Feb 1, 2012, at 9:45 PM, Jonathan Mayer wrote:
>
>      The working group has made great progress on the broad contours of
>      the definition document, and the conversation is shifting to specific
>      exceptions.  With that in mind, now seems an appropriate time to
>      articulate my views on when and how exceptions should be granted.
>
>      At a high level, we all agree that exceptions reflect a delicate
>      balance between consumer privacy interests and commercial value.
>      There are, no doubt, substantial differences in opinion about where
>      that balance should be struck.  I hope here to clarify my approach
>      and help others understand why I find recent proposals for blanket
>      exceptions to be non-starters.
>
>      In my view, any exception must satisfy this rigorous six-part test.
>
>      1) Specifically defined.  An exception must clearly delineate what
>      data may be collected, retained, and used.  If a proposed exception
>      is purely use-based, that needs to be extraordinarily explicit.
>
>      2) No special treatment.  We should grant or deny an exception on the
>      merits of how it balances privacy and commerce, not a specific
>      business model.
>
>      3) Compelling business need.  A bald assertion that without a
>      specific exception Do Not Track will "break the Internet" is not
>      nearly enough.  I expect industry stakeholders to explain, with
>      specificity, what business purposes they need data for and why those
>      business purposes are extraordinarily valuable.
>
>      4) Significantly furthers the business need.  I expect industry
>      participants to explain exactly how and to what extent a proposed
>      exception will further the compelling business needs they have
>      identified.  In some cases cases, such as security and fraud
>      exceptions, this may call for technical briefing.
>
>      5) Strict minimization.  If there is a privacy-preserving technology
>      that has equivalent or nearly equivalent functionality, it must be
>      used, and the exception must be no broader than that technology.  The
>      burden is on industry to show that a privacy-preserving alternative
>      involves tradeoffs that fundamentally undermine its business needs.
>      In the context of frequency capping, for example, I need to hear why
>      - specifically - client-side storage approaches will not work.  In
>      the context of market research, to take another example, I would need
>      to hear why statistical inference from non-DNT users would be
>      insufficient.
>
>      6) Balancing.  There is a spectrum of possible exceptions for any
>      business need.  At one end is a pure use-based exception that allows
>      for all collection and retention.  At the other end is no exception
>      at all.  In between there are infinite combinations of collection,
>      retention, and use limits, including exceptions scoped to
>      privacy-preserving but inferior technologies.  In choosing among
>      these alternatives, I am guided by the magnitude of commercial need
>      and consumer privacy risk.  I am only willing to accept an exception
>      where the commercial need substantially outweighs consumer privacy
>      interests.
>
>      I understand example exceptions may be helpful in understanding my
>      thinking, so here are a few from the IETF Internet-Draft.
>
>              3. Data that is, with high confidence, not linkable to a
>            specific
>                  user or user agent.  This exception includes statistical
>                  aggregates of protocol logs, such as pageview statistics,
>            so long
>                  as the aggregator takes reasonable steps to ensure the
>            data does
>                  not reveal information about individual users, user
>            agents,
>                  devices, or log records.  It also includes highly
>            non-unique data
>                  stored in the user agent, such as cookies used for
>            advertising
>                  frequency capping or sequencing.  This exception does not
>            include
>                  anonymized data, which recent work has shown to be often
>            re-
>                  identifiable (see [Narayanan09] and [Narayanan08]).
>              4. Protocol logs, not aggregated across first parties, and
>            subject
>                  to a two week retention period.
>              5. Protocol logs used solely for advertising fraud detection,
>            and
>                  subject to a one month retention period.
>              6. Protocol logs used solely for security purposes such as
>            intrusion
>                  detection and forensics, and subject to a six month
>            retention
>                  period.
>              7. Protocol logs used solely for financial fraud detection,
>            and
>                  subject to a six month retention period.
>
>
>      I would add, in closing, that in difficult cases I would err on the
>      side of not granting an exception.  The exemption API is a policy
>      safety valve: If we are too stringent, a third party can ask for a
>      user's consent.  If we are too lax, users are left with no recourse.
>
>      Best,
>      Jonathan
>
>
>
>
>




--
Sean Harvey
Business Product Manager
Google, Inc.
212-381-5330
sharvey@google.com<mailto:sharvey@google.com>