Re: issue-112, exceptions for subdomains

On Aug 23, 2012, at 8:32 AM, Vinay Goel <> wrote:

> As both David W and Shane pointed out, this is still an open issue that we'd like to further discuss.  I don't think its sufficient to allow for the exception to cover the fully qualified domain only.  I know there are some concerns of abuse with the expansion of ICAAN policy, but by limiting the exception to fully qualified domains we'd be limiting significantly how a trusted third party ad services provider could use an exception.
> Take the scenario of Acme, a site retargeting advertising firm.  It has three clients that it collects data on; but each client's data is owned by the client; not Acme.  Acme cannot combine/use data from Website A with data from Website B.  Acme uses the domain  For data collected on Website A, it uses; for Website B it uses; for Website C it uses  If Acme is asking for an exception, it needs it to cover all of its retargeting services for each client.  It cannot ask for a separate exception for each of its customers (could be in the hundreds).  By limiting the exception to fully qualified domains only, you would be encouraging retargeting firms to move away from cookie-based silos.
> We should change the language of the current draft such that can make an exception request for * or (*.)  I would suggest we allow for a domain to ask for an exception for itself and its subdomains, but restrict how a subdomain can ask for an exception.  Specifically: can ask for an exception for and; can ask for an exception only for  (*), but not

This appears to be a request for Web-wide exceptions to be requested for a broader scope than as currently drafted. As I understand the use case -- a user visits (a 3rd-party re-targeting firm), hears about how great the re-targeting feature is, decides to opt-in to Acme retargeting even while sending a DNT:1 signal to everyone else, and uses the JavaScript API to request a Web-wide exception. But wants to ask the user to send DNT:0 for requests to all subdomains of, not just to the effective script origin ("").

We could potentially achieve this requirement through adding an optional, boolean, default=false parameter named `includeSubdomains` to the requestWebWideTrackingException() method. That would add some complexity, certainly, and we'd want to add a specification that this should only be done for subdomains that are part of the same party as defined elsewhere, but otherwise seems straightforward.

On Aug 23, 2012, at 12:52 PM, Vinay Goel <> wrote:

> I agree  a user that might want to give NYT an exception, but not give the vendor of NYT's other clients an exception.  In that situation, NY Times should be responsible for using the domain and not *  That only works though if that retargeting firm uses client-specific subdomains.  Not all do.

As a result, I'm not sure I understand this particular use case, Vinay. If a user grants a site-wide exception on (whether the exception is for "*" or for a list of third-party trackers including ""), the exception would only apply to those third parties embedded within, not on other sites. The re-targeter isn't getting permission to track on other first party sites, no matter whether it uses client-specific subdomains or not.

As I understand it, Vinay's is a separate request from Shane's request [0] to include sub-domains (in response to Ian and me on ISSUE-112) -- Shane wants a parameter to list which (or all) subdomains are part of the same first-party to which the site-wide exception should be applied. I would be concerned about that as it could broaden the request for an exception well beyond the current context, which was the advantage of site-specific exceptions to begin with.  As I noted last month, it's also possible for user agents to optionally do this already -- "check here to extend this permission to other properties owned by the same company" and use the same-party or OUR-HOST to determine the scope, which could incentivize that documentation and extend beyond just subdomains to other domains controlled by the same party.



Received on Wednesday, 29 August 2012 02:47:29 UTC