- From: Ed Felten <ed@felten.com>
- Date: Sat, 7 Apr 2012 07:52:44 -0400
- To: Shane Wiley <wileys@yahoo-inc.com>
- Cc: "public-tracking@w3. org Group WG" <public-tracking@w3.org>
Which parts of this are normative and which are non-normative? On Sat, Apr 7, 2012 at 4:40 AM, Jonathan Mayer <jmayer@stanford.edu> wrote: > Shane, > > Could you please identify the authors and institutions that developed this > proposal? > > Thanks, > Jonathan > > On Apr 7, 2012, at 12:43 AM, Shane Wiley wrote: > > NOTE – please excuse the naming of the document – I had initially named it > NAI as a placeholder but this should not be deemed an NAI submission. > Apologies to Marc and the rest of the NAI team. > > - Shane > > _____________________________________________ > From: Shane Wiley > Sent: Friday, April 06, 2012 10:17 PM > To: public-tracking@w3. org Group WG > Subject: Parties and Necessary Business Uses > > > Please find attached a proposal for party definitions, rules, and permitted > uses with respect to Do Not Track (as promised). A number of those > participating in the W3C TPWG that represent industry and trade associations > collaborated on this proposed text. We look forward to further discussion > in DC next week. > > Thank you, > Shane > > << File: NAI Parties and Necessary Business Uses Proposal Submission.rtf >> > ----- > > Parties and Necessary Business Uses > We appreciate all the hard work being put in by the W3C, the co-chairs, and > all of the stakeholders participating within the Tracking Protection Working > Group. The ultimate objective is a standard that will be implemented by a > significant portion of the ecosystem. A standard that is not adopted does > not benefit consumers and that is everyone’s objective – a practical, > easy-to-use tool that will enhance consumers’ ability to express preferences > about certain data collection and use. In order to make that objective > possible, the following proposal is put forward regarding exemptions as an > attempt to introduce additional important aspects of the DAA Self-Regulatory > Principles for Multi-site Data to the existing discussion on permitted data > uses for necessary business activities when a user expressly turns on > Do-Not-Track (DNT:1). > Part I: Parties > > Definitions > > > A party is any commercial, nonprofit, or governmental organization, a > subsidiary or unit of such an organization, or a person. > For unique corporate entities to qualify as a common party with respect to > this standard, those entities MUST be commonly owned and commonly controlled > (Affiliates). > A First Party is the party that owns the Web site or has control over the > Web site the consumer visits. A First Party also includes the owner of a > widget, search box or similar service with which a consumer interacts. > > NOTE: If a user merely moused over, closed, or muted third-party content, > that is not sufficient interaction > > A Third Party is any party other than a First Party or a user. > > > > Rules > > If a user has not granted an exception (via browser agent or out-of-band > consent) AND if an activity is not allowed under Permitted Uses, THEN the > following general party rules apply when a user expressly sets their > tracking preference to DNT:1: > > > 1st parties MAY collect and profile in the context of the 1st party > experience. > > > > 3rd parties MUST NOT use data across multiple, non-affiliated websites. > > > NOTE: Data collected by a 3rd party MUST be segregated according to the 1st > party from which it was collected. A 3rd party MUST NOT aggregate, > correlate, or use together data that was collected on different 1st party > sites. > > > 3rd parties MUST NOT add collected data to a "profile" of a user. > > > > 3rd parties MUST NOT leverage previously collected transactional data to > profile a user or to alter a user's experience. > > > > 3rd parties MUST NOT attempt to personally identify a user. > > > > A party MUST NOT share (send or receive) collected data or profiles with > another party (unless that party is ONLY working on the behalf of that > specific party – aka Service Provider relationship). > > > NOTE: (Outside of DNT Context): Data legitimately collected and received > from a party MAY be combined with existing 1st party profile data. > > > A party MAY choose to remove any previously profiled data. > > > > All permitted data uses for necessary business activities apply in all > cases. > > > > User granted exceptions (through DNT standard or out-of-band) supersede > these rules. > > > Part II: Permitted Data Uses for Necessary Business Activities when DNT:1 > > For all of these permitted uses, the complying entity must make reasonable > data minimization efforts to ensure that only the data necessary for the > permitted use be retained. This is described under the draft heading "4.4 > Usage-based Permitted Uses." The option to designate that restriction was > not provided by this template so the restriction on scope is highlighted > here and then also applied as an "E" limitation below. > > 1. Frequency Capping - Data MAY be collected and used for the limited > purpose of frequency capping. Restricting the number of times a user agent > displays ads prevents a user from having to see repetitive ads, prevents > publishers from displaying repetitive ads, and prevents advertisers from > harming the reputation of their clients. > > > Examples of important data uses include, but are not limited to: > > • Reach and frequency metrics > • Ad performance > • Logging the number and type of advertisements served on a particular Web > site(s). > (For additional details see DAA Self-Regulatory Principles for Multi-site > Data: Reporting) > > E. This particular use is allowed with reasonable data minimization > efforts > > 2. Financial Logging - Data MAY be collected and used for the limited > purpose of billing or product or service fulfillment. > > Comment: Ad impressions and clicks (and sometimes conversions) events are > tied to financial transactions. > > E. This particular use is allowed with reasonable data minimization > efforts > > 3. 3rd Party Auditing - Data MAY be collected and used for the limited > purpose of 3rd Party Auditing. Online advertising is a billed event and > there are concerns with accuracy in impression counting and quality of > placement so 3rd party auditors provide an independent reporting service to > advertisers and agencies so they can compare reporting for accuracy. > > Comment: This data use serves an important business purpose in preventing > fraud and reasonable data minimization efforts can insure privacy for users > > E. This particular use is allowed with reasonable data minimization > efforts > > 4. Security - Data MAY be collected and used for the limited purpose of > security. Security data is any data reasonably necessary for enabling > authentication/verification, providing fraud prevention, or bolstering > security. > > Comment: Restrictions on security efforts would certainly harm users. We do > not want to mistakenly turn the DNT:1 signal into a signal for user > vulnerability. > (For additional details see the DAA Self-Regulatory Principles for > Multi-site Data: Authentication, Verification, Fraud Prevention and Security > & Compliance, & Public Purpose and Consumer Safety) > > E. This particular use is allowed with reasonable data minimization > efforts > > 5. Contextual Content or Ad Serving - Data MAY be collected and used for the > limited purpose of contextual content or ad serving (examples: serving > advertising or content based on the Web page content, search query, time of > day or general geographic location detected from current interaction only) > as long as the data is used by a party with which the user interacts and is > not collected and used for the purpose of advertising on Web sites of > non-Affiliate parties. > > Comment: Depending on the definition of tracking, defined in Section 3.7, > this exemption may not need to be included because the serving of contextual > ads will not be within the scope of the definition. > > This particular use is allowed without qualification > > 6. Research / Market Analytics - Data MAY be collected and used for the > limited purpose of research & market analytics as long as collection and use > are limited in scope to the analysis of: > > the characteristics of a market or group of consumers; or > the performance of a product, service or feature, in order to improve > existing products or services or to develop new products or services. > > > Data used for this limited purpose is allowed with aggregation. (For > additional details see the DAA Self-Regulatory Principles for Multi-site > Data: Market Research & Product Development) > > D. This particular use is allowed with aggregation where the data may not be > re-identified to market directly back to, or otherwise re-contact a specific > computer or device. > > 7. Product Improvement, or, more narrowly, Debugging – Data MAY be collected > and used for the limited purpose of product improvement. This includes data > used for the express purpose of product improvement related to debugging to > specific events, devices, or site locations. > > E. This particular use is allowed with reasonable data minimization efforts > > 8. Legal Compliance & Public Purpose: Data MAY be collected and used for the > limited purpose of legal compliance and public purpose. This includes, but > is not limited to, intellectual property protection or using location data > for emergency services. > > E. This particular use is allowed with reasonable data minimization efforts > > 9. "Unlinkable" data – we believe this is already covered by general > anonymization and aggregation approaches that are tied to a specific > identifiable individual or device. > > Proposed Definition: The FTC defines “linkable” as “consumer data that can > be reasonably linked to a specific consumer, computer, or other device.” > [Emphasis added] This reflects a scaled approach rather than a bright line > distinction for determining privacy protection. Data is “unlinkable” if it > goes through a de-identification process. A de-identification process is > sufficient when an entity has takenreasonable steps to ensure that the data > cannot reasonably be re-associated or connected to an individual or > connected to or be associated with a particular computer or device. (For > additional details see the DAA Self-Regulatory Principles for Multi-site > Data: De-Identification Process Definition) > > > >
Received on Saturday, 7 April 2012 11:53:30 UTC