Re: changes to TPE before last call.

On Feb 5, 2014, at 7:42 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> Existing text:
> 
> 6.3.1 User Interaction
> 
> The call to store an exception MUST reflect the user's intention to grant an exception, at the time of the call. This intention MUST be determined by the site prior to each call to store an exception, at the time of the call. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the site making the call to determine that a call to record an exception reflects the user's informed consent at the time of the call.
> 
> changes to:
> 
> 6.3.1 User Interaction
> 
> The call to store an exception MUST reflect the user's intention to grant an exception. This intention MUST be determined by the data controllers of the site prior to the call to store an exception, and MUST reflect the data controller’s most recent understanding of the user’s intention. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the data controller of the site to determine that a call to record an exception reflects the user's informed consent at the time of the call.

Hi Mike

I don’t think this works.  In discussion in developing the exceptions, it became clear that we can’t leave it that ‘at some time in the past’ the user consented, as that would make it impossible for them to change their mind.  This was re-inforced when we went ‘no local user interface’ on exceptions; now the user-agent is not even expected to confirm with the user (though it may).

“Most recent understanding” has to be defined by the user, not the site.  If I take care not to ask you for several years, my most recent understanding is several years old.

Your text does not follow.  In the original text, if an exception is deleted, the site is required to re-ask the *user*.  In your text, they merely have to check their most recent understanding, so deleting an exception does NOT necessarily trigger the site to explain or ask for anything.

So, on the call today, this was presented as simple textual changes;  it is anything but, and is (in my opinion) functionally flawed.  In addition, I am not sure what this is fixing.  Perhaps you envisage that (for example) some Proctor & Gamble brand asks for an exception for all P&G brands, but (because of cross-site scripting rules) the exceptions for other brands cannot be registered until the user visits those sites, which may be (a lot) later.  I’m not sure how to deal with this in a simple way, alas.  How much later, for example?  If I agree to brand X, and then delete it, and then visit brand Y, brand Y will not know the history and will register an exception under your scheme, even though that is no longer what I want.  It has no visibility (cross-site scripting again) into the deletion of exception for brand X.

On the question of whether it applies to multiple sites under the same data controller, I am OK with looking into modifying the language to make it clear that you can register the exceptions that you ask for, and that request might span several sites under the same data controller.


> The second proposal is for an optional standard mechanism by which a controller can give users the ability to delete their tracking history. This would let them build user’s trust by offering a domain specific way to remove tracking history, e.g. to delete cookies or other identifiers in that particular domain. A simple anchor link in a privacy policy would be sufficient for a user to have their tracking data deleted, even if the policy document was addressed by a resource in a different domain (which is often the case for bigger sites).
> 
> Forget Property
> 
> An origin server MAY send a property named “forget” with a string value containing a URI reference to a resource which, when referenced in a request,  will cause personal data collected from the user-agent, other than that for a permitted use,  to be deleted. It is assumed that values in the cookie header (or in the request entity if a POST) are sufficient to identify the user-agent.
> 
> forget          = %x22 "forget" %x22
> forget-v        = string       ; URI-reference
> 

On this one, I incline to the view that this is a V2 feature.  Once data records have been created, propagated, archived, shared, acted on, and so on, it can be very hard to get rid of them, for a start.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 5 February 2014 22:11:11 UTC