W3C

Site Navigation

Nearby

Results of Questionnaire [Call for Objections] Tracking definition

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: team-tracking-chairs@w3.org

This questionnaire was open from 2013-11-08 to 2013-11-20.

14 answers have been received.

Jump to results for question:

  1. Objections to Option A: Tracking across multiple distinct contexts
  2. Objections to Option B: Retention/use associated with user, user agent, device
  3. Objections to Option C: No Definition/Definition Location

1. Objections to Option A: Tracking across multiple distinct contexts

Option A: Tracking across multiple distinct contexts

Tracking 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.

The above definition depends on collection, retention, use, and sharing being defined along the lines of the editors' draft or as clarified by Vinay's proposals.

The above definition also 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: 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.

The above definition also assumes that an explanation of permitted tracking will occur as well, presumably in the introduction along with the definition of tracking, so that a reader won't be misled about the user's expressed preference being the same as compliance. For example, something along the lines of: Some servers might perform tracking regardless of the user's expressed preference; for example, a service might have obtained prior consent that allows them to track the user, or a service might limit its tracking to specific purposes that are allowed under a given compliance regime (see Section XX).


If you have an objection to this option, please describe your objection, with clear and specific reasoning.

Details

Responder Objections to Option A: Tracking across multiple distinct contexts
Chris Mejia I object to Option A:

I strongly object to the porting of ANY definition into the TPE. I believe that ALL definitions should be found in the compliance specification of the compliance regime for which a server claims compliance—such compliance regimes may include one created by W3C, or some other qualified organization. This TPE should focus ONLY on the technical protocols, and should not rely on any broad or narrow definition of terms.

With respect to the TPE’s context (on it’s own), I counter the argument that the user needs to know what her preference is when she turns on the DNT signal. My opinion is that the user need only know that she has stated a preference to “send” a DNT signal. That’s all the TPE should be about—no further context required.

I believe that how the server handles a preference statement from the user should be dependent on the compliance regime honored by the called server, and this should be messaged accordingly to the user.

I’m very concerned about the “slippery slope” situation that the porting of ANY definition into the tech spec creates. If these ported definitions were too broad, valuable context could be lost. If these ported definitions were too narrow, technical and policy compliance may be jeopardized (i.e. some organizations may not be able to live with the resultant technical spec and may choose then not to honor DNT at all).

Bringing overly broad or unclear definition of Tracking into the TPE does nothing to help the user understand his or her DNT choice. The user’s choice is simple: to send or not send a DNT signal.

After all, I cannot conceive of how the TPE would ever, practically speaking, stand alone in the marketplace. Naturally, I think this TPE would be married with SOME compliance policy/spec, and the definition of terms found in the TPE would be made clear in that policy/spec. That policy/spec should be openly reference-able by any user, and that document, with its definitions, should help the user understand their choice to send a DNT signal.

So to be clear, I OBJECT STRONGLY (I can’t live with) BOTH Option A and Option B, and am in strong support of Option C in this poll.
Rob van Eijk I bbject to this definition. Do Not Track may well be a context negotiation mechanism, but that negotiation is done by the user. Defining the boundaries of context by anyting else but the user would seriously undermine the user centric nature of Do Not Track. Context is highly subjective from a user perspective and should therefore not be pinned down by boundaries like common branding or other assumption.
Brooks Dobbs I object to this for two distinct reasons:

1) This definition does not have meaning. It is really just a punt to another misunderstood and not agreed upon term, "context". The non-normative language actually confuses this matter further by saying that a definition is required - just not any particular definition. In reality the term "context" likely has very different meanings to different participants, meaning that the resultant definition of tracking will have an equally un-agreed upon meaning. In my opinion this definition moves us no further towards consensus.

2)Any definition of tracking in a TPE will necessarily be incomplete and therefore incorrect. If "tracking" is the activity that users will be able to effect a choice with respect to, but compliance with that choice is to be determined in another document (documents) there is a logical breakdown. If we define tracking in broad terms in a TPE and allow for a TPE compliant signal to be an expression of a choice for NOT "tracking" then any exceptions to that e.g. permitted uses, would seem to be outside of the choice a user made. While a definition is important, the definition must occur in a location to provide consistency between user expectation and compliance requirements.
Amy Colando Microsoft believes that defining Tracking will be helpful for implementers and other readers of the TPE specification. Because the proposals are dependent on other definitions, and are also dependent on other text currently in the Compliance specification, we believe that the editorial notes (in italics) that accompany the selected proposal should accompany the Tracking definition as non-normative text, particularly for option B. We support the inclusion of either option A or B to help define use and retention approaches for DNT, although we note that option A may be slightly easier for nontechnical readers to comprehend.
Mike O'Neill I object to Candidate A.

This definition restricts the locus of this specification to the collection of data “regarding a particular user’s activity across multiple distinct contexts”, which makes this core definition ambiguous and weakens the meaning conveyed by the Do Not Track signal.

A common understanding of tracking involves the collection of a database of any web activity without a user’s knowledge (and therefore without their consent) and to many it is irrelevant what “contexts” apply when this data is collected.

This definition would allow the collection, use etc. of data within any single context, not only by “location bar” visited sites but also by third-party content servers. A third-party server receiving a DNT:1 signal could continue to place or retain a unique user identifier and collect other data such as time of visit or geo-location details. Although there may be restrictions on associating this data with details about the explicitly visited first-party this could be by “administrative and operational controls” which would be impossible to verify automatically, leaving the user to simply rely on trust.

Restricting the definition of tracking in this way may also reduce the likelihood that this specification could fulfil the requirements for “browser settings” in Recital 66 of the European e-privacy directive or as an automated mechanism to impart a consent or “right to object” signal referred to by the forthcoming general data protection regulation. This could lessen the chance of getting legal backing for the standard in Europe.

If a user’s agreement to be tracked, irrespective of their general preference not to be, can be implied by the action of clicking on a link then it would be better to document that as a possible exemption, subject to local law, in the compliance document.
Alan Chapell I respectfully object to Option A

The inclusion of context into the definition of tracking is certainly interesting and worth discussing in the event that we ultimately work on a compliance specification. However, creating a definition of tracking is unnecessary to complete the technical specification document.
David Wainberg I strongly object to the inclusion of any definition of tracking in the TPE. It is unnecessary to defining the technical mechanism for transmitting a user's DNT preference. It's inclusion outside of a broader document that fully defines and describes the meaning of a DNT signal will be highly detrimental to the specification, because it would create considerable ambiguity and therefore risk for potential implementers.

However, because it seems likely the chairs will elect to include a definition of tracking in the TPE despite strong objections to doing so, I will also state the following objections to this particular definition:

1. While I support the focus on context, I object to the finalization and inclusion of a definition of tracking that relies on vague, undefined terms, such as context or sharing.

2. Additionally, I specifically object to the portion of this definition that applies to "data derived" from users' activity. This is over-broad in
that it could include data and data uses that should not reasonably fall within the definition of tracking, including, for example, aggregate data, or other data that is not tracking data.
David Singer This definition has many problems.
1) It needs a definition of 'context', as noted.
2) It's probably not comprehensible to users, whereas the purpose of the definition is to reflect the users' general desires. Users' general objection is to 'keeping records about them' and this is more complex and rather different from that.
3) It talks about the symptom (tying contexts together) rather than the activity or problem (collection and retention of personal data).
4) It would appear to permit a great deal of recording; ad servers could record everything they see about a user 'in their context', for example. Indeed, it appears only to restrict connecting those records 'outside the ad server context', e.g. to the sites on which the ads appeared. That's permitting a lot of tracking and retention. If that is not the intent of the definition, it's misleading.
5) It appears to be a formal definition, but it's at odds with what the current compliance draft actually restricts (there is nothing in there about multiple contexts, for example).
John Simpson I object to this definition. First, as presented, it is too contingent on other language that hasn't been clarified. Second, and more to the point, I don't think it is readily understandable by the average user: what exactly is across multiple distinct contexts? It also is too narrow and limiting.
Roy Fielding I support this definition.

The reason context is not defined as part of this definition is because the scope of what a user considers to be same-context is an orthogonal question. Hence, it can be debated and decided separately, or perhaps not even defined at all (left to the user to define according to what is evident from a site's user experience). The entire point of using context in this definition of tracking is to abstract away from what has clearly been a contentious issue.

Objecting to this definition because you don't like the explanatory notes is ludicrous -- they exist for the sole purpose of explaining what I was thinking when writing down the definition, so that the chairs would have a better idea of what might be considered "new information" if we later change those assumptions. They are not part of the definition itself.

Objecting to this definition because you don't like relying on undefined terms is nothing more than a delaying tactic to prevent further work on the standard. Every word in the specification is dependent on the specification's scope, and that scope is "Do Not Track". I don't think we need to define the first two words, but we do need to define the third. For two years now, the same people have been complaining about working on a definition of collection because they did not have an agreed upon definition of tracking. We have to start somewhere. If new information is discovered later, the W3C process allows this decision to be reconsidered by the group.
Brad Kulick First, I strongly object to moving any definitions into the TPE.

I object to this definition. While this is a core term that must be defined, doing so in the TPE, instead of a compliance specification, does not make the TPE a stronger document but rather limits its utility. Furthermore, leaving the term “context” under-defined does not provide enough clarity to avoid confusion of what tracking is. It leaves open for unacceptably different interpretations of what would be within scope of this definition. The nuance involved with getting this definition correct, should not be rushed simply due to pushing the TPE out first. I recommend moving this definition back to the compliance specification and clearly define context in less ambiguous terms.
Jack Hobaugh In general, I object to the porting of a TCS compliance definition into the TPE. I feel strongly that the TPE should remain a pure protocol and technical specification document. Some have contended that some TCS definitions are needed in the TPE in order for the user to understand the choice that the user is making regarding the DNT signal. This is simply not the case. A technical specification need only specify the requests and responses necessary for a DNT protocol to be implemented in a scalable and implementable solution across all browsers and the servers called. A technical specification should not inform the user regarding a policy or compliance choice but instead should inform the technical community on how to implement a technical solution. The compliance specification for the DNT signal should be left to the compliance regime, whether it is a national compliance regime, a W3C-based compliance regime or an industry-based compliance regime. Porting definitions from a particular compliance regime into the TPE only serves to provide an incomplete and confusing picture to those attempting to implement the technical protocol. Porting an overly broad or unclear definition of Tracking into the TPE does nothing to help the user understand his or her DNT choice. The user preference that should be supported within the scope of the TPE is fairly simple - to send or not send a DNT signal. Such a preference choice is easily supported by the TPE without importing definitions from the TCS.

Specifically, I object to this definition of tracking to the extent that it contains words and phrases that are yet to be fully explored and defined within the TPWG. For example, it is already admitted that “context” is an undefined term. Also, “Data Controller” and “multiple distinct contexts” are not defined. In the non-normative text offered with this proposal, there is a proposed definition for context. But this definition has not been vetted within the TPWG. This highlights the process issues with attempting to define a crucial compliance term without first defining or at the same time defining the necessary terms contained in the proposed definition.

If the co-chairs dismiss Option C, although I have serious objections against both Option A and Option B, I would prefer Option A over Option B.
Vinay Goel
Shane Wiley I believe moving forward with this definition will only create further confusion with how to fairly set expectations with users. Outside of the strong question of whether a definition is needed here in the context of a pure technical specification, this definition lacks certainty for implementers. Many elements, chiefly “context”, are unclear in this definition which will lead some to believe the scope is either broader or more narrow than expected.

2. Objections to Option B: Retention/use associated with user, user agent, device

Option B: Retention/use associated with user, user agent, device

In general terms, tracking is the retention or use after a network transaction is complete, or sharing, of data that is, or can be, associated with a specific user, user agent, or device.

Non-normative text

Tracking may result in the compilation of a database about a person and their online activity, perhaps without their knowledge. Harms from this might include direct ones, such as differential pricing or service provision, through to major ones, including the consequences of public revelation of the database, access to it by persons with criminal intent, or its use by government or other bodies.

Note that the extent to which tracking data may nonetheless be retained in the presence of this signal under some circumstances is defined in the companion specification.

Notes

The following non-normative text was previously here, but would be out of place in the TPE, and is premature for the Compliance document. So the above text is suited to the TPE, and we can settle on the non-normative text that reflects Compliance when we get there.

However, this recommendation assumes that by choosing to visit a site, users allow First Parties to retain and use tracking data they collect directly, or indirectly via Service Providers (though there are restrictions on sharing); and it allows Third Parties to claim permission to retain tracking data under some specific conditions (e.g. for security, auditing, or for deferred processing of raw data).


If you have an objection to this option, please describe your objection, with clear and specific reasoning.

Details

Responder Objections to Option B: Retention/use associated with user, user agent, device
Chris Mejia I object to Option B:

I strongly object to the porting of ANY definition into the TPE. I believe that ALL definitions should be found in the compliance specification of the compliance regime for which a server claims compliance—such compliance regimes may include one created by W3C, or some other qualified organization. This TPE should focus ONLY on the technical protocols, and should not rely on any broad or narrow definition of terms.

With respect to the TPE’s context (on it’s own), I counter the argument that the user needs to know what her preference is when she turns on the DNT signal. My opinion is that the user need only know that she has stated a preference to “send” a DNT signal. That’s all the TPE should be about—no further context required.

I believe that how the server handles a preference statement from the user should be dependent on the compliance regime honored by the called server, and this should be messaged accordingly to the user.

I’m very concerned about the “slippery slope” situation that the porting of ANY definition into the tech spec creates. If these ported definitions were too broad, valuable context could be lost. If these ported definitions were too narrow, technical and policy compliance may be jeopardized (i.e. some organizations may not be able to live with the resultant technical spec and may choose then not to honor DNT at all).

Bringing overly broad or unclear definition of Tracking into the TPE does nothing to help the user understand his or her DNT choice. The user’s choice is simple: to send or not send a DNT signal.

After all, I cannot conceive of how the TPE would ever, practically speaking, stand alone in the marketplace. Naturally, I think this TPE would be married with SOME compliance policy/spec, and the definition of terms found in the TPE would be made clear in that policy/spec. That policy/spec should be openly reference-able by any user, and that document, with its definitions, should help the user understand their choice to send a DNT signal.

So to be clear, I OBJECT STRONGLY (I can’t live with) BOTH Option A and Option B, and am in strong support of Option C in this poll.
Rob van Eijk
Brooks Dobbs Though I have only a singular objection to this definition, the objection is no less strong as to option A. The breadth of this definition, seemingly reliant on limitations in a companion document, illustrates the problem with locating a tracking definition in the TPE and highlights the potential for user choice to be based on misunderstanding. Its non-normative language further clouds the meaning by saying "the extent to which tracking data may be retained in the presence of this signal is defined in the companion specification". This appears to be saying tracking is X unless somewhere else we say it isn't, but we don't have that somewhere else done yet. While this may factually correct, one wonders how it is helpful with respect to a users expression of choice. Additionally suggesting that only an exception to *retention* would be defined in a companion document is misleading.
Amy Colando
Mike O'Neill I support Option B.

Alan Chapell I object to Option B

Creating a definition of tracking is NOT necessary to complete the technical specification document.
David Wainberg I strongly object to the inclusion of any definition of tracking in the TPE. It is unnecessary to defining the technical mechanism for transmitting a user's DNT preference. It's inclusion outside of a broader document that fully defines and describes the meaning of a DNT signal will be highly detrimental to the specification, because it would create considerable ambiguity and therefore risk for potential implementers.
David Singer No objection, but a minor comment: since this text was submitted, the TPE and compliance are to be further teased apart, and the non-normative text may need editing. "Note that the extent to which tracking data may nonetheless be retained in the presence of this signal under some circumstances is defined elsewhere." for example.

We also note that the formal definition of 'network transaction' is needed (an HTTP request and its matching response(s)), and that was noted when this definition was supplied but is not present in this CfO.
John Simpson I could probably live with this definition, but as explained below see absolutely no reason to define tracking in either the TPE or a Compliance document. I think the Working Group would be best served if we avoided trying to define Tracking. We've tried for 3 years to do so, it is unnecessary and a waste of time.
Roy Fielding I object to this definition because it includes any retention of personal data, including that by first party sites.

When a user says "do not track", they clearly do not intend that their bank forget who they are, that their social network account stop working, that their Flickr pictures be deleted, or that they be prevented from logging in.

The privacy concern we are addressing in *this* protocol is the personal data that might be learned by observing a user across multiple contexts (i.e., the ability to learn something new about, or build a profile on, the user by observing their activity at multiple contexts).

I am not being tracked if I am never seen in more than one location. I am being remembered, sure, but there is a good reason why we have a separate word for being tracked. Being tracked has significant negative implications because it is more significant to a user than simply being remembered.

If I walk into my favorite bar and everyone knows my name, I am not going to be creeped out; that's good customer service. If I get the same reaction from a place I've never been before, then I would find that creepy (even if it was with good intentions).

People deliberately use the Internet in ways that allow most first party site and app providers to retain personal data. That is what the user wants. DNT should not turn that off, and in fact none of the proposed compliance notions turn that off. It therefore isn't considered (by the user) to be tracking unless someone tries to combine observations from multiple contexts.

A site is not tracking you just because you logged in. It is authenticating you. There is a huge difference between authenticating that a user at one site has access to their own account at that site, and that same authentication data being used to follow the user's activity at other sites. The latter is clearly an issue with federated identity services, and if we don't define tracking correctly then we can't explain that issue.

I also object to this definition because data is often retained "after a network transaction is complete" just for the sake of communication, status monitoring, and caching. Most hardware routers would not be able to satisfy this definition because they retain IP addresses and/or session pointers in their routing tables until they are replaced by later connections. Apache HTTP Server's default status monitor won't satisfy this definition.

IP addresses get stuck at all layers. Any application that involves security has an audit trail. Every first party website has an access log.

To clarify why this definition grossly overreaches our mandate, we only need to look at a subset of what it includes:

tracking is the retention of data that can be associated with a specific user, user agent, or device

I claim that the above definition has no relation to our work.

There is nothing in the original DNT proposal that would suggest a user's expectations when setting DNT:1 would be that they could only perform anonymous activity on the Internet. In fact, the original proposal only sent DNT when making (what the author believed to be) a request to a third party --- an embedded request to some domain other than that of the primary page.

Let's compare that to how DNT implementations are described by the browsers and servers that implement them:

http://datatracker.ietf.org/doc/draft-mayer-do-not-track/

This document defines the syntax and semantics of Do Not Track,
an HTTP header-based mechanism that enables users to express
preferences about third-party web tracking.

http://www.mozilla.org/en-US/dnt/

Do Not Track is a feature in Firefox that allows you to let
a website know you would like to opt-out of third-party tracking
for purposes including behavioral advertising. It does this by
transmitting a Do Not Track HTTP header every time your data
is requested from the Web.

https://twitter.com/privacy

If you prefer, you can turn off tailored ads in Twitter account
settings so that your account is not matched to information
shared by ad partners for tailoring ads.

https://en.help.pinterest.com/entries/25010303

If you don’t want Pinterest using stuff you do off Pinterest
to personalize your experience, here are some things you can do:

Note that the last two are account-based services that retain extensive personal data about each account holder, and yet privacy folks were quite vocal in their approval of the fact that these sites honor DNT.

Furthermore, I object to any prefix like "In general terms,": the whole point of this exercise is to be specific.

Finally, I think the definition is unreadable as phrased given the ambiguous use of commas. It would be clearer as a bulleted list of sentences, which would make it even more obvious that it doesn't define what DNT is intended to turn off.
Brad Kulick First, I strongly object to moving any definitions into the TPE.

Furthermore, I strongly object to this particular definition. While all definitions will work in conjunction with other text, using such a broad description on THE main definition, which is does not accurately capture the most prevalent limitations, only serves to add confusion to its application to user preference. To make this definition usable, it needs to convey more accurately the scope of tracking.
Jack Hobaugh In general, I object to the porting of a TCS compliance definition into the TPE. I feel strongly that the TPE should remain a pure protocol and technical specification document. Some have contended that some TCS definitions are needed in the TPE in order for the user to understand the choice that the user is making regarding the DNT signal. This is simply not the case. A technical specification need only specify the requests and responses necessary for a DNT protocol to be implemented in a scalable and implementable solution across all browsers and the servers called. A technical specification should not inform the user regarding a policy or compliance choice but instead should inform the technical community on how to implement a technical solution. The compliance specification for the DNT signal should be left to the compliance regime, whether it is a national compliance regime, a W3C-based compliance regime or an industry-based compliance regime. Porting definitions from a particular compliance regime into the TPE only serves to provide an incomplete and confusing picture to those attempting to implement the technical protocol. Porting an overly broad or unclear definition of Tracking into the TPE does nothing to help the user understand his or her DNT choice. The user preference that should be supported within the scope of the TPE is fairly simple - to send or not send a DNT signal. Such a preference choice is easily supported by the TPE without importing definitions from the TCS.

Specifically, I object to this definition of tracking to the extent that it contains words and phrases that are yet to be fully explored and defined within the TPWG. For example, the definition of “shared” has yet to reach consensus within the TPWG. Also the definition of “network transaction” has not reached consensus within the TPWG. This highlights the process issues with attempting to define a crucial compliance term without first defining the necessary terms contained in the proposed definition. I also object to non-normative text that is admittedly out of place for the TPE and premature for the Compliance document being referenced here with this definition. Such a reference prejudices the entire process. If it is premature, then it should be removed. As it stands now it provides an unfair and prejudicial view of the Internet that could have a negative effect on the economic balance of the Internet without providing substantial privacy gains to users.
Vinay Goel I object to this proposed definition of tracking. This definition completely ignores the intent of the working group to place limits on data collection and use by a company across unaffiliated websites. This proposed definition does not speak at all about how tracking is the collection and use of data across unaffiliated websites. If browsers were to use / display this definition within its user interface, it would completely mislead the user as to what the signal is intended to tell company's about the user's privacy preference. I believe including this definition within the TPE (or any W3C Tracking Protection standard) would significantly reduce the number of companies that implement the standard.
Shane Wiley As David and I have discussed on the public email list, this definition provides for far too broad of a view of “tracking” including any and all events online. This sets up a dangerous outcome in that readers of the standard will be misled to believing this is the intended scope of DNT - missing vitally important and foundational concepts up-front. While it is unnecessary to move forward with a definition of tracking in purely technical specification where that definition could be referenced elsewhere, this approach misses to accurately capture the nuance of multi-site activity and permitted uses.

3. Objections to Option C: No Definition/Definition Location

Option C: No Definition/Definition Location

No definition; remove from Definitions section, rest of document unchanged.


If you have an objection to including the definition of tracking in either the TPE document or the Compliance document, please describe your objection, with clear and specific reasoning

Details

Responder Objections to Option C: No Definition/Definition Location
Chris Mejia I strongly SUPPORT OPTION C: of the limited options given in this poll, this is the only option I CAN live with.

As stated above, with respect to the TPE’s context (on it’s own), I counter the argument that the user needs to know what her preference is when she turns on the DNT signal. From a purely technical perspective, I believe that the user need only know that she has stated a preference to “send” a DNT signal. That’s all the TPE should be about—no further context required in a pure tech protocol on how a HTTP header is sent by browsers and received by servers.

I believe that how the receiving server handles a preference statement from the user should be dependent on the compliance regime honored by the called server, and this should be messaged accordingly to the user, so the user understands the choice she is making, or has made.

I cannot conceive of how the TPE would ever, practically speaking, stand alone in the marketplace. Naturally, I think this TPE would be married with SOME compliance policy/spec, and the definition of terms found in the TPE would be made clear in that policy/spec. That policy/spec should be openly reference-able by any user, and that document, with its definitions, should help the user understand their choice to send a DNT signal.
Rob van Eijk
Brooks Dobbs While I have long supported a definition of tracking, that definition should not be created in a location which is likely to mislead a consumer by not correctly and fully defining the thing to which they are accepting or objecting to. The correct location for this definition is in a compliance document or documents.
Amy Colando Microsoft believes that defining Tracking will be helpful for implementers and other readers of the TPE specification.
Mike O'Neill I object to Option C.

This is an essential definition because it is fundamental to the whole standard. There needs to be a definition in general terms of tracking, though we can leave it to the TCS to detail how servers should respond to a DNT signal.
Alan Chapell I support Option C

This working group voted, and the preference of the working group was to work on the TPE document. W3C staff and chairs are attempting to create a de facto Compliance document by importing key compliance-specific terms into the TPE.

Moreover, the definition for tracking is dependent on other definitions (e.g., collection, retention, use, sharing, and context). As a result, its difficult to assess their impact on the DNT standard in isolation. There is a significant possibility that multiple working group members will look to reopen this issue depending upon how the myriad of dependencies are defined.

Our time is best utilized by working on the TPE through to completion without the distraction of a dispute over the tracking definition.

David Wainberg I support this option.
David Singer No strong objection, but a note that there are three viable options:
a) a formal definition (option A is written this way) that is then used later.
b) an informal definition, which sets the stage, but is then not used (option B is used this way).
c) no definition, but some other explanation of what is restricted by this protocol.

Option C fails to set the stage, and describe even in rough terms what is being expressed by the 'T' in DNT.
John Simpson There is no reason to define tracking in either document. We need to do two things: 1.) Spell out how technically to send a DNT signal and 2.) Spell out the compliance obligations when a DNT message is received.

Consider this analogy. My daughter asks for the keys to the family car. I tell her, "OK. Don't speed." She responds, "Define speeding." I say, "Nonsense, just follow the Motor Vehicle Code [ie, a compliance document]. It's easy to do, the highlights are posted along the highway in different places [use cases]."

Consider the Working Group's task. We all agree the user sends a DNT message. Some advocate bogging us down in defining "tracking." It's totally unnecessary. Our answer should be spelled out in a Compliance document: If you receive a DNT message this is what you MUST, SHOULD and MAY do...
Roy Fielding I object to this option of no definition.

We need a definition of tracking because the protocol is supposed to be expressing a user preference, and the only thing the user is being informed about is:

Firefox 24.0:

"Tell sites that I do not want to be tracked"
+ plus a link to a web page that says
"Mozilla Firefox offers a Do Not Track feature that lets you
express a preference not to be tracked by websites. When the
feature is enabled, Firefox will tell advertising networks and
other websites and applications that you want to opt-out of
tracking for purposes like behavioral advertising."

Safari iOS:

"Do not track" (with a link to a Safari and Privacy document that says:
"Some websites keep track of your browser activities when they serve
you content, which enables them to tailor what they present to you.")

Safari OS X 6.0.5

"Website tracking: [ ] Ask websites not to track me"

Chrome 30.0.1599.69:

"Send a 'Do Not Track' request with your browsing traffic"
[with a pop up that basically says it isn't defined]

Internet Explorer (reported):

"Always send Do Not Track header"

Hence, the user needs a definition of tracking (or "to track") in order to have an informed preference, and sites need to know what that definition is in order to understand the meaning being expressed by the user and to ensure that their own behavior is consistent with how they have informed users in the exception dialogs and privacy policies.

The essence of standards is to ensure that all parties share the same vocabulary when communicating. Consistency in user expression depends on a common definition and consistency in its implementation by browsers. The way to get that consistency is to include a definition in the protocol document that all user agent implementers need to read to properly implement the protocol, so that user agents will (in turn) describe it consistently to users when offering the configuration option.

What a server believes, or intends to comply with, is not relevant to the user's preference. It is only relevant to the server's compliance with that preference. Even if the server believes tracking might mean something else, the definition is still required to communicate what the user requests.

If neither the user nor the server can state what they want, then there is no point in having a protocol at all. We might as well be talking gibberish.
Brad Kulick I strongly support option C.

The definition of tracking is not required for the TPE. The major browser vendors already send DNT signals -- proof that it is not needed in the technical specification. Given the interdependencies between the definitions, I see pushing a few core ones into the TPE quickly and then handling the others separately as hurting privacy since they are related. Definitions should be returned to the compliance document and the TPE should be completed and moved forward.
Jack Hobaugh I strongly SUPPORT Option C.
Vinay Goel
Shane Wiley No definition is necessary for the TPE. The TPE fully functions in an accurate and expected manner by allowing Servers to offer up their compliance program (and the definition of tracking within them) in a well-known URI and/or in pointers provided in Server responses. UAs can provide these to users in real-time. Attempting to define Tracking in the TPE creates the real and highly probable outcome that a conflict in definitions will occur between the W3C and self-regulatory efforts - and - with local laws where definitions may be argued to already exist. A better location for the definition of Tracking in the W3C process is within the Compliance and Scope document where is was prior to the Poll to move forward on Option 3.

More details on responses

  • Chris Mejia: last responded on 20, November 2013 at 19:13 (UTC)
  • Rob van Eijk: last responded on 20, November 2013 at 21:39 (UTC)
  • Brooks Dobbs: last responded on 20, November 2013 at 22:16 (UTC)
  • Amy Colando: last responded on 20, November 2013 at 22:28 (UTC)
  • Mike O'Neill: last responded on 20, November 2013 at 22:49 (UTC)
  • Alan Chapell: last responded on 20, November 2013 at 23:26 (UTC)
  • David Wainberg: last responded on 20, November 2013 at 23:45 (UTC)
  • David Singer: last responded on 20, November 2013 at 23:59 (UTC)
  • John Simpson: last responded on 21, November 2013 at 00:49 (UTC)
  • Roy Fielding: last responded on 21, November 2013 at 02:10 (UTC)
  • Brad Kulick: last responded on 21, November 2013 at 02:41 (UTC)
  • Jack Hobaugh: last responded on 21, November 2013 at 03:37 (UTC)
  • Vinay Goel: last responded on 21, November 2013 at 03:55 (UTC)
  • Shane Wiley: last responded on 21, November 2013 at 04:08 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.