- From: Matthias Schunter <mts@zurich.ibm.com>
- Date: Wed, 12 Oct 2011 11:25:32 +0200
- To: JC Cannon <jccannon@microsoft.com>
- CC: "public-tracking@w3.org" <public-tracking@w3.org>
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