Re: changes to TPE before last call.

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.

Received on Monday, 10 February 2014 23:49:39 UTC