W3C home > Mailing lists > Public > public-tracking@w3.org > September 2013

proposed short-term changes to TCS

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 20 Sep 2013 17:20:11 -0600
Message-Id: <32DDE1A7-9A86-43ED-BBA7-4971A1C1E962@gbiv.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 20 September 2013 23:20:39 UTC