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

On Mar 20, 2013, at 2:44 PM, Rigo Wenning wrote:

> On Wednesday 20 March 2013 15:26:44 Adrian Bateman wrote:
>> I don't believe most "everyday" browsers will take the performance hit
>> of downloading the TSR.
> 
> This is sad for privacy on the Web. A browser that can read a chain of 
> CSS files, that has client side storage for all kinds of information, 
> that can wait until an entire industry has done an auction on a targeted 
> user selected from a million profiles, is not capable of reading, 
> parsing and using a 1k chunk of information and provide useful 
> information to the user?
> 
> Performance is a pseudo-argument and it will remain one. If the very 
> little information in the TSR has a problem of performance or 
> scalability, there must be a way to solve it. 
> 
> Or do you say that the web knowledge around the table has failed to 
> deliver a scalable solution? If so, what is the problem? You need a 
> round trip? Blame Roy! A header would not have needed any more round 
> trip. 

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.

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

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.

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.

....Roy

Received on Thursday, 21 March 2013 17:30:50 UTC