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: Jonathan Mayer <jmayer@stanford.edu>
Date: Fri, 3 Feb 2012 16:17:28 -0800
Cc: Jeffrey Chester <jeff@democraticmedia.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-Id: <39B50F5A-DA5B-44EE-AEE6-7646237AB20F@stanford.edu>
To: Matthias Schunter <mts@zurich.ibm.com>
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
> 
> 
> 
> 
> 
Received on Saturday, 4 February 2012 00:18:01 UTC

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