w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire [Call for Objections] Limitations for first parties
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-06-18 to 2014-07-09.
7 answers have been received.
Jump to results for question:
1. Objections to Option A
Option A
If a first party receives a DNT:1 signal, the first party MAY collect, retain, and use data to both analyze usage and customize the content, services, and advertising within the context of a first party experience. A first party MAY share data about this network interaction with its service providers, but it MUST NOT share data about this network interaction with third parties.
The first party MUST NOT share data about this network interaction with third parties who could not collect the data themselves under this recommendation. Data about the transaction MAY be shared with service providers acting on behalf of the first party.
Details
| Responder | Objections to Option A |
|---|---|
| Vinay Goel | |
| Xuemei Yan | What is the First Party? There should be an explicit definition of the First party.The First party is a organization who provide direct interaction with user, also include its corporate affiliates and subsidiaries who is under the same corporate ownership as the first party. |
| Mike O'Neill | This would allow first-parties to share data with service providers for retargeting users in other contexts even when DNT is set. There is also nothing to stop service providers using this information for profiling. If cross-context profiling or retargeting is needed then a DNT UGE or OOBC should be obtained for it, otherwise this compliance document is useless. There should also be a reference (as there is in Option B) to the fact that the first-party/third-party role qualification may be irrelevant, as it is in the EU for legal reasons, or that sites may wish to gain the trust of users by raising the privacy bar. |
| Chris Pedigo | The OPA supports this option as it clarifies the long-standing intent of the working group and would be helpful guidance for implementers of this standard. |
| John Simpson | This would seem to allow service providers to re-target based on 1st party data and that should be precluded. |
| Jeffrey Chester | When DNT:1 is sent, a first party should not be able to share data with service providers--who are likely serving as form of data-driven profiling and targeting apparatus. |
| Rob Sherman | We support Option A, which permits people to continue to use the online services they are used to using but prevents first parties from “gaming the system” by sharing information with a third party that could not collect it directly. We do not agree with the suggestion some working group members have made that this language would enable service providers to build profiles of people's activity across multiple first parties' sites. If a service provider engaged in that kind of activity when DNT is enabled, it presumably would lose eligibility for “service provider” status, under the currently existing definition of that term. We also disagree with Mike O’Neill’s suggestion that this language should be rejected because it does not include language analyzing the impact of EU law on first parties. It is of course always true that legal obligations will trump compliance with a voluntary standard, but there is no need to call out that legal obligations “especially” trump the standard here. Likewise, it seems imprudent for a global standards body to suggest that particular national laws have special status, if we anticipate that parties with operations in many nations may want to implement the standard. |
2. Objections to Option B
Option B
When DNT:1 is received:
A 1st Party MUST NOT combine or otherwise use identifiable data received from another party with data it has collected while a 1st Party.
A 1st Party MUST NOT share identifiable data with another party unless the data was provided voluntarily by, or necessary to supply a service explicitly requested by, the user.
A 1st Party MAY elect further restrictions on the collection or use of such data.
Details
| Responder | Objections to Option B |
|---|---|
| Vinay Goel | The new obligations made in this option either are superfluous or create additional barriers to implementation. The first proposed obligation (must not combine or otherwise use ...) places a HUGE burden on websites implementing the spec. Implementers are not given guidance on what 'identifiable data' means, and in many instances, first parties leverage publicly available information to better the site visitor's experience. While I commend the efforts to place limitations on data acquired from another source, it shouldn't be addressed in this spec which is addressing the collection of data by a single party across different contexts. We should first address the online system first before tackling issues that may change practices governing offline data management. I oppose the second proposed obligation (must not share identifiable data) because it too provides unclear implementation guidelines and may not be necessary based on other language in the spec. Specifically, what do they mean by 'identifiable data' again here? And, the above sentences in Option A (which this proposal isn't deleting) prevent the first party from sharing data with a third parties that couldn't otherwise collect it themselves. If the first party is doing that, then they are relying on out of band consent or an exception. In addition, how would the first party determine what is 'necessary to supply a service'? A first party may say 'its necessary for me to serve ads on my site. But I know I can only serve one ad, or consumers will get annoyed. So I must share this data so I can get the best ad possible that would pay me the most money so I can pay my engineers who built this website.' I know its a simple example, but it shows that this proposed statement adds a lot more confusion to the spec. The last statement is completely superfluous. A first party may do a lot of things. This spec doesn't need to list all things a first party may do. |
| Xuemei Yan | Does it means that a First party Must NOT combine use identifiable data of the First party collected itself and another First party collected? Does it means that a First party May combine use identifiable data of the first data collected itself and another third party collected? |
| Mike O'Neill | |
| Chris Pedigo | The Online Publishers Association (OPA) objects to the proposal to prohibit “data append” activities by first parties. The W3C Tracking Protection Working Group has diligently worked to develop a DNT standard that would give consumers a persistent choice over “tracking,” which the group defined as “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.” “Data append” activities do not fit within this definition and should not be considered within the scope of this group’s work. It is important to note that the W3C standard already would prohibit 3rd parties from collecting/using data about DNT:1 users except for a narrow set of permitted uses. In an effort to prevent 3rd parties from working around these restrictions, the W3C standard would prohibit 1st parties from sharing data about DNT:1 users that the 3rd party could not otherwise collect/use. These two restrictions effectively close any loophole for parties to work around the DNT standard. As a result, the prohibition on “data append” activities is a major departure for this standard. It would restrict how first-party publishers present and market to consumers who visit their sites. The visit is an intentional relationship between the user and a publisher, who wants to know his customers and market to them, in the very context in which the relationship is occurring. For example, Firstparty.com sells flowers via business relationships with florists around the country. When the user visits the site, firstparty.com might use a third party that matches the user’s IP address with the user’s likely location within a metropolitan area. The location information is then used to customize the inventory available to that customer. This practice would be a data append. First party publishers also use third party data for such routine functions as auto fill-in for zip code, or cleansing or de-duping a database, or offering an online discount once a purchase is made offline from a retailer. Appending data from lawful sources for a first party relation is governed by the first party relationship (and most typically, by privacy policies and other consumer-facing notices) not by a W3C standard designed to fill in the gap where there is no relationship. If consumers aren't happy with the service provided by firstparty.com, then they can choose not to use it as there is a direct relationship between consumer and first party. Because consumers have this fundamental ability to choose what service to use, there is no reason to put restrictions on data append. First parties that operate as third parties in other contexts may be treated as third parties, but not when they are operating as first parties. These types of first party data practices should be considered out of scope for the DNT standard. The DNT signal is a valuable tool for consumers to express choice about how their data is collected across multiple distinct contexts or used outside the context in which it occurred. But, the DNT signal is not an effective or appropriate tool for restricting how outside data is used by first party publishers. |
| John Simpson | I support this option. A strong case could be made that the definition of tracking would preclude data append because when DNT:1 is enabled data would be combined from two distinct contexts. However, given the discussion in the working group, I think it must be crystal clear that data append is not allowed when DNT:! is enabled. |
| Jeffrey Chester | We support this option |
| Rob Sherman | We strongly object to Option B, which is excessively broad and would make it impossible for many organizations to adopt the standard. The provisions also use concepts that are not defined (and should not be defined) in the draft, such as “identifiable data,” which raise serious questions about whether implementers could clearly understand what they are supposed to do. The first obligation would sweep so broadly as to, for example, break the core functionality of many established, fundamental internet services such as email and social networks. For example, it would prohibit Alice from mentioning her friend Bob in a Facebook status update, if Bob had enabled DNT. In this instance, Facebook (the first party) would be “combining” and “using identifiable data received from another party” (Alice) and associating it with Bob's Facebook profile — information Bob shared while he was using Facebook. Likewise, if an email provider received an email from Alice addressed to Bob, it would under this formulation be required to reject the email because it would have to “combine or otherwise use” the email address information together with Bob's account. Prohibiting this kind of activity is simply at odds with the basic things people want to do when they use the Internet. If we adopt a standard that prohibits them, it will doom the standard to failure because most interactive websites will not be able to adopt it, or if they do then they will not be able to offer the services their users want to receive. The second obligation relating to sharing is also far too broad and adds unnecessary confusion for implementers. As framed, it conflicts with the language in Option A (which would also be retained under this proposal) by prohibiting sharing not only with THIRD parties but with “another” party, which presumably includes a service provider of the first party. Because the concept of “necessary” is not defined, implementers would be left to wonder whether using a managed server provider results in a “sharing” prohibited by DNT, even if the provider is only a service provider that has no independent right to use the data. If a user of a website sues the website operator, would the website violate DNT by allowing its lawyer to view a message the user sent to the operator through the website? Third, it's not clear that last proviso is necessary or additive. It is of course always true that any party can impose on itself any legally permitted limitations that it wishes, so it is unnecessary to spell out here that first parties can elect further restrictions in order to make that happen. If anything, specifying here that first parties can elect further restrictions implies that third parties cannot because there is no comparable statement in the third party section. For all of these faults, the basic goal of this proposal, as we understand it, is accomplished by Option A, which says that first parties can't circumvent DNT by providing information about a network interaction in which DNT is set to a third party that couldn't collect it directly. Option A does this without all breaking fundamental aspects of the way the Internet works, as Option B would. |
More details on responses
- Vinay Goel: last responded on 25, June 2014 at 21:10 (UTC)
- Xuemei Yan: last responded on 26, June 2014 at 08:18 (UTC)
- Mike O'Neill: last responded on 7, July 2014 at 10:56 (UTC)
- Chris Pedigo: last responded on 9, July 2014 at 14:22 (UTC)
- John Simpson: last responded on 9, July 2014 at 23:28 (UTC)
- Jeffrey Chester: last responded on 10, July 2014 at 02:25 (UTC)
- Rob Sherman: last responded on 10, July 2014 at 03:29 (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