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

Hi JC,


thanks for your input. I fully agree that the discussion "whether
end-users benefit from the information we send" is valuable.

Some thoughts on how I would structure the design process (All: please
complete my info if I overlooked pieces):

1. The first goal should be to define what we want to achieve /
   what info to send:
	- Ensuring proper end-to-end communcation of the preference
           (by, e.g., copying the preference on the return message)
	- Communicating the choice to do DNT or not by the server
	- ...

2. The second goal is to discuss criterias for assessing the
   quality of design/implementation options. E.g.
	- who can use the info and how? (from JC)
	- does it serve its purpose? (from me)
	- difficulty of implementing the server side (from JC?)
	- compatibility with caching (from Roy)
	- what are potential regulatory/legal consequences
            (from Justin)
	- ...

3. The third goal is to create a number of potential alternatives:
	- Header with one/two/more fields on all/some elements
	- Well-known location on server
	- Clauses in the privacy policy
	- Nothing
	- ...

4. The fourth step is to select the best alternative

The point I am trying to make is that the usefulness/displayability is
one (albeit important) assessment criteria out of multiple. However,
if 'do users actually care' is taken as the only criteria, servers
should probably stop sending SSL certificates ;-)

ALL: If you like, we can 'formalize' this process by using it as a
pattern to analyze and document design choices in our early documents.
Once we then see clearer, we can strip these annotations or produce
annotated/plain versions.



Regards,
matthias




On 10/12/2011 1:00 AM, 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 09:26:07 UTC