W3C home > Mailing lists > Public > public-tracking@w3.org > February 2012

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

From: Ed Felten <ed@felten.com>
Date: Mon, 6 Feb 2012 20:24:59 -0500
Message-ID: <CANZBoGiQUNr32-i1-MBLpCVbx4CP3=AbZrw2z9wjn61nP1jppQ@mail.gmail.com>
To: "<public-tracking@w3.org>" <public-tracking@w3.org>
Mike,  when you say "90% market participation," which market do you mean?

On Mon, Feb 6, 2012 at 4:58 PM, Mike Zaneis <mike@iab.net> wrote:
> I would like to echo Alan’s argument about small publisher considerations
> here.  This was my point in Brussels, that we cannot ask millions of
> websites (certainly well over the conservative estimate Shane gave of
> approximately 1 million) to reconfigure their servers to meet the W3C
> standard.  While this concern was largely brushed off as a mere
> “educational” task by some in attendance, we cannot fool ourselves into
> believing it is an achievable goal.  The reason the DAA program has been
> able to achieve well over 90% market participation in the United States is
> because we leverage the ad networks to deliver increased transparency and
> choice instead of focusing on publishers.  I fear putting the onus on
> publishers will relegate any standard to the trash heap of P3P and other
> failed projects.
>
>
>
> Mike Zaneis
>
> SVP & General Counsel
>
> Interactive Advertising Bureau
>
> (202) 253-1466
>
>
>
> Follow me on Twitter @mikezaneis
>
>
>
>
>
> From: Shane Wiley [mailto:wileys@yahoo-inc.com]
> Sent: Monday, February 06, 2012 10:06 AM
> To: Alan Chapell; Jonathan Mayer; Sean Harvey
>
>
> Cc: Matthias Schunter; Jeffrey Chester; public-tracking@w3.org
> (public-tracking@w3.org)
> Subject: RE: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31,
> ISSUE-34, ISSUE-49)
>
>
>
> I understand the desire for technology oriented solutions – as those remove
> much of the “trust” factor necessary for user based prohibitions or
> exceptions within the standard.  As we have ~1 million web sites around the
> globe that will need to implement DNT, ranging from the very large
> (disproportionate share of user engagement) to the very small (small
> bloggers who are reliant on ad revenue to pay their mortgage and will feel
> the impact of revenue loss more acutely), a more balanced approach will be
> necessary for DNT to be successful.  The alternative is to force an
> extremist, technology-only solution on sites across the globe and quickly
> repeat the failure of P3P (and risk even large websites from deploying this
> version of DNT).
>
>
>
> I personally want W3C’s process to be hugely successful and for DNT to be
> implemented by every website across the globe.  To do this, we’ll need to
> find a balance with operational purpose exceptions that provide for a degree
> of “trust” initially for website operators.  This trust can be further
> tested through self-regulatory efforts to ensure the appropriate protections
> have been put in place to solidly separate business-as-usual, basic
> operations from profiling efforts (self-attestations, privacy policy
> postings, external audits, etc.).
>
>
>
> I appreciate the stance both sides of the philosophical divide are taking to
> cement their respective perspectives.  I believe industry participants have
> done an incredibly good job of seeking an acceptable middle-point to the
> situation as a starting point (I’m biased of course).  If Jonathan’s
> approach is the end of the compromise process, I’m afraid W3C’s DNT is DOA.
> Hopefully the conversation will continue from here and we’ll figure out a
> way to start at use-based exceptions and develop a process by which
> technology solutions become the best practice as soon as they’re available
> at scale (and in a manner all privacy advocates would agree do not harm
> consumer privacy).
>
>
>
> - Shane
>
>
>
> From: Alan Chapell [mailto:achapell@chapellassociates.com]
> Sent: Monday, February 06, 2012 8:44 AM
> To: Jonathan Mayer; Sean Harvey
> Cc: Matthias Schunter; Jeffrey Chester; public-tracking@w3.org
> (public-tracking@w3.org)
> Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31,
> ISSUE-34, ISSUE-49)
>
>
>
> Thanks Jonathan. I'll take a look at 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>
> Date: Sun, 5 Feb 2012 14:54:04 -0800
> To: Sean Harvey <sharvey@google.com>
> Cc: Matthias Schunter <mts@zurich.ibm.com>, Jeffrey Chester
> <jeff@democraticmedia.org>, "public-tracking@w3.org
> (public-tracking@w3.org)" <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>
> 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 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> 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>
>>                                                                 |
>>>
>>> -----------------------------------------------------------------------------------------------------------------------------------------|
>> |------------>
>> | To:        |
>> |------------>
>>>
>>> -----------------------------------------------------------------------------------------------------------------------------------------|
>>  |Jonathan Mayer <jmayer@stanford.edu>,
>>                                                                  |
>>>
>>> -----------------------------------------------------------------------------------------------------------------------------------------|
>> |------------>
>> | Cc:        |
>> |------------>
>>>
>>> -----------------------------------------------------------------------------------------------------------------------------------------|
>>  |"public-tracking@w3.org (public-tracking@w3.org)"
>> <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
>
>
Received on Tuesday, 7 February 2012 01:29:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:44 UTC