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

I agree with much of what Shayne said - but will add the followingŠ.

It seems like much of the discussion (on this topic at least) is a bit
one-sided. If we're going to ask industry to granularly explain why
certain data uses pass Jonathan's Compelling need test, then it seems fair
to ask Jonathan (and/or others) to be able to granularly demonstrate (for
example) how and to what extent client side frequency capping approaches
work. The Stanford team has clearly done some fantastic work here, but a
test using a relatively small game network may or may not translate
perfectly outside of the testing environment. And I think its fair to ask
for a clear demonstration of how these concepts can be applied by both the
MSFT's and Googles, as well as tier 2 and tier 3 companies.

On that note, I'm concerned that much of what we're talking about
implementing will create all kinds of technical and logistical issues for
companies who don't have the resources of a Yahoo or Adobe.

Has the group considered bringing in some invited experts from the
long-tail of industry to help ensure that this is something that they can
implement without hiring an army of tech consultants?


Cheers,

Alan Chapell
Chapell & Associates
917 318 8440






On 2/1/12 9:45 PM, "Jonathan Mayer" <jmayer@stanford.edu> 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 Thursday, 2 February 2012 17:18:01 UTC