W3C home > Mailing lists > Public > public-tracking@w3.org > February 2014

Re: changes to TPE before last call.

From: David Singer <singer@apple.com>
Date: Thu, 06 Feb 2014 11:51:48 -0800
Cc: Shane M Wiley <wileys@yahoo-inc.com>, "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-id: <64B5491C-FB5C-423B-883E-92A8315C1B9B@apple.com>
To: Mike O'Neill <michael.oneill@baycloud.com>

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
> 
> iQEcBAEBAgAGBQJS84X5AAoJEHMxUy4uXm2JTgAIAIvMndKhBYRQWeIl5p3P0eEf
> wU40RWg3415xapv9npcIBgZQzcZMhlr73msc27l+bTKVlA3aJYr/syMTlloy1jGz
> xAXOlme4bPShy5n/XS8KVB8w6QscW8QkuLsZSrfM1KbYxgZQlmSIr47RpAYC5m5h
> OdumLgC0s946P64cqn9lWxGDyuivPusceZJJzzgynIkcvL4W5VwRYaLiOXOpiTKY
> x62aVUqAVlyG8yRJC0u6KXxWSDyS1HpiMlDqLjaC1Dyac8vVcpjktNVG6d5gH0UT
> cpYUkvRPuc0zlfwlYHF7WGWOkP0SL14aWbkoqwBNHqVfj+/MGp2dTRwWGbcjbW4=
> =dGSe
> -----END PGP SIGNATURE-----
> 

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 6 February 2014 19:52:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:40:07 UTC