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: Shane Wiley <wileys@yahoo-inc.com>
Date: Thu, 2 Feb 2012 03:36:28 -0800
To: Lauren Gelman <gelman@blurryedge.com>, Bryan Sullivan <blsaws@gmail.com>
CC: Jonathan Mayer <jmayer@stanford.edu>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8023D0C8AC207@SP2-EX07VS02.ds.corp.yahoo.com>
It is not - please see previous email response.

-----Original Message-----
From: Lauren Gelman [mailto:gelman@blurryedge.com] 
Sent: Thursday, February 02, 2012 1:17 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)


If frequency capping is limited to on only a single domain, by a single entity, only to record a time stamp from when a user has last seen an ad and no other content, and data is destroyed at the conclusion of a campaign and the cookie expires, that would be better. 

On Feb 1, 2012, at 9:47 PM, Bryan Sullivan wrote:

> Not being an expert in frequency capping techniques, I must defer to those
> in the group who are. But in the F2F I heard reasonable descriptions of
> how frequency capping is possible without involving tracking (which yes, I
> would define simply as cross-site correlation of data).
> 
> My point about justification of restrictions is that we need a two-way
> dialog here. Not just a high wall that the industry must climb over in
> order to continue doing business.
> 
> I'm not sure anyone around this table is individualy so adept at all the
> needs and risks that they could unilaterally design a system that has few
> unintended consequences either on privacy or BAU, or could accurately
> estimate the cost/benefit from all angles. In such a complex situation,
> small reasoned steps are best IMO, with implementation/deployment
> experience helping us find the next step. So no, I do not support sweeping
> all data uses off the table and then putting each one through the fire so
> it can return.
> 
> I agree that David's proposal is very close to a working description and
> mitigates some of the needed exceptions/exemptions (I'm not sure of which
> term I should be using yet).
> 
> Thanks,
> Bryan
> 
> On 2/1/12 9:23 PM, "Lauren Gelman" <gelman@blurryedge.com> wrote:
> 
>> 
>> 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.
>> 
>> 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?
>> 
>> 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?
>> 
>> 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?"
>> 
>> 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 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
>> 
> 
> 
> 

Lauren Gelman
BlurryEdge Strategies
415-627-8512
gelman@blurryedge.com
http://blurryedge.com
Received on Thursday, 2 February 2012 11:37:26 UTC

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