RE: changes to TPE before last call.

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

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

Received on Thursday, 6 February 2014 12:55:15 UTC