Results for ISSUE-170: CfO on Data Append

Hi Team,

enclosed is the outcome of ISSUE-170 (Data Append).

Regards,
matthias

ISSUE-170: Definition of and what/whether limitations around data append
and first parties

* *


  Summary

What limitations should be placed on first parties and data append?

This question addresses ISSUE-170
<https://www.w3.org/2011/tracking-protection/track/issues/170>. For more
information please refer to the wiki page.
<https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_First_Party_Compliance>
Results can be found here
https://www.w3.org/2002/09/wbs/49311/tpwg-first-parties-170/results
<https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_First_Party_Compliance>

We determined that Option (A) received weaker substantiated objections
and is therefore determined as the consensus of the group. In
conclusion, ISSUE 170 is closed.


  Detailed Argumentation


    The Options


      Text Proposed by 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.


      Text Proposed by 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.


    Received Input

We received 7 inputs to our questionnaire.


      Objections against Option A

We received substantial objections against Option (A). The main concern
was that if first parties can collect and analyse data over multiple
sessions, then the first party has enhanced capabilities that are
undesirable under do not track. Specific examples of objections that
were raised were

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.

·         "[...information can be used] for profiling."

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.

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


      Assessment of the Objections against Option A

There are three concerns that have been raised.

1.       Sharing with Service Providers:

2.       Privacy Invasive Usages:

3.       EU Law

We believe that concern (1) has been mitigated: According to the
definition of a "service provider" currently in use, service providers
must not use data except for servicing a given customer (1^st party).
They are not permitted to share data with other parties. As a
consequence, service providers act on behalf of the first party and can
be seen as a part of the first party without no independent rights to
the data. As a consequence, we rate the substance of this objection as
rather low.

The raised concern (2) is a valid and important concern. The point
raised is that by analyzing, storing, collecting, and using data over a
long time (under DNT;1), first parties can assemble data that allows
them to exhibit behaviors that are technically not tracking under this
specification but may be seen as unwanted or a violation of personal
privacy. However, it is not the mission of this working group to address
every potential privacy issue, even online. The group's work has focused
specifically on the privacy concerns raised by cross-site tracking for
advertising and other purposes.

The raised concern (3) is important but is not deemed substantial for
this issue. As agreed in this group, legislation always trumps this
standard, i.e., if a certain behavior is not permitted under EU law,
then enterprises must follow the law and not this standard.


      Objections against 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.[...]

·         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 it's 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.

Chris Pedigo

·         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 3^rd parties from collecting/using data about DNT:1 users
except for a narrow set of permitted uses. In an effort to prevent 3^rd
parties from working around these restrictions, the W3C standard would
prohibit 1^st parties from sharing data about DNT:1 users that the 3^rd
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. 

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.


      Assessment of the Objections against Option B

The raised objections express the following concerns:

1.       Basic protections (e.g. sharing of tracking data with 3^rd
parties) are already enforced. Similarily, obtaining  tracking data from
another context (3^rd party)

2.       Very high cost of implementation and incompatibility with many
services where external databases are queried to improve the user
experience.

3.       The MAY clause is perceived to be superfluous.

The most substantiated arguments that have been raised are points (1)
and (2).

Limitations on first party collection and use of data are outside the
scope of this group's work and are not implicated by the definition of
tracking that we have adopted by consensus. It would be logically
inconsistent to require first parties to adopt certain prohibitions on
their practices that were not requested by a DNA:1 request.

The specific points made are that the increased privacy is not
proportional to the increased cost and likelihood of adoption. We deem
this to be very relevant: Our goal is to balance privacy gain with the
cost and efficiency of enterprises to adopt this standard. The arguments
made substantiate the claim that for a relatively small gain (e.g. to
disallow first parties to retrieve non-tracking data based on data of a
transaction), the implementation cost is substantially increased and the
potential burden falls on a far wider swath of services, including small
publishers who may lack the technical capacity to acknowledge and
respond to Do Not Track requests.


    Results

In conclusion, ISSUE 170 is closed. We determined that Option (A)
received weaker substantiated objections and is therefore determined as
the consensus of the group.