- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Tue, 15 May 2012 15:32:56 -0700
- To: Nicholas Doty <npdoty@w3.org>
- CC: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <63294A1959410048A33AEE161379C8023D16CB2C75@SP2-EX07VS02.ds.corp.yahoo.com>
Nick, Great points - please see my comments below in [ ]: - Shane From: Nicholas Doty [mailto:npdoty@w3.org] Sent: Tuesday, May 15, 2012 2:12 PM To: Shane Wiley Cc: public-tracking@w3.org Subject: Re: ACTION-177: Add an API to let a site request a web-wide exception Thanks for drafting this, Shane. If we want to re-use the TrackingResponseCallback interface for this method, we should also define what the "granted" parameter will signify. In the current draft (for requestSiteSpecificTrackingException): The granted parameter passed to the callback is the user's response; true indicates the user wants an exception on this site for all of the trackers specified inarrayOfDomainStrings. The response false indicates that the user does not want an exception on this site for at least one of the trackers specified inarrayOfDomainStrings. A particular response to the API - like a DNT response header - is only valid immediately, and users' preferences may change. Presumably in this case true indicates that the user wants to grant an exception to the tracker specified in domainString and false indicates that the user does not wish to grant an exception to the tracker. [Agreed - but with a change you proposed below (drop domainString and simply refer to requesting domain) I would change the language to state "True indicates that the user wants to grant a web-wide exception to the requester and False indicates the user does not wish to grant a web-wide exception to the requester".] The caution that preferences may change is particularly true here. In addition, what do you want to happen if the Web-wide exception is granted generally but the user's preferences specify that they'll continue to send DNT:1 while browsing some sites or during some browsing modes? One possibility: A particular value of `granted` in response to this API is only valid immediately and generally; users' preferences may change and other user preferences (per site or per browsing mode, for example) may override. [I believe the web-wide exception should trump - outside of "privacy browsing" which typically wouldn't impact multi-site tracking if a cookie already exists for that domain.] Also, A separate call must be made for each DomainString and the requester origin should match the DomainString. I do believe the agreement in DC was that the requester origin would have to match. Is there a particular reason you wrote this as "should" rather than "must"? If the requester origin and requested exception domain are always the same, could we remove the domainString parameter altogether and the request would just be for the script origin? [Agreed - move to "MUST" and drop domainString and simply refer to the requesting orgin.] Thanks, Nick On May 15, 2012, at 1:05 AM, Shane Wiley wrote: 6.7 Web-wide exceptions Users may wish to configure exceptions for a certain trusted tracker across several or all sites. User agents may instantiate NavigatorDoNotTrack.requestWebWideTrackingException. Sites should test for the existence of requestWebWideTrackingException before calling the method. If an exception is granted in this context and the user-agent stores that preference, a user agent may send a DNT:0 header even if a tracking preference isn't expressed for other requests. A web-wide exception request can be initiated even when navigator.doNotTrack is null. [NoInterfaceObject] interface NavigatorDoNotTrack { void requestWebWideTrackingException (DomainString, TrackingResponseCallback callback, optional explanationString, optional detailURI); }; - DomainString, a single domain signifying the origin of the domain receiving the web-wide exception. - Note - all like named fields carry the same definitions as set forth in requestSiteSpecificTrackingException. A separate call must be made for each DomainString and the requester origin should match the DomainString. Multiple calls can be facilitated through nested iFrames for each domain, similar to the NAI opt-out page individual domain call routines to set opt-out cookies for each domain.
Received on Tuesday, 15 May 2012 22:33:50 UTC