-------- 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.