RE: RE: JS Exception API

One more thought.  It's also critical that the 1st party knows upfront whether it has an exception or not, because under DNT:1, it may choose to use completely different 3rd party services (ie - to maximize cpm, they may choose to go with 1 ad exchange for targeted ads, but a completely different one for truly random ads)

Its not acceptable to have to try to make these decisions after the page has loaded and requests have succeeded or failed.  It makes for a more expensive and complicated implementation and a poorer user experience, so again, a site would not implement it.

Again, I am ok with having the option to pass it an array of 3rd party services, but it would be a very poor API indeed which required a parameter in which everyone used the same value.

-----Original Message-----
From: TOUBIANA, VINCENT (VINCENT) [mailto:Vincent.Toubiana@alcatel-lucent.com] 
Sent: Friday, March 02, 2012 4:59 AM
To: Kevin Smith; Tom Lowenthal; public-tracking@w3.org
Cc: Andy Zeigler; Nicholas Doty
Subject: RE: RE: JS Exception API

Kevin,

I believe points 2 & 4.  depend of how the User Interface is implemented and this part is not covered by the API. Users may not be prompted with the list of parties asking an exception but it is still important that the browser receives this list. 
I can imagine that some users will simply blacklist mistrusted third parties and will not be prompted unless a first party requires an exception for a blacklisted third party.

Regarding point 1. & 3., I don't believe there will be that many different configurations --mostly because users may not know specifically each third party-- so publishers may not have many configuration to consider. At worst, they could simply consider two cases:
1) All third parties have been granted an exception,
2) At least one third party has not bee granted an exception.

Also, for point 1.a I don't see why it would be an issue if one element in the chain receives DNT:1


Vincent
 
________________________________________
From: Kevin Smith [kevsmith@adobe.com]
Sent: Friday, March 02, 2012 12:41 AM
To: Tom Lowenthal; public-tracking@w3.org
Cc: Andy Zeigler; Nicholas Doty
Subject: RE: JS Exception API

This is feedback for the JavaScript API itself and I am not sure what issue to attach this to.  If anyone has any suggestions, let me know and I will try to get it filed correctly.



Again, I want to emphasize that I believe exceptions are a tool for the user much more than for the site.  A lot of our discussion and documentation seems to be around protecting users from exceptions, and I believe that has resulted in a slightly skewed definition.



For the actual JS API, I am OK if we allow an optional array of 3rd party 'trackers', but it should be optional with a default of '*'.  Very very few would ever pass in anything other than '*', which is what defaults are for.  Again, I totally understand the reasoning behind wanting to give the user as much control as possible.  However, if 1st parties have to request exceptions on a per 3rd party basis, then we might as well axe the exceptions from our docs completely.  It is completely impractical for a 1st party to request individual exceptions for the 3rd parties it employs for the following reasons:



1.       Programmatically, neither the first party, nor the UA will often know exactly who all the 3rd parties are - especially at run time.

a.       Most ad requests go through a chain of 3rd party services (ad server to ad exchange to dsp to ad server etc), the 1st party may only know the 1st stop in the chain, but all stops need to function correctly to show an ad (targeted or otherwise).  Granting the 1st stop an exception, but not the remainder of the chain, will not do much good.

b.      Many 1st parties are starting to use Tag Managers to load 3rd parties asynchronously because they can deploy and change their 3rd party services without retagging or updating their pages in any way.  There will be no way to parse the DOM and determine which 3rd parties will be used on a given page, and hardcoding a list of 3rd party services, especially on a per page basis, would negate a large part of the benefit provided by the tag managers

2.       It would provide a miserable experience for the user, and present the user with options that very few would be capable of using correctly.

a.       Most users will never have heard of the 3rd parties that are being used behind the scenes (I know - this is the concern for the other argument as well).  If you present a user with a long list of companies that they have never heard of, how are they going to decide which they are ok with, and which they are not.  If you provide links to the companies and their policies, very few will follow those links.  If you give detailed descriptions of  each company and their use cases and why the 1st party uses them, you very quickly end up with a long difficult document that few will read and even fewer will understand (think privacy policies or terms of use).  Even worse, here we would expect users to make actual intelligent decisions based on it

b.      Users may get frequent exception requests from the same 1st party because the list of 3rd parties will change frequently for some 1st parties.

3.       Companies will not implement it - this is the most important reason

a.       As has been stated, the user experience would be poor, and sites owners do not want a negative experience associated with their site, even if the negative experience is generated by the browser.

b.      The user experience could be very unstable.  If some 3rd parties are allowed to interact freely while others have restrictions, it quickly becomes very difficult to control the overall experience.  For instance, if you have 10 3rd party services employed on your site, the possible number of different experiences that you may need to control could be as high as 2^10 or 1024

c.       It is waaaaaay too expensive to maintain different code paths based on which of my services have been approved.  In an all or nothing scenario, I have one decision - what I will show a user without DNT on, and what I will show a user with DNT on.  However, if some of my services have been approved and others have not, I have to decide exactly which content I will show for which subset of services.  From a development, deployment, and maintenance perspective, this gets expensive very quickly, especially since the 3rd parties may change frequently.  In other words, if adoption of DNT stays relatively small, it would be more cost effective for large sites simply to lose monetization opportunities on DNT enabled visitors, than it would be for them to support exceptions where they had to ask for exceptions for each 3rd party.  They would not offer exceptions, and then it's the user that loses, not the site.

4.       The exception process would drive users to disable DNT - If a user is constantly presented with complicated options, large dialogs, decisions they are not equipped to make, they will either disable DNT, or get used to clicking 'Approve All', which invalidates the reason for splitting them out in the first place.  If large sites do not offer exceptions because of cost or complexity, users will be unable to get the experience they want from trusted sites which will again encourage them to disable DNT.   Note: I am confident the browser designers can implement a better UI than I have described, and I am not attempting to prescribe a UI.  I am just suggesting that even the best browser designers will be hard pressed to overcome the implicit challenges presented by this approach.





Therefore, I again state that the list should be optional with a default of 'all' or '*'.



-kevin









-----Original Message-----
From: Tom Lowenthal [mailto:tom@mozilla.com]
Sent: Wednesday, February 29, 2012 11:19 AM
To: public-tracking@w3.org
Cc: Andy Zeigler; Nicholas Doty
Subject: JS Exception API



I know you've been waiting for this for a while: here's the JavaScript API that Andy, Nick and I have been working on for the last few weeks.

Enjoy!



[cid:image001.png@01CCF7AE.156FF250]

Kevin Smith
Engineering Manager
Adobe

385.221.1288 (tel)
kevsmith@adobe.com

550 E Timpanogos Cir
Orem, UT, 84097
www.adobe.com

Received on Monday, 5 March 2012 22:09:42 UTC