RE: JS Exception API

Matthias,

I agree that the situation below presents a valid problem.  However, it does not make sense to break the rest of exceptions to fix this one problem.  I cannot think of a good solution to disallow a single 3rd party while approving everything else for a given 1st party.  Even if you could provide a good UI for the user, it would have all the cost implications I mentioned for the site.  I personally think that if you do not trust the tools the 1st party is using, then you do not trust the 1st party, and therefore should not give them an exception.  So the exception request must have a link to a policy which clearly states all the 3rd parties they employ (or similar functionality).  Again, this is very difficult for a given page, but it should be possible on a 1st party wide basis.  This way, the educated user can still drill in and decide whether they trust the 1st party, we do not bludgeon the average user to death with requests, and the site still gets the all or nothing benefits which *may* make it feasible to offer an extension.

-kevin

-----Original Message-----
From: Matthias Schunter [mailto:mts@zurich.ibm.com] 
Sent: Tuesday, March 06, 2012 11:15 AM
To: public-tracking@w3.org
Subject: Re: JS Exception API

Hi Kevin,


I understand your point that asking for a "*'" permission is easier for the site. It basically means that you declare a 1st party to be trusted to do everything right and not select untrusted trackers.

I also understand that the user experience is sub-optimal if there is a new set of third-parties frequently popping up for approval .

However, I believe that your proposal  (using "*" exeptions without declaration of the third parties) does not satisfy the EU requirement of 'informed' consent. It also leaves some privacy holes.

Consider a scenario where I do not like a given 'data-broker' third party (e.g. this bad player will publishing all my browsing traces and data on the web ;-)),  Your proposal permits that this service tracks me all over my most trusted sites while I cannot even determine that this has happened.

>From my perspective, the requirements are;
- There exists a user friendly way to approve and disapprove individual third
   parties (blacklisting or the like).
- Users can find out what third party services are in use

I do not know whether, e.g., providing a "*" consent while then dynamically declaring/displaying the third parties in use would be called 'informed consent'. Such a solution would be a mix of "*"
exceptions plus TPL-like blacklisting of some third parties.

Did I misunderstand something?
Does anybody have ideas how to resolve this?



Regards,
matthias

On 3/5/2012 11:02 PM, Kevin Smith wrote:
> Vincent, thanks for your reply.  Responses inline below
> 
> 
> -----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.
> 
> Certainly the user interface could mitigate some of the issues, and if your blacklisted idea is adopted (is this the same tpl discussion we have had?), then perhaps that would help.  However, how would you see the workflow going then?  If site A uses 5 3rd party services, and a user arrives with DNT:1 enabled, you are saying that they would get a full page opt-in option, and then if one of the 5 services happened to be on a blacklist they would get a second opt-in request?  I don't actually think this solves much because a) remember that neither the 1st party or the browser will necessarily know the list of services at original run time which means the second opt-in may not be able to occur until the time of the actual request to the blacklisted service, and b) this is too late in the process for the 1st party to react intelligently.  This would essentially require them, as I mentioned below, to handle each service request individually.  Partial exemptions are simply a nig!
 htmare f
or 1st parties.
> 
> 
>> 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 been granted an exception.
> 
> Knowing that some but not all of the exceptions have been granted is completely useless to a 1st party.  What decisions can they make with that information?  None.   Either they treat it as if none were granted (in which case, we are back to an '*'), or they need to know which exceptions were not granted, so they can make a decision about what to do.  This implies that we expect them to make different decisions based on which services have not received an exception - which in turn means they have to customize code on a per 3rd party basis and make sure they all work together - expensive, complicated, and not worth it when they can handle things in a Boolean fashion by using an '*' or by not offering exceptions at all.
> 
> Plus, forget all about monetizing and tracking completely for a minute.  Site owners want complete control over how their page acts, looks, and renders.  Each 3rd party service included on a site may behave differently when receiving DNT:1 then DNT:0.  Its bad enough to handle two states - all on and all off.  But, depending on the extent to which the services interact, it could quickly become unmanageable to handle all the possible states of some on and some off.  Again, not even talking about tracking or monetizing, this makes it very difficult just to present a stable, coherent interface for users.
> 
> 
>> Also, for point 1.a I don't see why it would be an issue if one 
>> element in the chain receives DNT:1
> 
> Because each service in the chain relies on the others to provide a specific value to the first party.  If step 2 in the chain thinks it can provide full value, but step 3 is prohibited from doing so two things happen - 1) step 2 needs to know that step 3 cannot provide full value, and 2) in consequence, step 2 cannot provide full value so it has to make what decisions it makes as if it got DNT:1 - it may be able to track like it got dnt:0, but to a large degree it has to behave as if it received a DNT:1.  Meanwhile, since all this happens after the 1st party page has already loaded, even if the browser indicates to the 1st party somehow the dnt status it sent, it will be making decisions based on incorrect information (ie, it thought it could monetize this visitor, but in fact it could not, at least to the extent it expected).  To alert the 1st party after the fact, we would have to also implement an event of some kind (a DNT was different than you thought event), which t!
 he 1st p
arty will then have to catch
>  after their page has completely loaded and decide what to do about it.  This is getting pretty complicated and expensive really quickly.  I repeat, the 1st party needs to know upfront - I can monetize, or I can't.  The more run time decisions we add in, the more it means that sites will not employ exceptions.  Then the users and DNT lose.
> 
> 
> 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 Tuesday, 6 March 2012 23:36:54 UTC