Re: Draft for breakouts - text

Also, I can share the working document (in Google Docs) with folks if that
is easiest.

On Thu, Jun 21, 2012 at 3:02 PM, Heather West <heatherwest@google.com>wrote:

> 3 Definitions
>
> 3.1 Parties
>
> 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) and MUST provide “easy discoverability” of
> affiliate organizations.  An “Affiliate List” MUST be provided within one
> click from each page or the entity owner clearly identified within one
> click from each page.
>
> For example, a clear labeled link to the Affiliate List within the privacy
> policy would meet this requirement or the ownership brand clearly labeled
> on the privacy policy itself.
>
> 3.2  First and Third Parties
>
> A First Party is the party that owns the Web site or has control over the
> Web site the consumer visits. A party may start out as a third party but
> become a first party later on, after a user meaningfully interacts with it.
>
> 3.2.1  Service Providers/Outsourcers
>
> Service Providers acting on the behalf of a First Party and with no
> independent rights to use the First Party’s data outside of the context of
> that 1st party and Permitted Uses are also considered a First Party.
>
> It is possible to have multiple first parties on a single page but each
> party must provide clear branding and a link to their respective privacy
> policy (co-branded experience).
>
> 3.3 Third Party
>
> A Third Party is any party other than a First Party, Service Provider, or
> a user.
>
> 3.4 Unidentified Data
>
> A dataset is un-linkable when commercially reasonable steps have been
> taken to de-identify data such that there is confidence that it contains
> information which could not be linked to a specific user, user agent, or
> device in a production environment, and which the entity will commit to
> make no effort to re-identify, and prohibit downstream recipients of
> un-linkable data from re-identifying it
>
> Note: Un-linkable Data is outside of the scope of the Tracking Preference
> standard as information is no longer reasonably linked to a particular
> user, user agent, or device.
>
> 4 Compliance with an Expressed Tracking Preference
>
> 4.1  First Party Compliance
>
> If a first party receives a communication to which a DNT-1 header is
> attached, the first party must not [pass along/transmit/disclose]
> [identifiable information about the network interaction] with [a separate
> party] with which it does not have a service provider relationship.
>
> First Parties may engage in their normal collection and use, as long as
> they do not pass profile information on to third parties who could not
> collect the data themselves under this recommendation.  This includes the
> ability to customize the content, services, and advertising in the context
> of the first party experience.
>
> 4.1.1 Service Provider to First Party
>
> 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).
> Data collected by a 3rd party under a first party service provider
> relationship 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 use data across multiple, non-affiliated websites.
>
> 4.2  Third Party Compliance
>
> If the operator of a third-party domain receives a communication to which
> a DNT:1 header is attached:
> that operator must not collect, share, or use information related to that
> communication outside of the permitted uses as defined within this standard
> and any explicitly-granted exceptions, provided in accordance with the
> requirements of this standard;
> that operator must not use information about previous communications in
> which the operator was a third party, outside of the explicitly expressed
> permitted uses as defined within this standard;
> that operator may delete information about previous communications in
> which the operator was a third party, outside of the explicitly expressed
> permitted uses as defined within this standard.
>
> 4.3 UA
>
> [PARKED FOR TODAY]
>
> 4.4 Permitted uses for Third Parties and Service Providers
>
> For each of the Permitted Uses outlined, the following requirements apply:
> Outside of Security, all other Permitted Uses will not allow for altering
> a specific user’s online experience based on multi-site activity, including:
> No profiling
> No further alteration to the user experience based on profiled information
> based on multi-site activity
> Customization outside of multi-site activity profiles is allowable
> Each party engaging in Permitted Uses and claiming W3C DNT compliance,
> MUST provide public transparency of their data retention period
> Party MAY enumerate each individually if they vary across Permitted Uses
> Reasonable technical and organizational safeguards to prevent further
> processing.
> <non-normative>
>
> Examples of acceptable safeguards:  collection limitations, data siloing,
> authorization restrictions, k-anonymity, unlinkability, retention time,
> anonydmization, pseudonymization, and/or data encryption.
>
> NOTE:  While definitely a Permitted Use, compliance with local laws and
> public purposes, such as copyright protection and delivery of emergency
> services, is not listed separately.
>
>
>  1. Security
>
> Data MAY be collected and used for the express and limited purpose of
> security and fraud detection and defense.  This includes data reasonably
> necessary for enabling authentication/verification, detecting hostile
> transactions and attacks, providing fraud prevention, or bolstering site
> and system security.
>
> <Non-Normative>
> Restricting security and fraud detection and defense efforts could harm
> users.  We do not want to mistakenly turn Do Not Track into a signal for
> user vulnerability.
>
> Resources:  For additional details on the uses of Security data please see
> the DAA Self-Regulatory Principles for Multi-site Data: Authentication,
> Verification, Fraud Prevention and Security & Compliance, & Public Purpose
> and Consumer Safety
>
> <Normative>
> 2. Financial Purposes
>
>  - Data MAY be collected and used for the limited purpose of financial
> fulfillment such as billing and audit compliance.  This purpose is strictly
> necessary for the continued operation of most websites and requires
> uniqueness to prove user interactions (ad impression and ad click) were
> indeed achieved as billed for.
>
> 3. Frequency Capping
>
> Data MAY be collected and used for the limited purpose of frequency
> capping – the practice of keeping “count” of the number of times a user or
> device has seen a specific ad and then halting further display of that ad
> once the designated threshold has been reached.
> 4. Product Debugging
>
> Data MAY be collected and used for the limited purpose of identifying and
> repairing site errors to intended functionality (“Debugging”).
> 5. Aggregate Reporting
>
> Data MAY be collected and used for the express and limited purpose of
> aggregate reporting.  Aggregate reporting end-points should meet the
> objectives of “unlinkability” (see below) and therefore are outside of the
> scope of the DNT standard.  There is a time interval necessary to retain
> event level records to aggregate across the necessary time spans accurately
> (daily, weekly, monthly, quarterly, etc.).
>
>
> Appendix
>
> Issues to bring up separately:
> Data collected and received from a party MAY be combined with existing 1st
> party profile data.
>
>  Non-Normative: Unidentified
>
> There are many valid and technically appropriate methods to de-identify or
> render a data set "un-linkable".  In all cases, there should be confidence
> the information is unable to be reverse engineering back to a "linkable"
> state.  Many tests could be applied to help determine the confidence level
> of the un-linking process.  For example, a k-anonymous test could be
> leveraged to determine if the mean population resulting from a de-linking
> exercise meets an appropriate threshold (a high-bar k-anonymous threshold
> would be 1024).
>
> As there are many possible tests, it is recommended that companies
> publically stating W3C Tracking Preference compliance provide transparency
> to their delinking process (to the extent that it will not provide
> confidential details into security practices) so external experts and
> auditors can assess if they feel these steps are reasonable given the risk
> of a particular dataset.
>
> Information That Is Un-linkable When Collected:  A third party may collect
> non-protocol information if it is, independent of protocol information,
> un-linkable data. The data may be retained and used subject to the same
> limitations as protocol information.
>
> Example: Example Advertising sets a language preference cookie that takes
> on few values and is shared by many users.
>
> Information That Is Un-linkable After Aggregation:  During the period in
> which a third party may use protocol information for any purpose, it may
> aggregate protocol information and un-linkable data into an un-linkable
> dataset. Such a dataset may be retained indefinitely and used for any
> purpose.
>
> Example: Example Advertising maintains a dataset of how many times per
> week Italy-based users load an ad on Example News.
>
> Information That Is Un-linkable After Anonymization:  At some point after
> collection, a unique ID from a product cookie has a one-way salted hash
> applied to the identifier to break any connection between the resulting
> dataset and production identifiers.  To further remove dictionary attacks
> on this method, its recommended that "keys" are rotated on a regular basis.
>
> Non-Normative: Permitted Uses
>
> In order to avoid DNT significantly impacting the availability of free
> content on the Internet a balance is necessary to allow for minimal data
> use to continue standard site operations – including those that monetize
> site activities.
>
>
> Non-Normative: Aggregate Reporting
>
> While detailed event level data is not present at the outcome of
> aggregated reporting it is a necessary ingredient to arrive there.
>
> Examples of uses of aggregate reporting:
> Product Improvement (via Site Analytics)
> Navigation (Referring sites, Exit Points, Internal Navigation used or not
> used)
> Visitor Counts (New, Returning, High Activity, Low Activity)
> Market Research
>
> 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.
>
> References:  For additional examples and associated details see the DAA
> Self-Regulatory Principles for Multi-site Data: Market Research & Product
> Development
>
> Non-Normative - product debugging
>
> Detailed information is often necessary to replicate a specific user’s
> experience to understand why their particular set of variables is resulting
> in a failure of expected functionality or presentation.
>
> These variables could include items such as:
> cookie IDs
> URL of the page
> device (UA) details
> content specifics
> activity/event specifics to narrow in on the cause of the discrepancy
>
> Non-Normative: frequency capping
>
> NOTE:  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).
> Reporting
> Reference:  For additional examples and associated details please see the
> DAA Self-Regulatory Principles for Multi-site Data:
>
> Non-Normative: Financial purposes
>
> NOTE:  Typically all relevant advertising order criteria is necessary for
> retention of ad interactions.
> Examples of data uses include, but are not limited to:
> Ad Impression verification (CPM)
> Ad Click verification (CPC)
> Site Conversion associated with Ad Impression or Ad Click (CPA)
> Quality Measures such as ad position (location on page, above/below fold)
> and site the ad was served on (high quality vs. low quality content
> association)
> Reference:  For additional examples and associated details please see the
> IAB Financial Audit Guidelines.
>
> Closing
>
> We believe this proposal advances the existing opt-out cookie structure
> (albeit that is a fair and good one) and evolves online privacy in several
> ways:
>
> Users gain a consistent, local tool to communicate their opt-out preference
> Avoids property specific opt-out pages
> The user's choice is persistent for each device/UA
> Avoids accidental deletion
> Outside of Security purposes, the user will no longer experience
> alterations to their online experiences derived from multi-site activity
> No profiling <aka "tracking"> and extends beyond online behavioral
> advertising
> Only minimal data is retained for necessary business operations and
> retention periods are transparent to users
> The Internet remains a viable ecosystem for free content
> All real “harms” are removed
> Outside of government intrusion risk where there are no documented cases
> of this occurring with 3rd party anonymous log file data
>
> We hope you agree this clearly advances the already established opt-out
> program offered to users with many key new additions and evolved
> perspectives to what was already a long and hard negotiated outcome for
> users of the current Internet.  The online privacy debate did not begin
> with the W3C Tracking Protection Working Group and most definitely won't
> end with it but through collective agreement with this proposal we will
> have marked an important date in the positive progression of the online
> privacy debate.
>
> --
>
> Heather West | Google Policy | heatherwest@google.com | 202-643-6381
>



-- 

Heather West | Google Policy | heatherwest@google.com | 202-643-6381