RE: changes to TPE before last call.

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. 

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.

What is wrong with my latest text. Here it is again:

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.



I think it would also help implementers (using the multi-iframe method) if
we added text to 6.4.1 pointing out that a child frame can register
exceptions on its own behalf, i.e. that the inferred top-level origin may
differ from the top-level origin in effect when the call is made. 

Something like:

This function can be called in the context of a child frame of the top-level
origin document and would then result in an exception being granted on
behalf of the document origin of the child frame, or one of its subdomains.
This exception would take effect whenever a site with the child-frame's
document origin was accessed. 

Mike

> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 06 February 2014 22:19
> 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 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/0Pu6EV3V4U7y4PBhdFVYu
> 9Y
> > 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 Friday, 7 February 2014 02:11:31 UTC