Re: ACTION-258: Propose 'should' for same-party and why

On Mar 21, 2013, at 11:36 AM, Rigo Wenning wrote:

> On Thursday 21 March 2013 10:27:07 Roy T. Fielding wrote:
>> Rigo, I have already explained this a dozen times.  No response is
>> ever necessary in order for this protocol to work its entire
>> benefit for privacy.  Either the server conforms to the user's
>> preference or it does not -- neither option has anything to do
>> with the response.  If you can't trust the server to comply, you
>> can't trust a response from the server either.
> 
> If this would be true, we would not need any TSR, but just a one byte 
> response in a header for all headers: Either you do DNT or you don't. 

We don't even need that much -- the response does not change whether
the user is tracked or not.

> Why then is the TSR much more complex? Are we all so misguided that we 
> have created much ado about nothing?

A simple static file will suffice for most sites.  There are a few
optional fields that provide more information for the sake of
transparency and control, but they aren't needed for privacy nor
intended for real-time automation.

> IMHO, from the above I could draw the conclusion that Adrian and You 
> have not fully factored in the legal dimension of the protocol. Let me 
> give you one example: 
> 
> Shane wants to be able not to honor certain requests under DNT:1.

Which he can do regardless of a response.

> There is agreement that this must be transparent and that the service has to 
> send back "D" in this case. This was on the call yesterday.

There is agreement that, in order to provide transparency, it is best
to include a response for disregarding a signal instead of simply
disregarding it without any response (other than a note in some
privacy policy that explains what is going on).

> You're 
> telling me that we don't need all that as either the thing can do DNT or 
> not. Are you winding me up? Or is Shane's usecase: I will ignore all of 
> user-agent xyz, which isn't expressed by one "D" in the static resource.

No, I am saying that the user agent has no need to check the TSV
because the response is not negotiable.  If the UA wishes to check
the TSV, then it can.

>> The only thing a response does is make it easier to see deployment
>> than reading a privacy policy or making one additional request to
>> the server, and that task (seeing deployment) is not and
>> has never been in the critical path.
> 
> In your mind model that might be true, see above, it breaks things 
> seriously and does not correspond to the fact that I may honor your 
> DNT:1 request or not. As a user of a browser, a browser that ignores the 
> feedback from the server is like driving with a black opaque windshield 
> and without seat belts. "I told you I ignore your DNT:1". "Oh right, but 
> my damn browser did ignore your message".

People have been using the Web without DNT for over 20 years and,
aside from some drivers using the Web on mobile phones while driving,
there has not been any threat of people hitting trees or getting
run over. DNT is a user preference and nothing more.

> If this is about control and communication, it needs some user side 
> implementation. Or we can all go home and prepare for the arms race by 
> cookie blocking, DNT-store blocking extensions, TOR or crowd-sourced 
> blocking lists. A few clicks and the ad-model was yesterday. I think we 
> are here to avoid that. 

No, we are here to define a user expression regarding tracking that
can be voluntarily implemented by services because they want to
adhere as much as possible to the user's desires.

>> It is only of interest to the
>> privacy advocates and regulators in the WG, a total of maybe 200-300
>> people in the entire world, and does not justify adding even a
>> single byte to the many trillion responses per day that occur
>> over HTTP.
> 
> If DNT is only interesting for privacy advocates and regulators,

I did not suggest that.

> we would not need a technical steam factory that does nothing.

A user preference does not "do nothing".  An entire industry exists
to guess the user's preferences, so a legitimate use of the protocol
will not be ignored by good actors.

> We could 
> just write down a policy and the regulator would audit your service from 
> time to time. This is what the Europeans tried for so long. Has it 
> worked? No. Unfortunately, Privacy is more complex than that and 
> interests more people like just 3 or ten paranoid privacy nerds and some 
> regulators. DNT is of interest for many people. And transparency is a 
> very very big part of the cake. Browsers ignored that in 2002. If they 
> ignore it again, we can also blame them for the next round of privacy 
> disturbance in the market. The cost will be much higher than 
> implementing transparency into a browser. A "verifying" browser is just 
> an overstatement to justify ignoring the feedback loop. In fact, the 
> browser doesn't verify anything.

The protocol is about communicating the state on both sides of
the connection.  What can be verified is if the results of the
interactions are consistent with the communicated statements,
which is something that has to be evaluated over time (not in a
single response) or with access to the back-end data.  That is
why the immediate response does nothing to ensure compliance
other than provide a machine-readable public statement.

Discovery can be done without support from the browser,
though a simple browser add-on would make it easier.

>> In contrast, the advantage of a well-known resource
>> is that it can be INDEPENDENTLY verified and monitored to whatever
>> extent advocates and regulators might want, without interfering
>> with the implementation of any existing resources or the
>> performance of any given user's request, and a browser that is
>> truly interested in verification can retrieve the TSR before
>> making any real request of the server that might contain their
>> individual tracking information.
> 
> There is no "true verification" and I'm not attacking the TSR model. 
> Adrian tells you that it doesn't work because only getting feedback is 
> more of a performance hog that he could accept. The problem is that your 
> assumption of a uniform reaction on all requests is only true if you 
> believe the internet is static. The use case "D" above shows you that it 
> isn't static. It may be that your intended implementation of DNT is 
> static per site. But there are other very important use cases. 

No, we've been covering all of the use cases. The static design will
cover the long tail.  The "D" response is no more dynamic than a
site's behavior: The site is not disregarding the signal for the
sake of sending D; it is sending D because it has chosen to disregard
the signal.  In a sane world, browsers would not deliberately send
false signals, and sites would never need to disregard DNT.
Fortunately, this is one dynamic that can be safely cached.

> The feedback mechanism is a cornerstone in the entire legal construct. 

DNT is a (currently undefined) user preference that may or may not be
adhered to by sites.  The legal constructs that might result in
enforcement regarding DNT are specific to each jurisdiction, but
are consistent in not having anything to do with contract law:
neither the user nor the operator of a service engage in a contract
merely by making or answering an embedded third-party request.

In the EU, the legal requirements are on obtaining prior consent, so
whatever the site says after the request is irrelevant.
The response mechanism does not currently have a role in obtaining
consent (only in providing transparency and links).

In the US, the requirements are on fair and non-deceptive
practices with regards to the consumer, which is simply not
going to be satisfied (either way) via after-the-fact HTTP
communication that would only be understandable by an expert.
DNT is not an alternative to existing privacy practices.

> If the protocol is not capable of generating transparency on whether for 
> a certain request DNT:1 was honored, it is not fit for purpose and does 
> not reflect the use case where I want to reject a single DNT:1 request. 
> I think your protocol is able to do it. But Adrian says, it is not fit 
> for purpose and that's why he is not implementing it. 

No, Adrian said that he isn't going to implement verification in
the browser core feature set because verification that the signal
is received and correspondingly accepted is simply not a relevant
feature to the vast majority of users.  That does not prevent it
from being implemented by extensions.  Even if we reverted to the
simplistic notion of sending a header field on every response,
I am quite certain that browsers would not display that response
to the user in the chrome, for the same reason that they don't
display errors in received/truncated content.

This does not in any way lessen the ability of good actors to
adhere to the user's preference, nor does it interfere with the
ability of regulators to enforce the appropriate behavior.

>> It is, in all respects, a far superior solution than header fields
>> alone.  More importantly, it won't break the Web in the way that a
>> dynamically produced, user-specific header field on every response
>> would break the Web's caching properties.
> 
> Maybe the TSR is superior, but looks like Adrian thinks otherwise. He 
> thinks it is just a waste of time. So if it is so superior, why is it so 
> unimportant? Perhaps the policy people have lost the technical people 
> over the discussion? Maybe. I just find it very very sad, if a browser 
> can not give me very important information that is out there, namely 
> whether is site is tracking me or not. Without the TSR, a browser is not 
> better than any of the DNT:1 -header spawning DSL-routers. This is like 
> a phone with a microphone but without a speaker. 

That's nothing more than a paper tiger.  A browser is just a tool.
If the TSR information is useful, someone will find a way to display
it.  If the information is not useful, we don't want to require
that everyone display it.

The principle I design by is that all important resources be given
a URI. If we fail in that respect, then we fail the Web and become
dependent on singular tools. The TSR is a representation of a
resource -- accessible by any tool that can use the Web, not just
the browser engaged in a specific network interaction.

....Roy

Received on Tuesday, 23 April 2013 08:08:35 UTC