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