Hi David,
 
It is possible to signal cross-domain using web technologies as long as both the domains are handled by "servers" that take part in the communication. There are a number of ways to do that with existing web technologies.
So if BigCo has 3 sites A,B,C and user visits site A they can give informed consent to tracking (or cookie usage under EU e-privacy) across all the sites, and the fact of that consent is available to the server when they visit site B. This is already in use on thousands of sites.
 
The reason that this would be useful for the DNT UGE is that DNT is the only standard signal to embedded third-parties. Sure we could have script that took part in the (cross-domain OOBC signalling) consent but why do we have to re-invent the wheel? The DNT UGE is perfectly capable of doing the job (signalling consent to the embedded third-parties) if supported by the cross-domain signalling technique.
 
BigCo would know immediately when a user visits one of their sites what their consent status is. The only problem, as you point out, is when a user has revoked their UGE in the browser (say for site A) before visiting C.  BigCo would give them a UGE for site C although the user has already revoked it for site A. The fact that they have revoked it means they have withdrawn consent for all sites (the are all covered by the same policy and managed by the same data controller) but BigCo will not realise this till the user revisits site A.
 
But I think that is an edge case which we could fix in DNT2.0. What I am suggesting is a minor text tweak. There is already an implicit time delay ("at the same time" is impossible in practice even using the multiple iframe technique) so why not just spell out how it could be used. IE11 has not implemented UGE revoking yet (ATM you have to delete all data including cookies to revoke UGEs) so this is not yet an issue anyway.
 
 
I am travelling so I will not be able to take part in the call today, but I would like to carry this discussion on when I get back.
 
Mike


Mike O'Neill
Technical Director

Baycloud Systems



Oxford Centre for Innovation

New Road

Oxford

OX1 1BY

Tel. 01865 735619

Fax: 01865 26101

michael.oneill@baycloud.com
 
 
-------- Original Message --------
Subject: Re: changes to TPE before last call.
From: David Singer <singer@apple.com>
Date: Mon, February 10, 2014 11:49 pm
To: "public-tracking@w3.org (public-tracking@w3.org)"
<public-tracking@w3.org>
Cc: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>


On Feb 6, 2014, at 18:10 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> David,
>
> Even with the multi-iframe method "at the time of the call" is not testable
> because the API will be called in the context of different frames probably
> handled by separate servers. The frame may be dynamically created by script
> in the first document origin when consent is given but the API will be
> called by script in another origin initiated by code executing in another
> server.

But it is observable.

>
> There are also better ways to do it than dynamically creating multiple
> frames, especially if there are a large number of domains to register
> consent in. There are thousands of sites in the P&G use-case and it would be
> better to encourage them to use the UGE than forcing them to rely on a less
> transparent OOBC.

Sure. I only gave frames as one example. But in some cases, perhaps an OOBC is needed.

I won’t critique your text yet, because I am still struggling to know what you are trying to fix.
* I understand you want to make some minor adjustments to the text, to align with the definitions of party, site, and so on. (Probably fine).
* I think you perceive a possible ambiguity over the word ‘each’ (though I don’t see it myself).
* I think I have understood two different requests:
a) do something to make it simpler for organizations with multiple distinct and domain-name-unrelated sites to request, and register, an exception for all or many of them in one go
b) make it permissible to register an exception at a time that is undoubtedly different from the time when the consent was granted

On the last, I think you are proposing (b) as a solution to (a), allowing an organization to get consent for a whole slew of sites, and then, as the user visits some of them (later), register the exception in a kind of ‘lazy binding’ way.
It is, on the face of it, a neat idea, but I think it suffers from at least two problems. (1) How do we know that the user still agrees/consents? Any exception deletion would have happened on another, unrelated (by name) site that this site cannot check. (2) Indeed, how do we even remember that the user consented once? A cookie has the same scoping as the exception request, and if I could have set a cookie at the time of consent, I could have set an exception. If I am recording the consent in ‘some other way’, I am effectively behaving as if I have OOBC, and then making that in-band at the time of first visit, later. I am not sure that that is a good idea.

I am obviously highly hesitant to blow a hole in between the consent and the recording of it, for all sites, in order to fix a problem with a small number of them — especially if the fix doesn’t really fix it for them, either. I think introducing that gap introduces a whole slew of problems and questions: how long, for example?

I also think we’re past the threshold for opening new issues on old text (i.e. text that existed when we closed the issue list); I know we’ll open new issues on things that arise as a consequence of other issue fixes, but this doesn’t fall into that category, either.

I think we have at least two solutions for the multi-site corporation problem (a) out-of-band consent or (b) frames.

Can you help me (us) understand what you are trying to fix or improve, first? Thanks




David Singer
Multimedia and Software Standards, Apple Inc.