- From: Aleecia McDonald via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 19 Jun 2012 09:31:13 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory hutz:/tmp/cvs-serv3431/drafts
Added Files:
combo-draft.html
Log Message:
adding the combo draft I'd sent to the dlist last week
--- NEW FILE: combo-draft.html ---
<!DOCTYPE html>
<html>
<head>
<title>Do Not Track — Combined Proposal</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
<script class="remove">
var respecConfig = {
extraCSS:["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
editors:[
{ name: "Aleecia M. McDonald", company: "Mozilla"}
],
specStatus: "unofficial"
}
</script>
</head>
<body>
<section id="abstract">
<p>
This partial draft attempts to reflect some of the points of consensus across multiple proposals presented at the Washington, DC f2f meeting, including <a href="http://www.w3.org/2011/tracking-protection/track/issues/10">issue-10</a> (what is a first party), <a href="http://www.w3.org/2011/tracking-protection/track/issues/17">issue-17</a> (data use by a first party), <a href="http://www.w3.org/2011/tracking-protection/track/issues/19">issue-19</a> (data collection and use by a third party), <a href="http://www.w3.org/2011/tracking-protection/track/issues/31">issue-31</a> (data minimization), <a href="http://www.w3.org/2011/tracking-protection/track/issues/49">issue-49</a> (third party on behalf of first party), and <a href="http://www.w3.org/2011/tracking-protection/track/issues/73">issue-73</a> (silo v. contract for outsourcing partner). It does not get into the disputed areas of <a href="http://www.w3.org/2011/tracking-protection/track/issues/22">issue-22</a> (operational use), <a href="http://www.w3org/2011/tracking-protection/track/issues/24">issue-24</a> (fraud exemption), <a href="http://www.w3.org/2011/tracking-protection/track/issues/25">issue-25</a> (research exemption).
</p>
<p>
If you remember the eight page poster on the wall with only two points of major disagreement in DC, this draft tries to capture the parts where we basically agreed. The idea is to have a format we can now go through and tweak and fix, then hand off to the Compliance editors to integrate into a public draft. Our next step is to see where we have consensus on these issues, where we are still working out wording, and where there are differences. Please review this text carefully prior to discussions during the Seattle f2f.
</p>
<p>
Much of the text comes from two proposals, one from Jonathan / Peter / Tom, the other from Shane et. al. Extraordinarily little text is actually new. The structure is different, with definitions pulled to the beginning and a simplified hierarchy.
</p>
</section> <!-- closes abstract -->
<section id="definitions">
<h1>Definitions</h1>
<p>
A <dfn>functional entity</dfn> is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person.
</p>
<p>
Functional entities are <dfn>affiliated</dfn> when they are related by both common majority ownership and common control.
</p>
<p>
A <dfn>party</dfn> is a set of functional entities that are affiliated and follow requirements to be easily discoverable.
</p> <!-- link to easily discoverable later in the document. -->
<p>
A <dfn>network interaction</dfn> is an HTTP request and response, or any
other set of logically related network traffic.
</p>
<p>
An <dfn>outsourced party</dfn> is any <a>party</a>, in a specific <a>network interaction</a>, that is working on behalf of a specific first or third party in compliance with the outsourced party information practices.
</p>
<p>
A <dfn>first party</dfn> is any <a>party</a> in a specific <a>network
interaction</a> that can infer with high probability that the user knowingly and intentionally communicated with it, and complies with DNT under first party information practices.
</p> <!-- link to those practices -->
<p>
A <dfn>third party</dfn> is any <a>party</a> in a specific <a>network
interaction</a> that is not a <a>first party</a>, an <a>outsourced party</a>, or the user. A party without the ability to infer with high probability that the user knowingly and intentionally communicated with it MUST represent itself as a third party and comply with third party information practices. A first party MAY choose to represent itself as a third party and comply with third party information practices.
</p> <!-- link to those practices -->
<p>
A dataset is <dfn title="unidentifiable data">unidentifiable</dfn> when there is a high probability that it contains only information which could not be linked to a particular user, user agent, or device by a skilled analyst. N-unlinkability is the special case of K-anonymity where all values are considered part of the pseudo-identifier.
</p>
<p>
<dfn>Protocol information</dfn> includes:
<ul>
<li>any information that a user agent necessarily shares with a web server when it communicates with the web server (e.g. IP address and User-Agent), and </li>
<li>the URL of the top-level page, whether communicated via a Referer header or other means.</li>
</ul>
</p>
<p>
Protocol information does not include:
<ul>
<li> any information that a web server could cause to not be sent but still communicate with the user agent (e.g. a cookie or a Request-URI parameter generated by the user agent), except the URL of the top-level page, and </li>
<li> any data added by a network intermediary that the operator of a web server has actual knowledge of (e.g. a unique device identifier HTTP header). </li>
</ul>
</li>
<p>
A <a>party</a> <dfn title="collect">collects</dfn> data if the data comes within its control and the control of that data is not transient.
</p>
<p class="note">Open action on defining collection; this is not done</p>
<p>
A <a>party</a> <dfn title="retain">retains</dfn> data if the data remains within the party's control.
</p>
<p>
A <a>party</a> <dfn title="use">uses</dfn> data if the party processes the data for any purpose, including for storage.
</p>
<p>
A <a>party</a> <dfn title="share">shares</dfn> data if the party enables another party to collect the data.
</p>
</section> <!-- closes definitions, h1 -->
<hr>
<!------------------------------------------------------------------------- ->
<!-- <section id="infoPracticesForAll"> -->
<section>
<h1>Information Practices for All Parties</h1>
<p>
This section of the specification applies to all <a>parties</a> who comply with an incoming DNT signal. See the companion [[!TRACKING-DNT]] document for information on how to respond to an incoming signal.
</p>
<section>
<h2>Additional Voluntary Measures</h2>
<p>
This specification sets a minimum common standard for compliance. Any party MAY take additional steps to protect user privacy when responding to a Do Not Track request.
</p>
</section> <!-- closes additional voluntarty measures, h2 -->
<section>
<h2>User Permission and Consent</h2>
<p class="note"> We have discussed this at length in action-152, action-157, and action-159. This section attempts to merge several texts together.</p>
<p>
Sites MAY override a user's DNT preference if they have received explicit, informed consent to do so.</p>
<p>A party may engage in practices otherwise prohibited by this standard if a user grants permission. When seeking an exemption, sites SHOULD communicate those requests clearly, accurately, and in line with consumer protection laws in the jurisdictions in which they operate. Permission may be attained through either (A) the browser API defined in the companion [[!TRACKING-DNT]] document or (B) an "out-of-band" consent attained through a different technology. An "out-of-band" choice mechanism has the same effect under this standard as the browser exception API.
<p>A party may receive multiple conflicting signals from users. Specific permission overrides a general permission. If a party has received prior consent for tracking a given user, user agent, or device, that consent overrides the general preference indicated by the DNT header field. If a party chooses to track based on that prior consent, the corresponding tracking status MUST indicate that tracking is occurring based on consent and SHOULD supply a link to a means for the user to remove or modify that consent, as described in [[!TRACKING-DNT]].
For example, if you have two conflicting signals from a user with a global DNT:1 yet also have the user's consent specific to you (via browser API or out-of-band consent) then the user's consent is the correct signal to follow.
</p>
<p>An "out-of-band" choice mechanism MUST additionally satisfy the following condition: An ordinary user would know that the choice overrides his or her general Tracking Preference.</p>
<section class="informative">
<h3>Non-normative</h3>
<p>Many organizations have developed direct consent mechanisms for web-wide tracking prior to this standard. Interactions with users to obtain consent may be contextual. For example, if a service has an obvious cross-site tracking function that the user deliberately signs up for then this could be deemed to have achieved “explicit and informed” consent from a user without directly addressing its relation to a Tracking Preference (which wasn’t contemplated at the time the consent experience was designed). Even in these cases, organizations should recall that users with DNT:1 are requesting privacy, and strongly consider providing Tracking Preference references in associated product or service materials such as a privacy policy, help center, or a separate notice to users who have indicated preferences for privacy. Organizations should also scope the user's consent to the task the user is likely to understand. For example, a user who signed up for a news tracking service that would note which articles h or she read across the entire web in order to suggest relevant articles in the future might consider just using the service as sufficient contextual consent for gathering information about news. However, that does not mean the user has also consented to that information being used in any other context or by other parties. Contextual consent is specific to a product or feature, as understood by the user.</p>
<p>Companies should not seek to obtain explicit, informed consent from users in non-obvious ways such as placing these details in their Terms of Service or their Privacy Center if it will not be obvious to users that the nature of the service will lead the company to ignore a user’s Tracking Preference based on the nature of the consent the user is granting. As an example where context would be insufficient to establish consent, a company could not obtain explicit, informed consent to ignore DNT in third-party settings by placing notice in a privacy policy or the terms of use for an email service or a game if that company also happens to own an advertising network. The company would need to present users with a request for consent. It is a good practice to present a choice that signing up for a service will override a Tracking Preference setting, or the option to decline the service, at the time the user's choice is being made. The W3C geolocation API is one example of out-of-band consent, which we dscuss in the section on geolocation.</p> <!-- add link to geoloc API -->
<p>Out-of-band consent will be further reinforced in user interactions through either the Header Response or Well-Known URI approaches to replying to user Tracking Preferences. This will provide a constant reminder of prior consent on each interaction and provide a resource (link) to allow the user to understand how this consent was achieved and ideally present options to alter that consent if the user chooses to do so.</p>
<p>We suggest the following properties for any out-of-band consent mechanism:
</p>
<dl>
<dt>Actual presentation</dt>
<dd>The choice mechanism must be actually presented to the user. It must not only be on a linked page, such as a terms of service or privacy policy.</dd>
<dt>Clear terms</dt>
<dd>The choice mechanism must use clear, non-confusing terminology.</dd>
<dt>Independent choice</dt>
<dd>The choice mechanism must be presented independent of other choices. It must not be bundled with other user preferences.</dd>
<dt>No default permission</dt>
<dd>The choice mechanism must not have the user permission preference selected by default.</dd>
</dl>
<p>What constitutes explicit consent is not necessarily the same across all legal jurisdictions. It is the site's responsibility to ensure that it has consent.</p>
</section> <!-- closes non-normative, h3-->
</section> <!-- closes user permission, h2-->
<section id="unidentifiableData">
<h2>Unidentifiable Data</h2>
<p>
Any <a>party</a> MAY <a>collect</a>, <a>retain</a>, or <a>use</a> <a>unidentifiable
data</a>, subject to the requirements that the <a>party</a> MUST either:
</p>
<ol>
<li> publicly publish information that is sufficiently detailed for a skilled analyst to evaluate the implementation, or </li>
<li> ensure that any datasets are at least 1024-unlinkable.</li>
</ol>
<p>
Unidentifiable information will either be unidentifiable at the time of collection, or be made unidentifiable by aggregating data after it is collected; both are described below.
</p>
<section>
<h3>Information That Is Unidentifiable When Collected</h3>
<p>
A <a>party</a> may collect non-<a>protocol information</a> if it is, independent of <a>protocol information</a>, <a>unidentifiable data</a>. The data may be <a>retained</a> and <a>used</a> subject to the same limitations as <a>protocol information</a>.
</p>
<pre class="example">
Example Advertising sets a language preference cookie that stores one of a
few values, such as us, de, and so on, and thousands of users share the
same language preference.
</pre>
</section> <!-- closes unidentifiable when collected <h3> -->
<section>
<h3>Information That Is Unidentifiable After Aggregation</h3>
<p class="note">If we do not adopt the notion of a grace period for log files, then this section applies only to parties that know they are always first parties. For everyone else, the only form of permitted aggregation will be at the point of collection as things are currently written.</p>
<p>
During the period in which a <a>party</a> may use <a>protocol information</a> prior to processing, it may aggregate <a>protocol information</a> and <a>unidentifiable data</a> into an unidentifiable dataset. Such a dataset may be retained indefinitely and used for any purpose.
</p>
<pre class="example">
Example Advertising maintains a dataset of how many times per week
Italy-based users load an ad on Example News.
</pre>
</section> <!-- closes unidentifiable after aggregation <h3> -->
<section class="informative">
<h3>Non-normative</h3>
<p class="note">It would be helpful to describe what 1024-unlinkable means so we do not send implementers scrambling for other texts. Also useful, a discussion that this can be either calculated mathematically (with a pointer to a readable reference) or by estimating based on actual data, perhaps with non-DNT users or pre-DNT users.</p>
</section> <!-- closes non-norm for aggregate data <h2> -->
</section> <!-- closes unidentifiable data <h2> -->
<section id="discoverability">
<h2>Discoverability</h2>
<p class="note">While there is disagreement over whether discoverability is sufficient, we do seem to be converging on what discoverability is. Should we decide discoverability is not helpful, or insufficient, we can easily remove this section.</p>
<p>
A <a>functional entity</a> must make its <a>affiliated</a> functional entities easily discoverable by a user.
</p>
<section class="informative">
<h3>Non-Normative Discussion</h3>
<p>
Affiliation may be made easily discoverable by a user in many ways, including but not limited to: prominent and common branding on pages, one click away within a privacy policy, or a machine-readable format in a well-known location. As a general guideline: if a lawsuit could be brought against two different entities, they are not the same <a>functional entity</a>. Similarly, if two portions of a legal entity have different privacy policies, they should not be considered the same functional entity under Do Not Track.
</p>
</section> <!-- closes non-norm discoverability -->
</section> <!-- closes discoverability <h2> -->
<section>
<h2>Additional Requirements Based on Party Status</h2>
<p>
In addition to the information practices for all <a>parties</a> as described in this section, for each <a>network interaction</a> an additional set of information practices applies based on which type of party you are during that <a>network interaction</a>: <a>first party</a>, <a>outsourced party</a>, or <a>third party</a>.
</p>
<section class="informative">
<h3>Non-Normative Discussion</h3>
<p>Determination of a party's status is limited to a single
transaction because a party's status may be affected by time,
context, or any other factor that influences user expectations. Other
than some third parties becoming first parties when users interact
(for example, social widgets or ads,) party status will usually stay
stable for the entire interaction with a given user.
</p>
</section> <!-- closes non-norm additional requirements, h3 -->
</section> <!-- closes additional requirements based on party status, h2 -->
</section> <!-- closes info practices for all implementers <h1> -->
<hr>
<!------------------------------------------------------------------------- ->
<!-- <section id="firstParty"> -->
<section>
<h1>Information Practices for First Parties</h1>
<p>
This section of the document applies just to <a>first parties</a>.
</p>
<p>
A <a>first party</a> MUST NOT share information with a <a>third party</a> that the <a>third party</a> is prohibited from collecting itself. A <a>first party</a> MUST NOT <a>share</a> (send or receive) identifiable information about a user to any party it does not have an outsource relationship with.
</p> <!-- add links here for identifiable and outsource-->
<p class="note">While confining data just to the first party reflects discussions of the TPWG to date, newer members have concerns about these provisions.</p>
<section class="informative">
<h2>Non-Normative Discussion</h2>
<section>
<h3>Overview</h3>
<p>We draw a distinction between those parties an ordinary user would
or would not expect to share information with, "first parties" and
"third parties" respectively. The delineation exists for three
reasons.</p>
<p>First, when a user expects to share information with a party,
she can often exercise control over the information flow.
Take, for example, Example Social, a popular
social network. The user may decide she does not like Example
Social's privacy or security practices, so she does not visit
examplesocial.com. But if Example Social provides a social sharing
widget embedded in another website, the user may be unaware she is
giving information to Example Social and unable to exercise control
over the information flow.</p>
<p>Second, we recognize that market pressures are an important factor
in encouraging good privacy and security practices. If users do not
expect that they will share information with an organization, it is
unlikely to experience market pressure from users to protect the security
and privacy of their information. In practice, moreover, third parties
may not experience sufficient market pressure from first parties
since increasingly third parties do not have a direct business relationship
with the first party websites they appear on. We therefore
require a greater degree of user control over information sharing
with such organizations. </p>
<p>Last, third parties are often in a position to collect a sizeable
proportion of a user's browsing history — information that can be
uniquely sensitive and easily associated with a user's identity. We
wish to provide user control over such information flows.</p>
<p>We recognize that, unlike with a bright-line rule, there can be
close calls in applying our standard for what constitutes a first
party or a third party. But we believe that in practice, such close
calls will be rare. The overwhelming majority of content on the web
can be classified as first party or third party, with few cases of ambiguity
in practice.</p>
<p>We require a confidence at a "high probability" before a party can
consider itself a first party. Where there is reasonable ambiguity
about whether a user has intentionally interacted with a party, it
must consider itself a third party. Our rationale is that, in
the rare close cases, a website is in the best position to understand
its users' expectations. We therefore impose the burden of
understanding user expectations on the website. We also wish, in
close cases, to err on the side of conforming to user expectations
and protecting user privacy. If the standard is insufficiently
protective, ordinary users have limited recourse; if the standard
imposes excessive limits, websites retain the safety valve of explicitly
asking for user permission.</p>
</section> <!-- closes overview, h3 -->
<section>
<h3>Common Examples and Use Cases</h3>
<ol>
<li>A user accesses an Example News article. The page includes an
advertisement slot, which loads content from many companies other
than Example News. Those companies are third parties.</li>
<li> A user accesses an Example News article. The page includes an
analytics script that is hosted by Example Analytics, an analytics
service. Example Analytics is a third party.</li>
<li> A user accesses an Example News article. It includes a social
sharing widget from Example Social, a popular social network.
Example Social is a third party.</li>
<li> A user visits Example Diary, which is hosted by the free blogging
service Example Blog Hosting but located at examplediary.com. Example
Blog Hosting is a third party.</li>
<li> A user launches Example Application, an app on a mobile device.
The app includes a library from Example Advertising Network that displays
ads. Example Advertising Network is a third party.</li>
</ol>
</section> <!-- closes examples & use cases, h3 -->
<section>
<h3>Multiple First Parties</h3>
<p>
There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominently advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.
</p>
</section> <!-- closes Multiple First Parties, h4 -->
</section> <!-- closes Non-normative, h3 -->
</section> <!-- closes First Party, h2 -->
</section> <!-- closes info practices for first parties -->
<hr>
<!-- --------------------------------------------------------------------- -->
<section>
<h1>Information Practices for Third Parties</h1>
<p>This section of the document applies just to third parties. </p>
<section>
<h2>General Rule</h2>
<p>
A <a>third party</a> may not <a>collect</a>, <a>retain</a>, <a>use</a>, or <a>share</a> any information related to communication with a user or user agent. There are exceptions to this general rule as defined in the following sections.
</p>
</section> <!-- closes general rule, h2 -->
<section>
<h2>Permitted Uses</h2>
<p>
We recognize a limited set of data uses as important enough to continue even with data in potentially identifiable form. For all other uses, many of which are quite valuable, sites can ask users for permission. Note that <a>first parties</a> are not constrained to permitted uses. <a>Outsourced parties</a> may act as the party they work with would act: if working with a <a>third party</a>, they are also bound to this list of permitted uses.
</p>
<p class="note">While we agree on this general structure, we do not agree on uses at this point.</p>
</section> <!-- closes permitted uses, h2 -->
<section>
<h2>User Interaction with Third Party Content</h2>
<p>
A party may start out as a third party but become a first party
later on, after a user interacts with it. If content from a third
party is embedded on a first party page, the third party may become
an additional first party if it can infer with high probability that
the average user knowingly and intentionally communicated with it.
If a user merely moused over, closed, or muted third party content,
the party would not be able to draw such an inference.
</p>
<section class="informative">
<h3>Examples and Use Cases</h3>
<p><b>Example:</b> Example Weather offers an unbranded weather widget
that is embedded into websites, including Example News. The widget
contains small links to Example Weather's website and privacy
policy. A user visits Example News and scrolls through the weekly
forecast in the Example Weather widget.</p>
<p><b>Discussion:</b> Example Weather is a third party. The user has
interacted with Example Weather's widget, but an ordinary user would
not expect that scrolling through the widget involves communicating
with Example News.</p>
<p><b>Example:</b> Example Social, a popular social network, hosts a
social sharing button that other websites can embed. The button is
colored and styled in the same fashion as Example Social's website,
contains descriptive text that is specific to Example Social,
includes Example Social's logo, and very frequently appears on
Example Social's website. Example News embeds the Example Social
button, and a user clicks it.</p>
<p><b>Discussion:</b> Example Social is a first party once the user clicks its
embedded social sharing button. The average user would understand that by
clicking the button she is communicating with Example Social.</p>
</section> <!-- closes examples and use cases, h3 -->
</section> <!-- closes user interaction with 3rd party content, h2 -->
</section> <!-- closes info practices for third parties, h1 -->
<hr>
<!------------------------------------------------------------------------- ->
<!-- <section id="outsource"> -->
<section>
<h1>Information Practices for Outsourcing</h1>
<p>
This section applies to parties engaging in an outsourcing relationship, wherein one party "stands in the shoes" of another party to perform a specific task. Both parties have responsibilities, as detailed below.
</p>
<p>
A <a>first party</a> or a <a>third party</a> MAY outsource functionality to another <a>party</a>, in which case the <a>third party</a> may act as the original <a>first party</a> or <a>third party</a> under this standard, with the following additional restrictions:
</p>
<ul>
<li> Data collected by each outsourced company is separated for each party they collect data for by both technical means and organizational process, AND </li>
<li> The outsourced company has no independent rights to the collected information, AND </li>
<li> A contractual relationship exists between the outsourced and the party they collect data for that outlines and mandates these requirements. </li>
</ul>
<p>An outsourced company acting on the behalf of another party is subject to all of the same restrictions on that party (for First or Third party, as appropriate.)</p>
<section class="informative">
<h2>Non-Normative</h2>
<p>Outsourced companies that act purely as vendors for their customers (often first parties in this context) are not the intended target for the Tracking Preference Expression but it is important there are no unintended activities that are extended to another party through this allowance. In all cases, its expected an outsourced company acting on the part of a customer follows all of the same restrictions placed on that customer.</p>
<p>For the data separation requirement, outsourced companies have technical options to achieve appropriate separation but in each the critical element is that data is never reconstituted for users that have indicated a preference not to be tracked. One possible approach would be to leverage a per partner hash against a common cookie identifier, ensuring the resulting identifier is consistent for a specific customer, but is unable to be linked with another customer’s identifier.</p>
<p>Contractual requirements that enforce data rights and responsibilities for separation are a critical element of establishing an outsourcer acting on another party’s behalf. Contracts may occur directly through parties (for example, a Publisher in an Ad Network) or between intermediaries (for example, an Ad Network acting through an Ad Exchange). In either case, data separation and removal of independent rights are necessary elements that must survive intermediary contractual constructs.</p>
</section> <!-- closes non-normative, h2 -->
<section>
<h2>Technical Precautions</h2>
<p>
Throughout all data <a>collection</a>, <a>retention</a>, and <a>use</a>, outsourced parties MUST use all feasible technical precautions to both mitigate the identifiability of and prevent the identification of data from different first parties.
</p>
<p>
Structural separation ("siloing") of data per first party, including both
<ol>
<li>separate data structures and</li>
<li>avoidance of shared unique identifiers</li>
</ol>
<p>
are necessary, but not necessarily sufficient, technical precautions.
</p>
</section> <!-- closes technical precautions, h2 -->
<section class="informative">
<h2>Non-Normative Discussion</h2>
<section>
<h3>Siloing in the Browser</h3>
<p>
Outsourcing services should use browser access control features so that stored data specific to one party is never accessed or collected when the user visits another party.
</p>
<section>
<h4>Same-Origin Policy</h4>
<p>
The same-origin policy silos stored data by domain name. An outsourcing service can use a different domain name for each first party.
</p>
<pre class="example">
Example Analytics provides an outsourced analytics service to Example News
and Example Sports, two unrelated websites. Example Analytics stores its
cookies for Example News at examplenews.exampleanalytics.com, and it
stores its cookies for Example Sports at
examplesports.exampleanalytics.com.
</pre>
</section> <!-- closes same origin policy, h4 -->
<section>
<h4>Cookie Path Attribute</h4>
<p>
The HTTP cookie path can be used to silo data to a first party.
</p>
<pre class="example">
Example Analytics stores its cookies for Example News with
"Path=/examplenews", and it stores its cookies for Example Sports with
"Path=/examplesports".
</pre>
</section> <!-- closes cookie path attribute, h4 -->
<section>
<h4>Storage Key</h4>
<p>
For key/value storage APIs, such as Web Storage and Indexed Database, an outsourcing service can use a different key or key prefix for each first party.
<pre class="example">
Example Analytics stores data for Example News at
window.localStorage["examplenews"] and data for Example Sports at
window.localStorage["examplesports"].
</pre>
</section> <!-- closes storage key, h4 -->
</section> <!-- closes siloing in the browser, h3 -->
<section>
<h3>Siloing in the Backend</h3>
<section>
<h4>Encryption Keys</h4>
<p>
An outsourcing service should encrypt each <a>first party</a>'s data with a different set of keys.
</p>
</section> <!-- closes encryption keys, h4 -->
<section>
<h4>Access Controls</h4>
<p>
An outsourcing service should deploy access controls so that only authorized personnel are able to access siloed data, and only for authorized purposes.
</p>
</section> <!-- closes access controls, h4 -->
<section>
<h4>Access Monitoring</h4>
<p>
An outsourcing service should deploy access monitoring mechanisms to detect improper use of siloed data.</p>
</section> <!-- closes access monitoring, h4 -->
</section> <!-- closes siloing in the Backend, h3 -->
<section>
<h3>Retention in the Backend</h3>
<p>
An outsourcing service should <a>retain</a> information only so long as necessary to provide necessary functionality to a first party. If a service creates periodic reports, for example, it should delete the data used for a report once it is generated. An outsourcing service should be particularly sensitive to retaining protocol logs, since they may allow correlating user activity across multiple first parties.
</p>
</section> <!-- closes retention in the backend, h3 -->
</section> <!-- closes Non-Normative Discussion, h2 -->
<section>
<h2>Internal Practices</h2>
<p>
Throughout all data collection, retention, and use, outsourced parties MUST use sufficient internal practices to prevent the identification of data from different parties.
</p>
<section class="informative">
<h3>Non-Normative Discussion</h3>
<section>
<h4>Policy</h4>
<p>
An outsourcing service should establish a clear internal policy that gives guidance on how to <a>collect</a>, <a>retain</a>, and <a>use</a> outsourced data in compliance with this standard.
</p>
</section> <!-- closes policy, h4 -->
<section>
<h4>Training</h4>
<p>
Personnel that interact with outsourced data should be familiarized with internal policy on compliance with this standard.
</p>
</section> <!-- closes Training, h4 -->
<section>
<h4>Supervision and Reporting</h4>
<p>
An outsourcing service should establish a supervision and reporting structure for detecting improper access.
</p>
</section> <!-- closes supervision and reporting, h4 -->
<section>
<h4>Auditing</h4>
<p>
External auditors should periodically examine an outsourcing service to assess whether it is in compliance with this standard and has adopted best practices. Auditor reports should be made available to the public.
</p>
</section> <!-- closes auditing, h4 -->
</section> <!-- closes non-normative discussion, h3 -->
</section> <!-- closes internal practices, h2 -->
<section>
<h2>Use Direction</h2>
<p>
An outsourced service:
</p>
<ol>
<li>MUST <a>use</a> data <a>retained</a> on behalf of a <a>party</a> ONLY on behalf of that <a>party</a>, and</li>
<li>MUST NOT <a>use</a> data <a>retained</a> on behalf of a <a>party</a> for their own business purposes, or for any other reasons.</li>
</ol>
</section> <!-- closes use direction, h2 -->
<section>
<h2>First Party or Third Party Requirements</h1>
<section>
<h3>Representation</h3>
<p>
A <a>party</a>'s representation that it is in compliance with this standard includes a representation that its outsourcing parties comply with this standard.
</p>
</section> <!-- closes representation, h3 -->
<section>
<h3>Contract</h3>
<p>
A <a>first party</a> MUST enter into a contract with an outsourced party that requires that outsourced party to comply with these requirements.
</p>
</section> <!-- closes contract, h3 -->
</section> <!-- closes first or third party requirements, h2 -->
</section> <!-- closes information practices for outsourcing, h1 -->
<!-- -------------------------------------------------------------->
<!-- commenting out permitted uses and adding to the end, since we do not have agreement here.
<section>
<h3>Protocol Information</h3>
<p>
A <a>third party</a> MAY <a>collect</a> and <a>use</a> <a>protocol information</a> for any purpose, subject to a two-week retention period.
</p>
<section class="informative">
<h4>Non-Normative Discussion: Contextual Personalization</h1>
<p>
Under the general rule on protocol information a third party MAY temporarily use a top-level page URL for the purpose of contextually personalizing content.
</p>
</section> <!-- closes non-norm contextual, h4 -->
<!--
<section>
<h3>Additional Limit on Geolocation</h3>
<p>
Under the general rule a third party MAY temporarily use an IP address for geolocation. The geolocation MUST be coarse.
</p> <!-- I KNOW we have better text on this. -->
<!--
<section class="informative">
<h4>Non-normative</h4>
<p>
The <a href="http://www.w3.org/TR/geolocation-API/">Geolocation API</a> available in web browsers is one mechanism by which fine-grained location information can be requested by a website. This API ensures that location information is only sent with the express permission of the user. Use of this API would be an example of specific consent being granted for the use of more granular location data. A user explicitly typing a location into a website, such as entering an address in a form or selecting a location on a map, would also be an example of specific consent being granted.
</p>
<p>
Not all mechanisms for consent for geolocation data are sufficient. Some geolocation permission models are insufficiently granular for third-party DNT purposes (e.g. smartphone OSes that support geolocation permissions per first-party app).
</p>
</section> <!-- closes non-normative, h4 -->
<!--
</section> <!-- closes geoloc, h3 -->
<!--
<section>
<h3>Security and Fraud Prevention</h3>
<p>
A <a>third party</a> MAY <a>collect</a> and <a>use</a> <a>protocol information</a> for the detection and prevention of security breaches and fraudulent activity, subject to a six-month retention period and the restrictions imposed in the subsequent sections on security and fraud prevention.
</p>
</section> <!-- closes security and fraud, h3 -->
<!--
<section>
<h3>Security</h3>
<p>
A <a>third party</a> MAY <a>collect</a>, <a>retain</a>, and <a>use</a> data about a particular user or user agent for the purpose of ensuring its security, provided that there are reasonable grounds to believe the user or user agent was attempting to breach the party's security at the time the data was collected.
<section class="informative">
<h4>Non-Normative Discussion</h4>
<p>
This exception grants <a>third parties</a> (e.g. advertising networks) some latitude to mitigate security risks. Websites that users store sensitive personal information on (e.g. financial services and webmail) are all first party; they are able to <a>collect</a>, <a>retain</a>, and <a>use</a> information about all users for security purposes.
</p>
</section> <!-- closes non-norm security, h4 -->
<!-- </section> <!-- closes security, h3 -->
<!--
<section>
<h3>Fraud Prevention</h3>
<p>
A <a>third party</a> MAY <a>collect</a>, <a>retain</a>, and <a>use</a> data about a particular user or user agent for the purpose of preventing fraud, provided that there are reasonable grounds to believe the user or user agent was attempting to commit fraud at the time the data was collected.
</p>
<section class="informative">
<h4>Non-Normative Discussion</h4>
<p>
When a user meaningfully interacts with third party content (e.g. clicking an ad), the <a>third party</a> can <a>collect</a>, <a>retain</a>, and <a>use</a> for fraud prevention. Third parties can also <a>use</a> <a>protocol information</a> for fraud prevention. This exception provides an additional capability to, in certain circumstances, track impressions for fraud prevention.
</p>
</section> <!-- closes non-norm fraud, h4 -->
<!--
</section> <!-- closes fraud prevention, h3 -->
</body>
Received on Tuesday, 19 June 2012 09:31:17 UTC