- From: CVS User rfieldin <cvsmail@w3.org>
- Date: Wed, 15 Jan 2014 03:25:41 +0000
- To: public-tracking-commit@w3.org
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv19560
Modified Files:
tracking-dnt.html
Log Message:
Add definitions from recent decisions on ISSUE-5, ISSUE-10, and ISSUE-16.
This is a first pass on including the definitions, since they are not yet
consistenly used in the rest of the text.
Add issue boxes for 141, 217, 228, 240, 241, 242.
Update all issue boxes to reflect current tracker status.
Remove issues that have been closed
112, 137, 152, 161, 164, 167, 168, 176, 194, 195
and remove corresponding option classes (blue boxes).
Remove compliance issues that have not been associated with TPE.
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2014/01/15 01:49:23 1.232
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2014/01/15 03:25:41 1.233
@@ -70,7 +70,7 @@
<section id='sotd'>
<p>
- This document is an editors' strawman reflecting a snapshot of live
+ This document is an editors' straw man reflecting a snapshot of live
discussions within the
<a href="http://www.w3.org/2011/tracking-protection/">Tracking
Protection Working Group</a>. It does not yet capture all of our work
@@ -89,9 +89,6 @@
<a href="http://www.w3.org/2011/tracking-protection/track/issues/postponed">postponed</a>
issues regarding this document.
</p>
- <p class="issue" data-number="136" title="Resolve dependencies of the TPE on the compliance specification">
- [OPEN] This draft removes all dependencies on TCS.
- </p>
</section>
<section>
@@ -180,6 +177,12 @@
<em title="optional" class="rfc2119">optional</em> in this
specification are to be interpreted as described in [[!RFC2119]].
</p>
+ <p class="issue" data-number="136" title="Resolve dependencies of the TPE on the compliance specification">
+ <b>[OPEN]</b> This draft removes all dependencies on TCS.
+ </p>
+ <p class="issue" data-number="141" title="Do a review according to qaframe-spec">
+ <b>[POSTPONED]</b>
+ </p>
</section>
<section id='notation'>
@@ -194,26 +197,93 @@
<section id='terminology'>
<h4>Terminology</h4>
<p>
- This specification uses the term <dfn>user agent</dfn> to refer to
- any of the various client programs capable of initiating HTTP
- requests, including, but not limited to, browsers, spiders
- (web-based robots), command-line tools, native applications, and
- mobile apps [[!HTTP]].
- </p>
- <p>
- The term <dfn>user-granted exception</dfn> is used when the user has
- permitted tracking by a given third party.
- </p>
- <p class="issue" data-number="5" title="What is the definition of tracking?">
- [OPEN] Definition of tracking awaiting WG decision following call for objections.
- </p>
- <p class="issue" data-number="10" title="What is a first party?">
- [OPEN] Definitions for party, first party, and third party are
- awaiting WG decision following call for objections.
- </p>
- <p class="issue" data-number="16" title="What does it mean to collect, retain, use and share data?">
- [OPEN] Definitions for collect, retain, use, and share are
- awaiting WG decision following call for objections.
+ A <dfn>user</dfn> is a natural person who is making, or has made,
+ use of the Web. A <dfn>user action</dfn> is a deliberate act by the
+ user to invoke, command, or manipulate a user agent to perform a
+ network interaction, including the intended consequences of that
+ action. <dfn>User activity</dfn> is any set of such user actions.
+ </p>
+ <p>
+ A <dfn>user agent</dfn> is any of the various client programs
+ capable of initiating HTTP requests [[!HTTP]], including (but not
+ limited to) browsers, spiders (web-based robots), command-line
+ tools, custom applications, and mobile apps.
+ </p>
+ <p>
+ <dfn>Tracking</dfn> is the collection of data regarding a particular
+ user's activity across multiple distinct contexts and the retention,
+ use, or sharing of data derived from that activity outside the
+ context in which it occurred.
+ </p>
+ <p class="issue" data-number="240" title="Do we need to define context?">
+ <b>[RAISED]</b>
+ The above definition depends on there being a definition of
+ context that bounds a scope of user activity, though it is not
+ dependent on any particular definition of that term. For example,
+ something along the lines of: <em>For the purpose of this
+ definition, a context is a set of resources that share the same data
+ controller, same privacy policy, and a common branding, such that a
+ user would expect that data collected by one of those resources is
+ available to all other resources within the same context.</em>
+ </p>
+ <p>
+ A <dfn>party</dfn> is a natural person, a legal entity, or a set of
+ legal entities that share common owner(s), common controller(s), and
+ a group identity that is easily discoverable by a user. Common
+ branding or providing a list of affiliates that is available via a
+ link from a resource where a party describes DNT practices are
+ examples of ways to provide this discoverability.
+ </p>
+ <p>
+ Within the context of a given user action, a <dfn>first party</dfn>
+ is a party with which the user intends to interact, via one or more
+ network interactions, as a result of making that action. Merely
+ hovering over, muting, pausing, or closing a given piece of content
+ does not constitute a user's intent to interact with another party.
+ </p>
+ <p>
+ In some cases, a resource on the Web will be jointly controlled by
+ two or more distinct parties. Each of those parties is considered a
+ first party if a user would reasonably expect to communicate with
+ all of them when accessing that resource. For example, prominent
+ co-branding on the resource might lead a user to expect that
+ multiple parties are responsible for the content or functionality.
+ </p>
+ <p>
+ For any data collected as a result of one or more network
+ interactions resulting from a user's action,
+ a <dfn>third party</dfn> is any party other than that user, a first
+ party for that user action, or a service provider acting on behalf
+ of either that user or that first party.
+ </p>
+ <p>
+ A party <dfn>collects</dfn> data received in a network interaction
+ if that data remains within the party’s control after the network
+ interaction is complete.
+ </p>
+ <p>
+ A party <dfn>uses</dfn> data if the party processes the data for any
+ purpose other than storage or merely forwarding it to another party.
+ </p>
+ <p>
+ A party <dfn>shares</dfn> data if it transfers or provides a copy of
+ that data to any other party.
+ </p>
+ <p>
+ A party <dfn>facilitates</dfn> any other party’s collection of data
+ if it enables such party to collect data and engage in tracking.
+ </p>
+ <p>
+ A <dfn>user-granted exception</dfn> is a specific tracking
+ preference, overriding a user's general tracking preference, that
+ has been obtained and recorded using the mechanisms defined in
+ <a href="#exceptions" class="sectionRef"></a>.
+ </p>
+ <p class="issue" data-number="217" title="Terminology for user action, interaction, and network interaction">
+ <b>[OPEN]</b> Waiting on result from call for objections.
+ </p>
+ <p class="issue" data-number="228" title="Revise the Network Interaction definition">
+ <b>[OPEN]</b> Waiting on result from call for objections.
</p>
</section>
</section>
@@ -300,9 +370,6 @@
Implementations of HTTP that are not under control of the user
MUST NOT generate or modify a tracking preference.
</p>
- <p class="issue" data-number="194" title="How should we ensure consent of users for DNT inputs?">
- <b>[OPEN]</b>
- </p>
</section>
<section id='expressing'>
@@ -438,8 +505,9 @@
request [[!HTTP]].
</p>
- <p class="issue" data-number="176" title="Requirements on intermediaries/isps and header insertion that might affect tracking">[OPEN]</p>
- <p class="issue" data-number="153" title="What are the implications on software that changes requests but does not necessarily initiate them?">[PENDING REVIEW]</p>
+ <p class="issue" data-number="153" title="What are the implications on software that changes requests but does not necessarily initiate them?">
+ [PENDING REVIEW]
+ </p>
</section>
<section id='js-dom'>
@@ -560,27 +628,17 @@
/ %x44 ; "D" - disregarding DNT
/ %x55 ; "U" - updated
</pre>
-
- <p class="note">
- [Editorial: The previous values of "1" and "3" to indicate the designated
+ <p class="issue" data-number="241" title="Distinguish elements for site-internal use and elements that can be re-used by others (1/3)">
+ <b>[OPEN]</b>
+ The previous values of "1" and "3" to indicate the designated
resource complies with first or third party requirements,
respectively, have been removed because they are dependent on a
specific compliance regime. They can still be communicated via the
- qualifiers.]
- </p>
- <p class="issue" data-number="137" title="Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s)">
- <b>[PENDING REVIEW]</b> No, in practice there may be dozens of
- service providers on any given request. If the designated resource
- is operated by a service provider acting as a first party, then
- the responsible first party is identified by the
- <code><a>controller</a></code> property or the owner of the origin
- server domain. This satisfies the use case of distinguishing
- between a service provider acting for some other site and the same
- service provider acting on one of its own sites.
+ qualifiers.
</p>
</section>
- <section id='TSV-!' class="option">
+ <section id='TSV-!'>
<h4>Under Construction (!)</h4>
<p>
A tracking status value of <dfn>!</dfn> means that the origin
@@ -593,10 +651,6 @@
ignored, nor that tracking will occur as a result of accessing the
designated resource.
</p>
- <p class="issue" data-number="161" title="Do we need a tracking status value for partial compliance or rejecting DNT?">
- <b>[PENDING REVIEW]</b> The <code><a>!</a></code> tracking status
- value indicates that tracking status is under construction.
- </p>
</section>
<section id='TSV-?'>
@@ -620,7 +674,7 @@
</p>
</section>
- <section id='TSV-N' class="option">
+ <section id='TSV-N'>
<h4>Not Tracking (N)</h4>
<p>
A tracking status value of <dfn>N</dfn> means the origin server
@@ -628,10 +682,6 @@
not used for tracking and will not be combined with other data in
a form that would enable tracking.
</p>
- <p class="issue" data-number="119" title='Specify "absolutely not tracking"'>
- <b>[OPEN]</b> The <code><a>N</a></code> tracking status
- value replaces the notion of absolutely not tracking.
- </p>
</section>
<section id='TSV-1'>
@@ -660,12 +710,9 @@
its corresponding tracking status representation
(<a href="#status-representation" class="sectionRef"></a>).
</p>
- <p class="issue" data-number="152" title="User Agent Compliance: feedback for out-of-band consent">
- <b>[PENDING REVIEW]</b> Proposal is to not add UA requirements.
- </p>
</section>
- <section id='TSV-P' class="option">
+ <section id='TSV-P'>
<h4>Potential Consent (P)</h4>
<p>
A tracking status value of <dfn>P</dfn> means that the origin
@@ -694,16 +741,9 @@
personalization. If consent can be determined at the time of a
request, the <code><a>C</a></code> tracking status is preferred.
</p>
- <p class="issue" data-number="195" title="Flows and signals for handling out of band consent">
- <b>[OPEN]</b><br />
- The <code><a>P</a></code> tracking
- status value indicates a special case of general data collection
- which is then trimmed to exclude those without out of band
- consent.
- </p>
</section>
- <section id='TSV-D' class="option">
+ <section id='TSV-D'>
<h4>Disregarding (D)</h4>
<p>
A tracking status value of <dfn>D</dfn> means that the origin
@@ -730,10 +770,6 @@
are inconsistent with their other published and unexpired claims
regarding tracking is likely to be considered misleading.
</p>
- <p class="issue" data-number="161" title="Do we need a tracking status value for partial compliance or rejecting DNT?">
- <b>[PENDING REVIEW]</b> The <code><a>D</a></code> tracking status
- value indicates rejection.
- </p>
</section>
<section id='TSV-U'>
@@ -1072,7 +1108,7 @@
</pre>
</section>
- <section id='rep.tracking' class="option">
+ <section id='rep.compliance' class="option">
<h4>Compliance Property</h4>
<p>
An origin server MAY send a property named
@@ -1089,7 +1125,10 @@
<dfn>compliance-v</dfn> = array-of-refs
</pre>
<p class="issue" data-number="239" title="Should tracking status representation include an array of links for claiming compliance by reference?">
- [RAISED] Text above is proposed resolution.
+ <b>[RAISED]</b> Text above is proposed resolution.
+ </p>
+ <p class="issue" data-number="242" title="URL Management for compliance regime URLs">
+ <b>[POSTPONED]</b>
</p>
</section>
@@ -1180,18 +1219,6 @@
<dfn>same-party</dfn> = %x22 "same-party" %x22
<dfn>same-party-v</dfn> = array-of-refs
</pre>
- <p class="issue" data-number="164" title="To what extent should the same-party attribute of tracking status resource be required?">
- [OPEN] 3 Alternatives - text is needed:<br/>
- (A) Current draft: Resource is optional<br/>
- (B) Alternative proposal 1: If multiple domains on a page belong
- to the same party, then this fact SHOULD be declared using the
- same-party attribute<br/>
- (C) Alternative proposal 2: State that
- user agents MAY assume that additional elements that are hosted
- under a different URL and occur on a page and declare "intended
- for 1st party use" are malicious unless this URL is listed in the
- "same-party" attribute
- </p>
</section>
<section id='rep.audit'>
@@ -1462,10 +1489,6 @@
a call to record an exception reflects the user's informed consent at the
time of the call.
</p>
-
- <p class="issue" data-number="194" title="How should we ensure consent of users for DNT inputs?">
- <b>[OPEN]</b> We agree that exceptions should reflect user consent and that this needs to be ensured before a site is permitted to register an exception. There is concern that the language above is insufficient to guarantee this desire. Potential language that is acceptable by the whole group is still under discussion.
- </p>
<p>
Sites MAY ask for an exception, and have it stored, even when the user's
general preference is not <a>enabled</a>.
@@ -1544,12 +1567,6 @@
<code>widgets.exsocial.org</code> are both
<strong>targets</strong>.
</p>
- <p class="issue" data-number="112" title="How are sub-domains
- handled for site-specific exceptions?">
- <b>[PENDING REVIEW]</b> In the current proposal a
- <code>domain</code> parameter allows exceptions to apply to
- sub-domains in the same way as cookies.
- </p>
<p>
The domains that enter into the behavior of the APIs include:
</p>
@@ -1659,10 +1676,6 @@
'no' to all exception requests, and a UA that does not implement the
calls.
</p>
-
- <p class="issue" data-number="167" title="Multiple site exceptions">
- [PENDING REVIEW] The current assumption is that the best practice is
- to use frames.</p>
</section>
</section>
@@ -2041,11 +2054,6 @@
limitations found in the legal system the content provider or the named
third party are operating in.</p>
- <p class="issue" data-number="168" title="What is the correct way for
- sub-services to signal that they are taking advantage of a
- transferred exception?">
- [PENDING REVIEW] When the status values and qualifiers are fixed, the
- penultimate paragraph may need adjusting to match.</p>
</section>
<section id="exceptions-ui" class="informative">
Received on Wednesday, 15 January 2014 03:25:42 UTC