Re: DNT-aware JavaScript (ISSUE-84, ACTION-85, ACTION-111)

I still don't follow.  Can you explain what specific traffic you think the API adds that is a concern?

--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)







On 2012-02-09, at 12:31 -0500, JC Cannon wrote:

> Forgive my hasty reply. The huge increase statement was probably due to reading too many emails to fast. Adding API calls will increase traffic and complexity over what we have today. All change takes greater than zero effort.
> 
> Regards,
> JC
> 
> -----Original Message-----
> From: Thomas Roessler [mailto:tlr@w3.org] 
> Sent: Thursday, February 09, 2012 8:48 AM
> To: JC Cannon
> Cc: Thomas Roessler; Shane Wiley; Kevin Smith; Jonathan Mayer; David Singer; tom@mozilla.com; Roy T. T. Fielding; public-tracking@w3.org (public-tracking@w3.org)
> Subject: Re: DNT-aware JavaScript (ISSUE-84, ACTION-85, ACTION-111)
> 
> On 2012-02-07, at 14:06 -0500, JC Cannon wrote:
> 
>> I'm concerned that the implementation of Action 111 as proposed would cause a huge increase in Internet traffic for very little benefit.
> 
> Can you explain how the API sketched in my note increases traffic?  My read is that it should actually *de*crease traffic.
> 
>> JC
>> 
>> -----Original Message-----
>> From: Shane Wiley [mailto:wileys@yahoo-inc.com] 
>> Sent: Wednesday, February 01, 2012 6:00 PM
>> To: Thomas Roessler; Kevin Smith
>> Cc: Jonathan Mayer; David Singer; tom@mozilla.com; Roy T. T. Fielding; public-tracking@w3.org (public-tracking@w3.org)
>> Subject: RE: DNT-aware JavaScript (ISSUE-84, ACTION-85, ACTION-111)
>> 
>> Tom,
>> 
>> Would this still allow for the 1st party domain list to somehow be incorporated into the site-specific exceptions structure?
>> 
>> - Shane
>> 
>> -----Original Message-----
>> From: Thomas Roessler [mailto:tlr@w3.org] 
>> Sent: Wednesday, February 01, 2012 10:45 AM
>> To: Kevin Smith
>> Cc: Thomas Roessler; Jonathan Mayer; David Singer; tom@mozilla.com; Roy T. T. Fielding; public-tracking@w3.org (public-tracking@w3.org)
>> Subject: Re: DNT-aware JavaScript (ISSUE-84, ACTION-85, ACTION-111)
>> 
>> Per ACTION-111, due today, I owe additional follow-up on this thread, based on hallway conversations in Brussels.
>> 
>> It seemed like there is general agreement that the exceptions we're talking about in the context of this work (site-specific exceptions) should be on an origin pair basis; indeed, the site-specific notion and the origin pair notion translate into each other easily.
>> 
>> This concept can be addressed with a simple JavaScript property that can be used to read the DNT status overall, and a callback based API like the one I called out in my earlier message.
>> 
>> Conversation with Shane, in particular, suggested that there was relatively little desire on his side to look into standardizing the communication between first and third parties over exception status, and that the ability of an outer frame to navigate an inner one (e.g., to a URI that serves a different class of ad) was easily sufficient.
>> 
>> PROPOSED, therefore: We specify a simple, call-back based opt back in API for site-specific exceptions, and a simple JavaScript property.  Both are scoped by origin pair.  We leave the messiness that multi-tenant DOMs bring out of scope.
>> 
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 2012-01-25, at 22:18 +0100, Kevin Smith wrote:
>> 
>>> While functional, I think both of these suggestions are extremely inelegant hacks.  Companies may choose to use a method such as these, but I would not think the W3C would want to formally recommend such an approach.  You don't usually see hacks standardized.  I agree with the two browser developers that we should leave this section out and let companies work around it if they ever need to.
>>> 
>>> I actually don't understand the use case.  It is true that 3rd party code can be embedded directly in a 1st party dom.  However, tracking does not occur unless a request goes out to the 3rd party server.  When would you need to know the DNT status in a situation where you would not make a request to the 3rd party?  If you are going to make a request anyway, just handle it when you do so (ie throw away the data).  Why would you want to make a request just to see if you can make a request?
>>> 
>>> -----Original Message-----
>>> From: Thomas Roessler [mailto:tlr@w3.org] 
>>> Sent: Wednesday, January 25, 2012 6:07 PM
>>> To: Jonathan Mayer; David Singer; tom@mozilla.com
>>> Cc: Thomas Roessler; Roy T. T. Fielding; public-tracking@w3.org (public-tracking@w3.org)
>>> Subject: Re: DNT-aware JavaScript (ISSUE-84, ACTION-85)
>>> 
>>> To follow up to this: Tom Lowenthal, David Singer and I had a parallel discussion a little earlier.
>>> 
>>> Our conclusion is that, while there are mechanisms to determine the DNT status of another origin without anything else that we discuss here, that gets messy extremely quickly, and requires the participation of the site that is tracking.
>>> 
>>> Proposal:  DNT status is a property of the origin pair, i.e., the pair of top-level origin and the origin the script is running under.  This, in particular, is the scope for site-specific extensions, for which we would propose an asynchronous API that permits discovery of the DNT status of the current origin pair.
>>> 
>>> Example: example-times.com has an ad from example-ad.com in an iframe.  The top-level origin is example-times.com.  The origin of a script executing within the iframe is example-ad.com.
>>> 
>>> A call like this:
>>> 	requestSpecificException(function (dntStatus) { ... });
>>> 
>>> ... permits the ad to request an exception *within the current context*.  If the exception has been granted already, the callback can be executed by the browser without user interaction, and immediately.  Otherwise, the callback is executed once the user has made a choice.
>>> 
>>> 
>>> In the case of several scripts (some retrieved cross-origin) running within one DOM, the scripts executed from additional origins can instantiate an iframe from that additional origin, that they can then communicate with using postMessage, and that can use the exception request API made available by the browser.  That way, the upper level script can discover the additional origin's DNT status without having to access any non-cacheable resources.
>>> 
>>> 
>>> An additional use case we heard in the meetings deals with the question how first parties can discover the exception status of ads they are loading.
>>> 
>>> Since we are working on the assumption of adding browser features, we can assume HTML5 and Web Messaging to be available. One idea to address this use case might be to actually specify the protocol that is executed between first parties and ads they run on top of Web Messaging, within the specifications that this group develops.  I'd be curious to hear whether the advertising networks and publishers involved here would be interested in that work.
>>> 
>>> 
>>> I'll leave the summary on this level for the moment, but would welcome discussion, and hope to refine this further as we go.
>>> 
>>> Regards,
>>> --
>>> Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 2012-01-25, at 17:17 +0100, Jonathan Mayer wrote:
>>> 
>>>> 
>>>> On Jan 25, 2012, at 4:49 PM, Roy T. Fielding wrote:
>>>> 
>>>>> On Jan 25, 2012, at 3:05 PM, Jonathan Mayer wrote:
>>>>> 
>>>>>> Proposed non-normative text:
>>>>>> 
>>>>>> It is straightforward to make JavaScript aware of DNT status.  In the simplest case, a server can mirror the DNT HTTP header into JavaScript.  For example, in PHP:
>>>>>> 
>>>>>> <?php
>>>>>> header("Content-type: text/javascript"); 
>>>>>> if(array_key_exists("HTTP_DNT", $_SERVER))
>>>>>> 	echo "var dnt = '';";
>>>>>> else
>>>>>> 	echo "var dnt = '" . $_SERVER["HTTP_DNT"] . "';"; ?>
>>>>> 
>>>>> Er, please don't do that on a real site -- javascript injection attacks are fun.
>>>> 
>>>> <?php
>>>> header("Content-type: text/javascript");
>>>> header("Vary: DNT");
>>>> $validDntHeaders = array("0", "1");
>>>> $dntHeader = "";
>>>> if(array_key_exists("HTTP_DNT", $_SERVER))
>>>> 	if(in_array($_SERVER["HTTP_DNT"], $validDntHeaders, true))
>>>> 		$dntHeader = $_SERVER["HTTP_DNT"]
>>>> echo "var dnt = '" . $dntHeader . "';"; ?>
>>>> 
>>>>> In any case, requiring the server to deliver non-cacheable pages is not an option.
>>>>> One of the advantages of doing personalization via javascript is that 
>>>>> both the page and the javascript can be static and extensively 
>>>>> cached.  Hence, this is not a solution to the issue.
>>>> 
>>>> Why not use Vary: DNT?
>>>> 
>>>>>> This standard does not include a JavaScript API for DNT status.  A webpage may include scripts from multiple origins; a naive approach (e.g. window.dnt) would give an embedded script the DNT status for the webpage's origin, which may differ from the DNT status for the script's origin.  Providing a DNT status API that accounts for different-origin embedded scripts would introduce implementation challenges for browser developers and script authors and could be a source of fingerprinting information.  Moreover, the first load of a script requires an HTTP request; the server may need to examine the request's DNT header anyways to determine how it may log and use that request.
>>>>> 
>>>>> I think there is a misunderstanding here.  The only DNT status that 
>>>>> this API needs to relate is that of the webpage origin.  The DNT 
>>>>> status of the script origin does not matter
>>>> 
>>>> Websites often embed a third-party script that phones home.  We have to support that use case.
>>>> 
>>>>> (if it did, then the script origin would be able to handle that when 
>>>>> the script was requested and deliver a different script).
>>>> 
>>>> Yes.  That would be an example of an implementation that is not "the simplest case," and in many cases the better implementation.  But it runs into the same caching issues.
>>>> 
>>>>> ....Roy
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
>

Received on Thursday, 9 February 2012 18:04:03 UTC