Re: Parties and Necessary Business Uses

Sorry, I still don't fully understand how to interpret the text with
regard to normative/non-normative status.    There are at least three
things I don't understand:
1) The notes are supposed to be non-normative, but their text seems to
consist of MUST, MAY, and MUST NOT rules, which are normative
statements.
(2) I'm not sure how to interpret *non-normative* text that advises
the reader to refer to normative text in the DAA documents.
(3) I'm also not sure how to interpret *normative* text that advises
the reader to refer to text in the DAA documents.  Does this mean that
the referenced sections of the DAA documents are meant to be
incorporated as normative requirements of the W3C standard?  Or is it
a non-normative statement that the normative text of this document has
the same meaning as the normative text of the referenced DAA material?

Re-reading the proposal, it looks to me like it contains a third
category of text besides normative and non-normative: helpful
commentary that is informative to readers of the proposal but that is
not meant to appear in the final standard's text (not even
non-normatively).   An example is the comment in part 5; also probably
the last part of the heading of part 9 ("we believe ...").


On Sat, Apr 7, 2012 at 10:36 AM, Shane Wiley <wileys@yahoo-inc.com> wrote:
> Ed,
>
> Notes, Comments, and stand-alone Examples are non-normative text.  For example, on the "Rules" section that we worked with you on in Brussels, the "Note" elements are non-normative.
>
> - Shane
>
> -----Original Message-----
> From: Ed Felten [mailto:ed@felten.com]
> Sent: Saturday, April 07, 2012 4:53 AM
> To: Shane Wiley
> Cc: public-tracking@w3. org Group WG
> Subject: Re: Parties and Necessary Business Uses
>
> 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 21:47:03 UTC