Re: action-317, discussion of the service-provider flag and the same-party resource

continuing a thread on ISSUE-137 ...

On Jan 23, 2013, at 3:42 AM, Aleecia M. McDonald wrote:
> On Jan 22, 2013, at 3:22 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> [...]
>> The only possible reason to use a flag to indicate that a service provider
>> is involved in the provision of services is to perform some form of
>> automated discrimination against service providers. 
> [...]
> 
> We continue to have this discussion. There is utterly nothing new here. I just want to note that I continue to disagree. 
> 
> Another very valuable use is to provide transparency to users. Service providers ARE NOT the same thing as first parties. Taking away the users' ready ability to have transparency into where data flows is a poor decision (given the somewhat twisted world we are in where DNT does not actually allow users to stop data collection in the first place.) At the very least, DNT should allow users to see what the heck is going on and visualize data flows. 

First, what does a user learn from a single character "s"?
How is that accomplishing data transparency?

Second, a user doesn't have the ready ability to know where data flows
within a first party either.

In practice, a first party will contract with other legal entities
(other parties, according to the compliance spec, which might
include contractors, accountants, and even IaaS providers) to perform
analysis or manipulation of that data long after the HTTP interactions
are done.  In fact, there is no way for a first party to truthfully
indicate, at the time of an HTTP interaction, all of the parties that
might eventually touch the data: they tend to change over time,
particularly during audits.  It simply doesn't matter for privacy.

What matters for privacy is that the user can know which party
(the first party) is responsible for maintaining control over the
data such that it isn't disclosed beyond the purpose for which the
data was provided. If the first party fails in that responsibility,
they can't avoid responsibility by blaming a service provider.

Service providers are a well understood concept. They enable
relatively young companies to compete with giants.  They are
specifically addressed (and accepted) by all of the privacy
legislation that I've read as part of this process.  I personally
prefer the data controller and data processor definitions used
by the EU, but they are effectively the same in terms of intent.

A service provider acting as the first party is the first party,
for all intents and purposes of DNT. Every major business
on the Web makes use of service providers, in one form or another,
to accomplish what the user believes is a first party website.
And folks here have repeatedly stated that the scope of first
party should match the user's intended interactions.

Users simply don't care whether a service like Netflix is hosted by
the company itself or by a dynamically determined cloud provider
based on current loads.  They don't care whether the embedded
images are delivered via self-hosted servers, a CDN like Akamai,
or an infrastructure service like S7.  If they want to know how a
given service works, they can ask the first party (politely, or
via subpoena).

What users do care about (regarding DNT) is whether the data
collected or derived from access to one site can be accessed or
used by any other site outside the original context in which
that data was collected.  Hence, we only allow the exception
for service providers acting as a first party when they ensure
that the data collected is siloed and under the control of the
first party.  An actual privacy risk is covered by an appropriate
DNT constraint.

This doesn't prevent a browser from visualizing the DNS requests
it makes and the TCP connections established and the HTTP pathways
(at least up to a gateway or origin server).  But it is complete
nonsense to suggest that is the sum total of the data flow, and
that DNT is somehow bankrupt without revealing the data flow.
DNT is about expressing a preference (from the UA) and expressing
a commitment to adhere to that preference (from the data controller).
DNT is not a tool for visualizing data flow.

We are going to continue getting nowhere on compliance if we don't
limit the scope of our solutions to the actual problem we have been
chartered to address.

> Your (Roy) assertion at this point in the discussion is usually that no browsers have promised to implement such a feature. The response back from Mozilla engineers is that they would like to enable add-ons to be able to provide this functionality. I think this is entirely reasonable. 

Actually, no, the only topic that I've requested such implementation
commitments is the exception API, since we have to implement a
cookie-based consent anyway to satisfy EU laws and handle the
100% of browsers that currently don't implement exceptions but
do implement DNT:1. I'd rather not implement both, and I'd rather
not continue this WG indefinitely while we wait for implementations
of the exception API.

As far as the "s" flag is concerned, I don't care whether any
browser implements (or wants to have) that feature.  It is
not a relevant question given that I am not going to send it
unless it can be demonstrated to solve an actual privacy harm.

> With no browsers promising to do anything like automated discrimination against service providers, I do not see how lack of implementation is actually a strong argument here. On the contrary, I would expect to see add-ons use this data for visualization. 

I didn't say that there were promises of discrimination.  I said
that it serves no possible purpose to send "s" on a response other
than to enable discrimination.  It provides no useful information
on its own.  If you aren't going to use the field for automation,
then there is no reason to send it in the protocol.

If you think data flow information is critical for privacy, then
I suggest that the appropriate forum for such consideration is
whichever groups regulate the content of privacy policies.

Cheers,

....Roy