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: Matthias Schunter <mts@zurich.ibm.com>
Date: Thu, 2 Feb 2012 16:06:21 +0100
To: Jeffrey Chester <jeff@democraticmedia.org>
Cc: Jonathan Mayer <jmayer@stanford.edu>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <OF23E41C3B.2007350C-ONC1257998.0052E621-C1257998.0052FA61@ch.ibm.com>
Hi Jonathan/Jeff,

what exeptions do you see at this point that are likely to satisfy this
what are viable candidates where only  more data/input/answers is needed?


| 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.


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

      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

      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
                  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
                  devices, or log records.  It also includes highly
            non-unique data
                  stored in the user agent, such as cookies used for
                  frequency capping or sequencing.  This exception does not
                  anonymized data, which recent work has shown to be often
                  identifiable (see [Narayanan09] and [Narayanan08]).
              4. Protocol logs, not aggregated across first parties, and
                  to a two week retention period.
              5. Protocol logs used solely for advertising fraud detection,
                  subject to a one month retention period.
              6. Protocol logs used solely for security purposes such as
                  detection and forensics, and subject to a six month
              7. Protocol logs used solely for financial fraud detection,
                  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.

Received on Thursday, 2 February 2012 15:07:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:32 UTC