RE: JS Exception API

I would like to hear more about the polling concept - I am not exactly sure how that would work.  But I definitely think a base requirement for exceptions to work is that the 1st party needs to know server-side prior to returning its page the effect that DNT will have on it.

-----Original Message-----
From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: Sunday, March 11, 2012 2:19 PM
To: Kevin Smith; TOUBIANA, VINCENT (VINCENT); Nicholas Doty; Andy Zeigler
Cc: Tom Lowenthal; public-tracking@w3.org
Subject: RE: JS Exception API

Kevin,

I believe this is another reason a server-side polling solution would be helpful.  :-)

- Shane

-----Original Message-----
From: Kevin Smith [mailto:kevsmith@adobe.com] 
Sent: Friday, March 09, 2012 3:40 PM
To: Shane Wiley; TOUBIANA, VINCENT (VINCENT); Nicholas Doty; Andy Zeigler
Cc: Tom Lowenthal; public-tracking@w3.org
Subject: RE: JS Exception API

No, I am talking about the expense of maintaining multiple code paths or multiple versions of your site depending on which of your 3rd parties have an exception.  The best example I can think of is javascript.  I remember when we used to have to build every site for both javascript enabled browsers and non-javscript enabled browsers.  We wanted a nice interface and good user experience, so we built sites using javascript.  But back when a large enough percentage of our traffic came from NonJS enabled browsers, we would have to build and maintain a less dynamic version of our site for those users.  This was very expensive, but we had to do it.  However, as soon as the percentage of non-js visitors dropped to an acceptable level, we stopped building the second version of our sites and just put a big error at the top stating -"This site requires JS to function"

-----Original Message-----
From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
Sent: Thursday, March 08, 2012 8:30 PM
To: Kevin Smith; TOUBIANA, VINCENT (VINCENT); Nicholas Doty; Andy Zeigler
Cc: Tom Lowenthal; public-tracking@w3.org
Subject: RE: JS Exception API

Kevin,

Are you arguing the cost of polling?  If this were accomplished server-side and rarely performed, where do you see the expense?  In the initial coding or in the operations?  There is no requirement to actually poll so worst case a publisher would be where they are today with opt-outs and have no visibility to the opt-out state of the 3rd parties serving ads on their sites.

- Shane

-----Original Message-----
From: Kevin Smith [mailto:kevsmith@adobe.com] 
Sent: Thursday, March 08, 2012 1:25 PM
To: TOUBIANA, VINCENT (VINCENT); Nicholas Doty; Andy Zeigler
Cc: Tom Lowenthal; public-tracking@w3.org
Subject: RE: JS Exception API

I certainly do not argue against the value of this information.  I simply think the cost to acquire this information will far outweigh the benefit.

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

I believe a fine grained mechanism could also help 1st parties to know which 3rd parties are not trusted by users. If a single 3rd party is "blacklisted" by many users (I assume the 1st party would be notified by the callback) that would raise a red flag and the 1st party may then investigate why this 3rd party is not trusted.

Vincent 

-----Message d'origine-----
De : Kevin Smith [mailto:kevsmith@adobe.com] Envoyé : mercredi 7 mars 2012 01:55 À : Nicholas Doty; Andy Zeigler Cc : Tom Lowenthal; public-tracking@w3.org Objet : RE: JS Exception API

A 1st party often may not even know the 3rd parties needed to monetize a specific page due to things such as 3rd party chains and tag managers.  They may know what 3rd parties they use across the entire 1st party, but not necessarily for a single page or section of their site.  So the list could be total site wide exceptions rather than just for that page (this would also reduce the # of requests to the user), but tag managers would have to be able to edit that list of 3rd parties if they were to continue to provide much value.

Nick, I would be very interested to know if the publishers that are interested in per 3rd party exceptions have thought through the custom implementations they would have to do.  From a pure business case it makes sense.  It's not until you do a cost/benefit analysis that it starts breaking down.

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Tuesday, March 06, 2012 5:22 PM
To: Andy Zeigler
Cc: Kevin Smith; Tom Lowenthal; public-tracking@w3.org
Subject: Re: JS Exception API

On Mar 6, 2012, at 3:32 PM, Andy Zeigler wrote:

> If it isn't feasible for 1st-parties to know which 3rd-parties will render on their site, then websites will just use "*". 

A 1st-party may not know which 3rd-parties will render on their site but still know which 3rd-parties on its site it needs a tracking exception for in order to make a monetization decision. For example, a lot of sites install social widgets and (I expect) don't require that those social widgets track the user in order to monetize their content. They could request a list of their analytics and advertising trackers they need for monetization purposes and a user could continue sending DNT:1 to the social networking widgets on the page.

> If sites only use "*", then I agree with you that it makes sense to scrap the per-3rd-party affordance altogether, as it has the side effect of massively simplifying implementations, *and* it solves the "DNT value accessibility from Javascript" issue. In other words, there would only be one possible DNT value per DOM, which means that any 3rd-party script will get the correct value. 

I agree that we can use implementation experience to help guide us here. If no site ever uses anything but "*", then there would evidently be no use for that parameter. I'm not sure that's the case given what we've heard from publishers, but I'm very interested to hear more input there.

Thanks,
Nick

Received on Sunday, 11 March 2012 23:18:45 UTC