alternative to party and outsourcing definitions

The Compliance spec is overly focused on details that aren't relevant
to the user's expectations regarding tracking.  I'd like to fix that,
but I haven't been able to piece together enough focused writing time
to deal with Compliance given my other obligations on TPE.  So, this
is a brief sketch on a way out of this particular rabbit hole.

 = = = = = = = = = = = = = = = = = = = =

Each user action on the Web, such as selecting a link or
submitting a data form, can result in numerous protocol requests
(interactions) by the user agent to satisfy that action.  These requests
might be sent to a single HTTP server, to multiple servers owned by
the same entity, or to a variety of servers owned by multiple
entities.

This specification distinguishes between "first party" sites
(origin servers owned or controlled by the entity that the user
expects to interact with as a result of their intended action) and
"third party" sites (all other origin servers).  Unfortunately,
there is no programmatic way to distinguish the two, since the
user's expectations are often determined by the context in which
an action is presented.

For example, a user might select a button containing the logo of
a familiar company, but which actually links to an advertising referral
counter, which redirects to an auditing service, which also
redirects to a page at the familiar company's site, which in turn
instructs the user agent to retrieve a number of page elements,
which might include elements from the original referral site,
the advertiser, the auditor, the familiar company, and any number
of domains operated on behalf of that company.  A user agent
will not know which of those sites are considered the first party,
since it cannot know why the user chose to select the logo.

Similarly, origin servers cannot control all of the ways in
which their resources might be linked from other sites. A server
might receive requests for page elements that were never expected
to be used by other sites, and thus receive data about user activity
that it had no intent to process.

However, resources on the Web are usually designed for specific
purposes and linked to within specific contexts.  In general, it
is possible for origin servers to design a resource for use in a
first party, third party, or dual-use context.  In particular,
resources that are intended for the purpose of tracking user
activity across multiple sites are almost always sensitive to the
context in which that activity occurs.

In other words, this specification does not rely on a strict
technical definition to distinguish first party resources
from third party resources.  Instead, it relies on implementations
of resources that are intended or predominantly used in a third
party context to comply with the requirements on a third party,
and for implementers to ensure that tracking resources designed
only for first party use are either discouraged from being used by
third parties or constructed such that tracking is disabled when
used in a third party context.

The scope of a "first party" is determined by user expectations
and control over the data collected, not limited to a specific
site, domain, or legal entity.  The first party includes the legal
entity that owns and controls the site intended by the user's action
and any employees, officers, affiliates, and contractors that operate
on behalf of that entity and that are bound under contract to keep
data collected on behalf of that entity confidential within the
scope of the first party, separated from data collected on behalf
of other parties, and to have no independent rights to use, share,
or retain the collected data except as directed by the first party.
A site that is operated on behalf of multiple legal entities is
considered to have a joint first party if a user's expectation
would be that each of those entities have control over the data
collected.

 = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Cheers,

....Roy

Received on Tuesday, 2 October 2012 15:46:58 UTC