Re: tracking-ISSUE-81: Do we need a response at all from server?

JC,

That's a reasonable question (consumer value).  IMHO it's not just  
about how many consumers would look at it.  Regulators could look at  
it.  Researchers could look at it; I can imagine extensions or  
browsers developing a capacity to log such responses, perhaps in a  
Netalyzr-type model, http://netalyzr.icsi.berkeley.edu (I believe  
clients automatically report data to a research database).

Perhaps the larger point is that more transparency to web clients may  
facilitate innovation.  I take your point that browsers are moving in  
the direction of simpler UI, which goes with the more appliance-like  
mobile device trend.  But apps may still be able to take advantage of  
that data.

Not being an engineer, I don't know if that makes technical sense, and  
if it does, how much that changes the calculus.  I readily admit that  
I did not understand Roy's explanation of the increased server load.

Lee

On Oct 11, 2011, at 4:00 PM, JC Cannon wrote:

> Matthias,
>
> You indicated the potential value. I feel we should tease out who  
> would realistically take advantage of those benefits and to what  
> extent. If less than 1% of consumers would look at the values would  
> it be worth every web site changing their servers to send the  
> response?
>
> How would the consumer see the values if they wanted to?
>
> JC
>
> -----Original Message-----
> From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org 
> ] On Behalf Of Matthias Schunter
> Sent: Tuesday, October 11, 2011 3:41 PM
> To: public-tracking@w3.org
> Subject: Re: tracking-ISSUE-81: Do we need a response at all from  
> server?
>
> Hi JC,
>
>
> thanks for this valuable input to our discussion of response headers.
>
> I believe that it is important to investigate the potential benefits:
>  Why do we need response headers; what purpose should they serve?
>
> Once we see clearer, we can then identify the cost-optimal  
> implementation.
>
> Value I've seen so far are:
> - Reflecting the preference of the user to identify
>   transmission errors
> - Communicating the choice of the server whether to comply
>   with a DNT preference or not
> - Determining whether a server understood a preference or not.
>
> Are there values that I've overlooked?
>
> Another discussion to have is the scope of responses: Do we want the
> server choices to be a fixed value for a site or unique subsets or
> requests?
>
>
> Regards,
> matthias
>
>
>
> On 10/11/2011 10:13 PM, JC Cannon wrote:
>> We think the topic of a response to the DNT header will require a  
>> fair
>> amount of further discussion.  We think that a number of other issues
>> should be resolved first before we can reach a consensus on whether  
>> it
>> should be sent and what it means. Here are some specific concerns:
>>
>>
>>
>> COST OF IMPLEMENTATION
>>
>>
>>
>> While most web server environments do make it simple to return a HTTP
>> header as part of the response, integrating a way to return such a
>> header into existing systems isn't necessarily straightforward. Some
>> systems used today to combine web requests with information known
>> about the user to form targeted responses and do not allow for an  
>> easy
>> way to derive what opt-ins are in place and why the response is the
>> way it is. A response header that indicates what the service saw in
>> the DNT request AND how it was processed is not always a trivial
>> engineering exercise.
>>
>>
>>
>> VALUE OF IMPLEMENTATION
>>
>>
>>
>> Today browsers are consistently moving in the direction of less and
>> less user interface, reducing the number of choices users must make  
>> to
>> experience the web, and trying to make smart choices on behalf of the
>> user. It's not immediately obvious that all browser vendors will want
>> to process a DNT response and take any action. Before we can truly
>> evaluate the benefit of a response, we should have a clearer idea of
>> what browser vendors want to do with this information. There is  
>> little
>> benefit to the community in requiring online services to invest in
>> being able to return a response if the value is then ignored.
>>
>>
>>
>> WHEN TO RETURN A RESPONSE
>>
>>
>>
>> To fullyunderstand the benefit of a response, we need to understand
>> when a response would be required. If we conclude too early that a
>> response is required we run the risk of creating reasons to have some
>> kind of value and potentially making the response more and more
>> complex. Perhaps a good resolution at this point is to agree that
>> nobody believes having a response is detrimental but until we address
>> some of the other questions before us (e.g. first party vs. third
>> party) it will be hard to demonstrate that the cost is worth the  
>> benefit.
>>
>>
>>
>> INCREASED LOAD ON WEB SERVERS
>>
>>
>>
>> We share Roy's concerns [1] about additional load on servers and
>> content caches.
>>
>>
>>
>> [1] http://lists.w3.org/Archives/Public/public-tracking/2011Oct/0047.html
>>
>>
>>
>> JC
>>
>> Twitter <http://twitter.com/jccannon7>
>>
>>
>>
>
> -- 
> Dr. Matthias Schunter, MBA
> IBM Zurich Research Laboratory,  Ph. +41 (44) 724-8329
> Homepage: www.schunter.org, Email: schunter(at)acm.org
> PGP Fingerprint    989AA3ED 21A19EF2 B0058374 BE0EE10D
>
>
>
>

Received on Wednesday, 12 October 2011 00:11:15 UTC