w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire [Call for Objections] Text on qualifiers, elements for 1st and 3rd party use
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 2014-02-12 to 2014-02-26.
8 answers have been received.
Jump to results for question:
1. Option A: Descriptively defining 1st and 3rd party
This text would be added after the definition of the qualifiers field in the tracking status resource section.
While different compliance regimes can define requirements and uses of certain qualifiers, and a particular compliance regime might not require the use of qualifiers for particular activities to be permitted, the following qualifiers have the defined, descriptive meanings.
"1": the resource is designed for usage as a first party
"3": the resource is designed for usage as a third party
If you have an objection to this option, please describe your objection, with clear and specific reasoning.
Details
| Responder | Option A: Descriptively defining 1st and 3rd party |
|---|---|
| Chris Pedigo | I support this option because it provides a voluntary method for implementers to provide greater transparency to users. Also, it reflects the long-standing agreement by this working group to differentiate between 1st and 3rd parties, where users generally have different expectations about data collection and use. |
| David Singer | I think this is a reasonable idea; much of our discussion and drafts depend on first and third party, and though it is possible to think of compliance regimes without this distinction, we have not done it. |
| Brad Kulick | I object to this option. These values have already been removed from the tracking status value (TSV) options as it would limit compliance regimes. Reserving them within the qualifiers, as is proposed with this option, again limits the flexibility provided to any accompanying compliance specification document. Upon rejection of this proposal, the "1" and "3" values will still be able to be represented should a compliance regime choose, therefore, not having them as reserved would not adversely affect any similar efforts this group might take when working on the compliance document. |
| Alan Chapell | I object to Option A. The 1st party / 3rd party distinction was created when 1st and 3rd party definitions were tied to the definition of tracking. Given the current definition of tracking in the TPE, 1st/3rd party distinctions are unnecessary here. This is a discussion that should be had in the context of creating a compliance document. Moreover, as pointed out by others, these values have already been removed from the tracking status value (TSV) options as it would limit compliance regimes. I don't believe the chairs should allow this concept to be re-inserted into the TPE through the back door. |
| Shane Wiley | I strongly oppose this option as it presumes a compliance outcome that has not yet manifested and many not be needed. If status codes for "1"st and "3"rd party become necessary then the TPE can be revved to included this at that point. Prematurely presuming a TCS outcome would not be appropriate. |
| Roy Fielding | I object to this option. The new definition of tracking makes distinctions between first and third party design obsolete. A resource that is not tracking will respond as "N" in the TSV, which excludes the collection of data about other contexts. This means that the resource is either only used in one context (first-party) and never shares the data outside of that context, or doesn't collect any data about a particular user in other contexts. Either way, it isn't tracking and thus not subject to qualifiers. A resource that might be tracking (or that later allows use or retention of the data received via that resource in a way that might result in a particular user's activity being observed across multiple distinct contexts) will respond as "T". Why would a resource that is designed only for use in a first-party context ever respond with "T"? The only reason I can think of is that the resource is designed for use on only one site, but shares the received data with other parties in a way that allows the particular user to be tracked. If so, why would the user consider that use of "1" to be better than a "3"? The distinction between "1" and "3" was added at a time when we were effectively saying that any tracking by a first party was okay provided that the data is not shared with third parties. What we are now saying is that collecting data about a user's activity across multiple distinct contexts is tracking, whether or not the user is intentionally interacting with that party. Hence, knowing the user's intent is no longer relevant to the definition of tracking, which means that the first party distinction is no longer relevant to the user (aside from how it impacts the boundaries of a given context). TPE does not need definitions of first or third party in order to describe the protocol. The current usage of those terms in TPE is legacy commentary that will be removed once we are clear on direction from the WG. This does not prevent the same terms from being defined and used within a given compliance regime, nor from being communicated in the TPE's qualifiers field after they have been appropriately defined by a compliance specification. |
| Jack Hobaugh | I object to Option A. On December 8, 2013, Roy Fielding notified the TPWG that an editorial change had been made to remove the “1” and “3” tracking values: “Over the past three weeks I have made a number of changes to the TPE editors' draft in order to remove the hard dependency on the Compliance specification and note the currently pending WG decisions. . . . . This reflects a first pass on revising TPE toward the new plan. Most of the changes are simply editorial rephrasing to avoid an indication of compliance. The non-editorial changes are summarized below. Note that these changes represent a set of proposals by the editor and are subject to the usual disclaimers regarding not yet being WG consensus. . . . . 5.2.* -- removed "1" and "3" tracking status values since they imply compliance; they can still be sent as qualifiers.” This issue appears to be an attempt to re-add the “1” and “3” values in a different place within the specification, i.e. in the qualifier field instead of the tracking property field. But hard-coding these values as qualifier field values then removes those values as values that may be used in a non-W3C compliance specification. Such a move would remove the intended flexibility of the qualifier field: “The meaning of each qualifier is presumed to be defined by one or more of the regimes listed in compliance.” Indeed if the “1” and “3” are already pre-defined in the TPE, these values would likely conflict with the use of these values in other compliance policies. Moreover, upon rejection of this proposal, the "1" and "3" values will still be available for use by a compliance document as is being recommended here if it is so desired by that compliance regime. In other words the qualifier field is reserved for the values defined by the compliance document. By hard-coding the 1 and 3 into the TPE, these values are taken off the board for further use. For example, maybe the compliance policy would want to use ‘1’ as a designator for the permitted use “frequency capping.” This value is no longer available if it has been hard-coded in the TPE. |
| Rob Sherman | I support and prefer Option A. |
2. Option B: No change
Leave text "as is" in current editor's draft (above) and the wiki for further rationale.
If you have an objection to this option, please describe your objection, with clear and specific reasoning.
Details
| Responder | Option B: No change |
|---|---|
| Chris Pedigo | |
| David Singer | I don't have a strong objection, but this leaves a 'low hanging fruit' to catch authoring problems. One might expect that finding a part of a site used in the wrong 'context' (an overloaded term, here first or third party) to be one of the more common mistakes; A authored it as a site, and then B framed it. Site authors know what they intended and what kind of tracking they are doing when they build a first-party site; having them say that (if they can and want to) in a uniform way helps everyone. Sites don't get accused of malice, and users get at least warned of undesirable effects. |
| Brad Kulick | This option is acceptable to me as it does not unnecessarily limit compliance documents. |
| Alan Chapell | I support Option B |
| Shane Wiley | I strongly support this option as it provides solid rationale for why defining these terms in the TPE is unnecessary in light of the new definition of "Tracking". The user need only know if a site is or is not "Tracking" them and the tracking status resource allows for this message to be clearly conveyed among other possible states/outcomes. This will greatly simplify communicating to users how/if their current activities are being "T"racked or not and by whom -- a much simpler conversation than attempting to explain 1st vs. 3rd party and the nuances imbued in either. |
| Roy Fielding | |
| Jack Hobaugh | |
| Rob Sherman | The Working Group has previously decided that “Do Not Track is not fundamentally intended to limit data collection and use by first parties with which the user has a direct relationship” and that “that first party data collection and use would have much fewer restrictions than third parties.” This distinction — between data collection by entities that a consumer knows he or she is interacting with and with entities that are unknown to the consumer — is core to the vast majority of the Working Group's decisions, including those in the TPE, and for that reason the TPE today differentiates between first and third parties. Given these recent pronouncements by the Co-Chairs in resolving other recent CFEs, the Option B rationale in the wiki is not correct to characterize the existing first/third party consensus language in the draft as "legacy commentary." Identifying “1” and “3” qualifiers in the TPE would preserve those identifiers for parties to designate their first- or third-party status and avoid confusion over this important distinction by preventing subsequent compliance regimes from prescribing different definitions of “1” and “3” that may conflict with the baseline understanding reflected in these basic TPWG decisions. Particularly, the “1” and “3” qualifiers preserve a persistent ability across all compliance regimes for parties to designate the status in which they intend a resource to be used. Because it is possible for one party to embed calls to another party's server in its web pages without the second party's knowledge, it's important for a party to be able to convey the manner in which it intends a given resource to be used — particularly if misuse of that resource causes a “tracking” or “not tracking” response to be unintentionally inaccurate. This also allows a user agent to discover if a resource is being incorrectly presented and take appropriate action to behave correctly based on the user's intent. “Option A” does not require the use of the “1” and “3” qualifiers or specify what, if any, action a first or third party is required to take; this decision is appropriately left for the relevant compliance document. But it avoids compliance regimes defining “1” and “3” in ways that frustrate user agents' ability to interpret first- or third-party status for the user, which is particularly important if the TPE anticipates multiple compliance regimes. If the “1” and “3” designations are not reserved, it will be impossible for user agents to reliably differentiate between intended first- and third-party behavior or honor user instructions that depend on whether a particular resource is designed for use in a first- or third-party context. If the Working Group adopts Option B, the Group should retain the long-settled “party,” “first party,” and “third party” definitions to ensure that compliance regimes do not frustrate the integrity of the DNT signaling mechanism by adopting unexpected or inconsistent approaches to these concepts. |
More details on responses
- Chris Pedigo: last responded on 26, February 2014 at 21:12 (UTC)
- David Singer: last responded on 27, February 2014 at 00:01 (UTC)
- Brad Kulick: last responded on 27, February 2014 at 02:29 (UTC)
- Alan Chapell: last responded on 27, February 2014 at 02:41 (UTC)
- Shane Wiley: last responded on 27, February 2014 at 03:05 (UTC)
- Roy Fielding: last responded on 27, February 2014 at 04:26 (UTC)
- Jack Hobaugh: last responded on 27, February 2014 at 04:39 (UTC)
- Rob Sherman: last responded on 27, February 2014 at 04:53 (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