- From: Kevin Trilli <ktrilli@truste.com>
- Date: Wed, 12 Oct 2011 08:07:28 -0700
- To: Matthias Schunter <mts@zurich.ibm.com>
- CC: JC Cannon <jccannon@microsoft.com>, "public-tracking@w3.org" <public-tracking@w3.org>
This seems like a pretty good framework. I would add a couple other points: 1) What is the desired degree of transparency we are looking to achieve via this system? - privacy policies that sit on website that is not available to the consumer (antiquated model) - opt-out cookies - trustmarks/icons that occur directly at the point of collection / use (the DAA model) - more transactional methods of indicating collection / use is happening (the location arrow on IOS5) - other 2) What kind of compliance regime is desired for DNT? This is independent of #1 to some degree. - enabling compliance entities to check whether transparency and choice is provided, at the transaction level. Today for the DAA system this is provided via detailed icon serving reports, periodic opt-out system monitoring and periodic audit. There is a limitation in the OBA use case of externally determining whether a given ad is OBA or not (ie false positive of a coincidentally relevant context ad, multiple entities in the ad chain, etc..). DNT could help solve that, if desired. - By requiring a DNT response from all 'compliant' parties, you now have a way to incent more participation in the standard with a simple filter to see only DNT compliant ads. This could also evolve to a more sophisticated trust model since it involves direct server participation. To some degree, the impact on end user behavior would drive this motivation to participate by the entities (error messages, trust marks in the browser, etc...). 3) Other use cases: There is a fairly common use case of 1st parties wanting to monitor and control their own web properties to know who is on their site and what they are doing (e.g., data leakage). DNT could help with this inventory and house cleaning exercise. In some cases, companies offering very sensitive products want to place ads on sites there there is absolutely NO OBA going on. It is very difficult to determine this as explained above. 4) Interaction with existing systems - What does DNT impact the use/need/meaning of opt-out cookies? - How does DNT interact/co-exist with DAA icons as it relates to consumer education and transa? - etc... Thinking through the scenarios could also impact if/what is in the response header. Kevin On Oct 12, 2011, at 2:25 AM, Matthias Schunter wrote: > 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 15:08:01 UTC