Re: changes to TPE before last call.

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Yes the multi frame method works and there are other solutions, but that’s exactly my point. The existing text says that consent must be established immediately before *each* UGE API invocation, which would mean repeatedly asking the user for consent on requests for resources on different domain, and also separately for each protocol (http or https).

That’s not the intent of the ‘each’ in that phrase "prior to each call to store an exception, at the time of the call”.  You should be able to answer the question “for this call, did you get consent prior to it, at the time of the call?” with an affirmative.  If you ask “I’d like an exception for my wholly-owned domains A,B,C — OK?" and the frames from those domains proceed to register when the user says ‘yes’, you have what this text asks for.

I suppose we could word-smith it to make it clearer that it’s not insisting on a one-to-one correspondence between a call and the acquisition of consent, but is it really ambiguous?

Currently:

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


> That was the reason for specifying cookie rules for the "domain" dictionary property [6.4.1], but that does not help sites with  non-subdomain links. We allow info.yahoo.com but not yimg.com (or even yahoo.co.uk or https://info.yahoo.com), and this just does not reflect how big sites are built.
> 
> I am not asking to change the protocol, just to clarify the text which could be read as arbitrarily limiting when it can be used.

OK, let’s make sure it’s clear then.

> This is bound to come up after LC anyway.
> 
> Mike
> 
>> -----Original Message-----
>> From: David Singer [mailto:singer@apple.com]
>> Sent: 06 February 2014 19:52
>> To: Mike O'Neill
>> Cc: Shane M Wiley; Matthias Schunter (Intel Corporation); public-
>> tracking@w3.org (public-tracking@w3.org)
>> Subject: Re: changes to TPE before last call.
>> 
>> 
>> On Feb 6, 2014, at 4:54 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> 
>>> Hi David
>>> 
>>> I have changed my UGE proposal to reflect Shane's comment about the EU
>> legal term and in light of your comments.
>>> 
>>> The fundamental problem is the structural clash between the registration of
>> consent in servers and in user-agents. If one is changed the other needs to be
>> synchronised, and we can only do that in one direction under the current model.
>> I did suggest an idea for an extra  "consent token" parameter to the UGE API
>> back in Oct 2012 but that got side-lined when we went with server centric UGEs.
>> As you point out (in your reference to wrongly giving a UGE to Brand Y after the
>> intention has been revoked in the UA for Brand X)  the current model
>> unfortunately leaves an unhandled edge-case. I think this will need to be
>> revisited eventually, maybe in DNT 2.0.
>> 
>> The current model leaves it that the server has to ask just before registering the
>> exception; it can handle this case, for example, by framing content from each of
>> the brands, and having those frames register exceptions immediately on getting
>> consent.  The user then is only troubled once.  I am sure there are other
>> solutions.
>> 
>> So I am unconvinced there is a problem here, and very loath to open the door to
>> greater problems by relaxing the simultaneity requirement.
>> 
>> I’ll not comment on the text, as I am still not clear that we have a problem.
>> 
>>> 
>>> Anyway how about this, other suggestions welcome:
>>> 
>>> 6.3.1 User Interaction
>>> 
>>> The call to store an exception MUST reflect the user's intention to grant an
>> exception. This intention MUST have been determined by the site prior to the
>> call to store an exception, and MUST not override an exception that has been
>> granted  but later revoked. (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.
>>> 
>>> On proposal 2 I was mainly thinking that UA stored identifiers would be
>> deleted, i.e. persistent UID cookies, localStorage etc. This would at least make
>> sure that existing server based data was unlinked, and it would be up to
>> controllers whether to also delete that. This could avoid users  having to delete
>> all their web history data i.e. give users an option to delete identifiers in a site's
>> third-parties' domains.
>>> 
>>> I agree this will probably have to wait till  v2, but I wanted to at least introduce
>> the idea.
>>> 
>>> Mike
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: David Singer [mailto:singer@apple.com]
>>>> Sent: 05 February 2014 22:11
>>>> To: Mike O'Neill
>>>> Cc: Matthias Schunter (Intel Corporation); public-tracking@w3.org (public-
>>>> tracking@w3.org)
>>>> Subject: 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.
>>>> 
>>> 
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.13 (MingW32)
>>> Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/
>>> Charset: utf-8
>>> 
>>> 
>> iQEcBAEBAgAGBQJS84X5AAoJEHMxUy4uXm2JTgAIAIvMndKhBYRQWeIl5p3P0eE
>> f
>>> wU40RWg3415xapv9npcIBgZQzcZMhlr73msc27l+bTKVlA3aJYr/syMTlloy1jGz
>>> 
>> xAXOlme4bPShy5n/XS8KVB8w6QscW8QkuLsZSrfM1KbYxgZQlmSIr47RpAYC5m5h
>>> OdumLgC0s946P64cqn9lWxGDyuivPusceZJJzzgynIkcvL4W5VwRYaLiOXOpiTKY
>>> 
>> x62aVUqAVlyG8yRJC0u6KXxWSDyS1HpiMlDqLjaC1Dyac8vVcpjktNVG6d5gH0UT
>>> 
>> cpYUkvRPuc0zlfwlYHF7WGWOkP0SL14aWbkoqwBNHqVfj+/MGp2dTRwWGbcjb
>> W4=
>>> =dGSe
>>> -----END PGP SIGNATURE-----
>>> 
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (MingW32)
> Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/
> Charset: utf-8
> 
> iQEcBAEBAgAGBQJS8/dWAAoJEHMxUy4uXm2JpFYH/0Pu6EV3V4U7y4PBhdFVYu9Y
> 8fRf7f7XB3RC22e1FcFua5lhUfjmNhKe7rXBZXOQ1yj4m2QiFDOsqBirJlvfyXrz
> M2R8hitECBJP1xBABs2K3LlJkP6IdpoNSa3Op90ortuBOZLOZ7Z18IOeVnNsKv21
> RLwkjeV4nYj46QsuAF/iEUby/Y9ULcdVyFl7TXg06JsAS1/5STcfgy4Qi4GO5eeh
> DbA/vMBctnhlx9Q2uVIuRIgPsPOE5JCVAVd3emdcXg/M93sjSjNwEOfEBSyQOJyY
> MHY6P6cw+2M7Tl6vL83L31cimwOSVLDtyaGhTEsgkKVejDgJ5yu04vpFMADtLSA=
> =grK6
> -----END PGP SIGNATURE-----
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 6 February 2014 22:20:11 UTC