- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 20 Sep 2013 17:20:11 -0600
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
These comments are based on http://www.w3.org/TR/2013/WD-tracking-compliance-20130912/ > 2.1 User > > A user is an individual human. When user agent software accesses online > resources, whether or not the user understands or has specific knowledge > of a particular request, that request is "made by the user." The second sentence belongs at the end of the next section (User Agent), not here. > 2.3 Network Transaction > > A network interaction is the set of HTTP requests and responses, or any > other sequence of logically related network traffic caused by a user visit > to a single web page or similar single action. Page re-loads, navigation, > and refreshing of content cause a new network interaction to commence. Section header does not match the defined term. The defined term does not make any sense (a network interaction is any message). The second sentence needs to be prefixed with "For example, ..."; and "Page re-load" is a subset of "refreshing of content". If we want to make requirements on any network interaction, then we should make them on any sent message, or use "network interaction" exclusively for single request/response pairs. If we want to make requirements on a set of network interactions that result from a single user action, then we should come up with a term for that (i.e., "user action"). If we want to differentiate between a browser's initial resource request (initiated by user action) and the sequence of automated redirects and embedded subrequests that follow as a direct result of how the browser is instructed or configured to process the results of those interactions, then we should come up with specific terms for each of those things. Note that those interactions are often caused by configuration outside the referring site's control, such as how the browser is implemented, what plug-ins have been installed, what proxies are defined, what accessibility options have been enabled, and so on; so, we might need to differentiate between subrequests caused by the user (i.e., "configured requests") and subrequests caused by content received as the result of an interaction that instructs the user agent (i.e., "embedded requests"). *phew* > 2.4 Party > > 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 > document, those entities MUST be commonly owned and commonly controlled > and MUST provide easy discoverability of affiliate organizations. A list > of affiliates MUST be available through a single user interaction from > each page, for example, by following a single link, or through a single > click. Replace with: A party is either a person or a set of legal entities that share a common owner, controller, and public identity that is easily discoverable by a user. The type of organization is irrelevant unless we intend to exclude some types. This is a definition -- there is no need to qualify. There is no page here. Requirements belong in later sections, where they can be associated with specific situations (like the website, where pages exist). > 2.5 Service Provider > > An outsourced service provider is considered to be the same party as its > client if the service provider: > > 1. acts only as a data processor on behalf of the client; > 2. ensures that the data can only be accessed and used as directed by > that client; > 3. has no independent right to use or share the data except as necessary > to ensure the integrity, security, and correct operation of the > service being provided; and > 4. has a contract in place that outlines and mandates these requirements. This does not reflect the state of many long discussions we had about the service provider definition. There is an existing change proposal at http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Service_Provider which is more substantive, but we should first FIX the poor phrasing that nobody in the working group supports. Namely, the above definition can be immediately replaced with: ===== For the data received in a given network interaction, a party is considered to be a Service Provider if it: 1. processes the data on behalf of another party; 2. ensures that the data is only retained, accessed, and used as directed by said party; 3. has no independent right to use the data except as necessary to ensure the integrity, security, and correct operation of a service being provided by, or on behalf of, said party; 4. has a written contract with said party that is consistent with the above limitations. ===== > 2.6 First Party > > In the context of a specific network interaction, the first party is the > party with which the user intentionally interacts. In most cases on a > traditional web browser, the first party will be the party that owns and > operates the domain visible in the address bar. The second sentence is incorrect and should be deleted. First, the address bar isn't relevant until a page is rendered, which may be several requests after the initial request caused by a user interaction. The first party needs to be known to the user before they do their action; otherwise, they can't possibly have an intention. Second, a first party is *a* party that the user believes it will be interacting with as a result of making an action, and thus has more to do with the content that evoked the desire to make a given action rather than the end-result of that action. If the user is presented with a logo for Tennessee Fried Bunnies overlaid with a hypertext link, the user's intention when selecting that link will be to get more information about TFB. They might, as a result of that intention, be aware that the link is to search.example.com, which is presenting the link in a page of search results, and that selecting the link will make a first party request to search.example.com that results in a redirect pointing to a resource owned by TFB, to which the user agent will make another first party request to a domain unknown to the user that they will later find out (via the address bar) to be "http://www.tennessee-fried-bunnies.com/order/". In other words, there will often be multiple first parties for a single user action. Third. "owns and operates" assumes that the first party is operating its own service, which isn't true in general unless we include the first party's service providers inside the definition of first party. Since this spec does not do so, it cannot say that the first party is operating anything. > The party that owns and operates or has control over a branded or labeled > embedded widget, search box, or similar service with which a user > intentionally interacts is also considered a first party. If a user merely > mouses over, closes, or mutes such content, that is not sufficient > interaction to render the party a first party. I don't know what this first sentence is trying to say that isn't already said in the first paragraph above it. Branded to whom? Labeled how? Delete the first sentence and replace the second with Merely mousing over, muting, or closing a given piece of content does not constitute an intended interaction. > In most network interactions, there will be only one first party with > which the user intends to interact. ... No, usually there are two (the current page owner and the destination of the action). > 2.7 Third Party > > A third party is any party other than a first party, service provider, or > the user. This is stated as if these are existence classifications (person, cat, horse) rather than roles with regard to data collected as a result of a specific network interaction. In other words, what it should say is: For any data collected as a result of one or more network interactions between a given user and a first party, a Third Party is any party other than that user, that first party, or a service provider acting on behalf of that user or that first party. [skipping ahead because I have no time left before my flight] > 2.9 Tracking > > Tracking is the retention or use, after a network interaction is complete, > of data records that are, or can be, associated with a specific user, user > agent, or device. As mentioned in the last call for objections, my response to the last chairs' decision, and almost every teleconference since this change was introduced in the June draft, the above definition is overly broad and does not match any of our discussions during or since the initial TPWG meeting in Cambridge. More importantly, it is inconsistent with the rest of this specification's requirements in response to the user's expressed desire of Do Not Track. I see no point in continuing this working group if we cannot immediately address ISSUE-5. However, since that is not a short-term discussion, I propose that the definition present in the prior WD be restored. IOW: "Tracking" is understood by this standard as the collection and retention of data across multiple parties' domains or services in a form such that it can be attributed to a specific user, user agent, or device. and that this definition rightly belongs in Section 1 (the Introduction, which is currently, incorrectly, and confusingly labeled Scope). Cheers, Roy T. Fielding <http://roy.gbiv.com/> Senior Principal Scientist, Adobe <https://www.adobe.com/>
Received on Friday, 20 September 2013 23:20:37 UTC