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

Lauren,

Please see my responses below in [ ]:

- Shane

-----Original Message-----
From: Lauren Gelman [mailto:gelman@blurryedge.com] 
Sent: Thursday, February 02, 2012 12:23 AM
To: Bryan Sullivan
Cc: Jonathan Mayer; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)


Frequency capping is squarely outside any prohibition on cross-site tracking, right? So even given your definition of what DNT:1 means-- which is the broadest possible interpretation of DNT-- you think it is Jonathan's burden to show why the standard shouldn't contain the broadest possible language for every exception necessary to maintain the current advertising business practice?

I stil have not seen any definition of frequency capping, but I'm pretty sure it means putting a cookie on a browser that tracks a user's activity across multiple sites to make sure the user sees enough ads to buy the goods, but not too many ads to be aware they are being targeted.   So even though one is opting into "not being tracked across sites" they are going to be tracked across sites. 

[Proposed Definition:  Frequency Capping is the process of "tracking" how many times a particular device has seen a particular ad - and then leveraging this information for the express and solo purpose of no longer showing that ad to a user.  Frequency Capping is NOT a means to target ads to the user, but rather the opposite.  Frequency capping is NOT tied to "the purchase of goods".  Frequency capping is NOT an attempt to hide if ads are being targeted to a user.]

To the extent you require a justification, doesn't the fact that it "breaks" an opted-in user expectation mean the burden is on you to show why the process should be allowed?

[Industry standards are voluntary.  If it is the desired outcome of this group to find a middle-ground where MOST (not all) of our concerns are addressed and the vast majority of industry adopts the standard, then it is in our mutual interest to devise a DNT standard that does not break the fundamental monetization model of the Internet.  Equally, it's important to ensure the consumer privacy debate and resulting protections are well advanced through DNT.  Balance is the key here and at times feels to be lost when one-side takes extremist positions on topics and throws the group into a bit of a spiral.  "Can't we all just get along." :-)]

I still think the scope of something like frequency capping needs to be defined.  Is it "cross site tracking that is permitted to fulfill a request that a browser only see an ad X frequency over Y time associated with Z domains and A content"  Can Y be a year, ten years?  Who can do it?  Just an adserver? what about the agency? or the advertiser? Does this data ever expire? can it be used for any other purpose? 

[Data retention is a much broader topic than DNT and should be addressed separately if the goal is to define global, industry-wide retention rates on specific business activities.  The group should continue to adhere to the concept of Minimization where parties must defend their specific retention periods for their unique business models.]

And I am not against a tailored exemption for frequency capping per se-- I prefer not being shown the same interstitial more than once every ten minutes in December when stock is oversold.  I just think an exemption for "frequency capping" is going to be a field day for the lawyers, DNT: 1 users are going to get cookies and not know why, and frankly, 15 minutes after the spec is published, companies are going to ask "why can I do this type of thing to make sure users don't see too many ads, but can't implement a cross site cookie to do x, which is also necessary to not break the internet?"

[Not sure what you mean by "shown the same interstitial more than once every ten minutes in December when stock is oversold."  Any assertion by a legal entity that it does X and in reality is doing Y is grounds for a legal challenge.  The "field day" is already here.  Bad actors will NOT implement the DNT standard no matter how balanced an approach we develop so I would suggest we keep our focus on those parties that are ready, willing, and eager to implement DNT once a balanced approach can be achieved.]

I am very against the exceptions that somehow require companies to keep data for the milliseconds necessary to transfer it into aggregate information. I understand the desire.  I have clients who do this.  But it is a legal nightmare, expensive and difficult for even technically sophisticated companies to do right. If you need proof of that, I can find some qualified security experts to weigh in.

[I strongly disagree and have been working in this field for over a decade (in industry for over 20).  Could you please provide evidence that data aggregation is a "legal nightmare, expensive, and difficult for even technically sophisticated companies to do right"?]

I actually think David Singer's proposal that doesn't require all these exceptions is very interesting, assuming there is a definition of Party that doesn't swallow the rule, though I liked the 1st/3rd party distinction because it focuses on user expectations which I thought is what DNT is all about.


> 
> 
> Without a clear justification in these terms, I would err on preservation
> of BAU, within again within the blanket use restriction for cross-site
> tracking.
> 
> Best Regards,
> Bryan
> 
> On 2/1/12 6: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
>> 
>> 
> 
> 
> 

Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com
http://blurryedge.com

Received on Thursday, 2 February 2012 11:36:40 UTC