Re: Work ahead; volunteers?

I agree with Kevin's analysis here.

On Mar 6, 2012, at 12:31 PM, Kevin Smith wrote:

> I am not making any claims for Adobe at this point, nor am I disputing that from a business logic perspective, a site may be willing to offer various levels of content for various levels of exceptions.  Conceptually that makes great sense.  Nor am I disputing that there will be simple cases where none of my concerns are valid.  What I am saying is that 
> 
> 1) In many cases it will not be technically feasible to know ahead of time what 3rd parties will be included by the time a given page has fully loaded - what good will your DNT:2 header or the API be if you do not know which 3rd parties to ask for.  
> 2) The cost for enterprise level sites to support partial exceptions would far outweigh the benefit (or opportunity cost) which could be acquired by partially monetizing visitors unless visitors with DNT:1 enabled make up a very significant percentage of traffic
> 
> Shane, pick a Yahoo property and ask yourself the following questions (rhetorical - you don't need to answer to the group):
> * What advantages does Yahoo really get for offering an exception at all?  Would it not make more sense to the bottom line to simply state that your page requires tracking to be able to function (it probably already does this if it sees javascript or cookies disabled - I am guessing you do not make two complete versions of your sites anymore - one for JS and one for non-js.  Would you be willing to do so for DNT:1?)
> * Are you really willing to change your data storage structures,  storage mechanisms, retrieval mechanisms and various internal processes to handle data differently when it comes in with DNT:1?  Or would you rather throw away that visitor or hit completely?
> 
> I am guessing the answers to these questions are threshold based.  Would you be willing to make the adjustments above for .01% of your traffic?  1%?  5%?  20%?
> 
> * If you are willing to offer an exception, how much more willing would you be if you could handle it server side with a single Boolean value - this is what I do when my 3rd parties can track, this is what I do when my 3rd parties cannot track?  Or how much less willing would you be to handle it exception by exception, page by page and have to update your entire front end?  (ie - handle DNT with a single site wide gateway, or customize each page?)
> * How will you decide what content to show based on a response of 'some but not all of your 3rd parties have exceptions'?  
> * Are you really willing to do all of your dnt-exception handling and dnt-exception based navigation client-side.  Do you use any sort of tag manager?  If so, are you willing to get rid of it?
> 
> I am guessing that the threshold percentage from the above tests continues to go up as you factor in these additional costs.  Again, I am not necessarily against allowing the array of 3rd parties to be passed in, I am stating that it will rarely be used by large companies and therefore should have a default of '*'.  However, if we axe it completely, a lot of issues gets simpler.  For instance, you do not need your DNT:2 header anymore, nor do you need the JS API.  We are back to DNT:1 or 0.
> 
> 
> -kevin
> 
> -----Original Message-----
> From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
> Sent: Tuesday, March 06, 2012 10:28 AM
> To: Kevin Smith; Matthias Schunter; public-tracking@w3.org
> Subject: RE: Work ahead; volunteers?
> 
> Kevin,
> 
> I'm not sure I agree but haven't canvassed enough large first parties to have developed a broader point of view.  I can see real situations where users reject exceptions for one or two 3rd parties and that a publisher would be okay with that if the bulk of their business is with others and/or they can dynamically decide to only call for ads from those 3rd parties that have been granted exceptions.  Are you stating that Adobe will only go for an "all or nothing" approach for 3rd party site specific exceptions?
> 
> Thank you,
> Shane
> 
> -----Original Message-----
> From: Kevin Smith [mailto:kevsmith@adobe.com] 
> Sent: Tuesday, March 06, 2012 12:10 PM
> To: Shane Wiley; Matthias Schunter; public-tracking@w3.org
> Subject: RE: Work ahead; volunteers?
> 
> I actually do not think the API is necessary because 1st parties are not going to be willing to ask for exceptions on a per 3rd party basis.  They will only use the '*' option which means we only need an API to see whether there is an exception for the 1st party, which does not have any finger printing risk. 
> 
> -----Original Message-----
> From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
> Sent: Tuesday, March 06, 2012 7:59 AM
> To: Matthias Schunter; public-tracking@w3.org
> Subject: RE: Work ahead; volunteers?
> 
> Matthias,
> 
> I don't believe the following issue is closed (or if it is, I'll propose we reopen the issue as Server-Side interrogation of site-specific exceptions will be an important option -- bad actors can find numerous other ways to digitally fingerprint a user's system and I believe we've agreed to not cripple the DNT standard in attempts to manage bad actors).
> 
> "- we decided not to provide an API for retrieving the set
>  of exceptions for a server due to the resulting finger
>  printing risks"
> 
> - Shane
> 
> -----Original Message-----
> From: Matthias Schunter [mailto:mts@zurich.ibm.com]
> Sent: Tuesday, March 06, 2012 9:03 AM
> To: public-tracking@w3.org
> Subject: TPE: Work ahead; volunteers?
> 
> Hi Folks,
> 
> 
> Enclosed is a summary list of areas where I believe more work is needed in order to create a complete and stable draft for the TPE document.
> 
> If you want to volunteer to push one of these areas or if you want to propose an action for one of them, please drop me a line.
> 
> Once we shipped the current draft, we need to tackle these open questions to finalize our spec.
> 
> 
> Regards,
> matthias
> 
> PS: Please drop me a line if I overlooked an area of if one of these areas has been resolve (with me overlooking the emails)
> 
> 
> ---8<---
> -----------------------------------------------------
> [Sec 4.3: Querying DNT request header via Javascript]
> -----------------------------------------------------
> - ISSUE-116: Can we build an API that works reliably?
> 
> ------------------------------------------------------
> [Sec 5: Server responses to user agent]
> ------------------------------------------------------
> 
> The goal of this section is to define mechanisms to tell a user agent to what extent his preferences are followed.
> 
> We have designed
> - A proposal for response headers
> - A proposal for posting information at a well-known URI
> 
> Questions:
> - Which of the following options to choose:
>  - Headers-only, URI-only, or both
> - What is the minimal data attached to a response.
>  The URIs propose a very rich set while the headers remain slim.
>  Example data that has been proposed by the URIs:
> 	- List of associated sites
> 	- List of partner sites
> 	- URL to an info page
> 	- URL to an opt-in and opt-out page
> 	- URL to the policy
> 	- Extensions
> - If we choose headers+URI: What is the best interplay
>  between them
> 
> -----------------------------------------------------
> [Sec 6: Informing the Server about Site-specific Exceptions]
> -----------------------------------------------------
> 
> In this area,
> - we created a Javascript API that allows a server to ask for
>  exceptions (Section 6)
> - we decided not to provide an API for retrieving the set
>  of exceptions for a server due to the resulting finger
>  printing risks
> 
> Open questions 1: Informing the server about exceptions
> - ISSUE-111: Different DNT value
> - ISSUE-84: API call that allows server to query
> 
> Open Question 2:
> - ISSUE-113: Should we allow for global exceptions
>  of the form like "thirdparty.*"
> 
> 

----------
John M. Simpson
Consumer Advocate
Consumer Watchdog
1750 Ocean Park Blvd. ,Suite 200
Santa Monica, CA,90405
Tel: 310-392-7041
Cell: 310-292-1902
www.ConsumerWatchdog.org
john@consumerwatchdog.org