RE: Issue-187

Hi David,

 

My comments to your in-line comments, in-line.

 

- Mike

 

From: David Singer [mailto:singer@apple.com] 
Sent: 15 March 2013 23:41
To: Mike O'Neill
Cc: public-tracking@w3.org WG
Subject: Re: Issue-187

 

Hi Mike

 

I am not sure I understand all you are saying here, so, let's explore a bit.

 

 

On Mar 15, 2013, at 14:07 , Mike O'Neill <michael.oneill@baycloud.com>
wrote:





Another use-case for site specific DNT:1 came up at the Berlin Global
Considerations meeting, which will also be a common occurrence outside of
the EU. The current API for site-specific exceptions only allows for the
setting of DNT:0, or the registration of Tracking Consent, after a
first-party site has established it. A user may be able to remove this
exception, or revoke the consent for tracking, by using a user-agent
specific UI but this may not be present in their particular browser and the
form of the UI cannot be under the control or part of the user experience of
the first-party site.

 

As there is no way with the current API to specify an expires or max-age
qualifier and no way for a first-party site to programmatically revoke the
signal 

 

No, there is.  I designed it not so a specific request could be revoked, but
that a site could, at any time, ask for a 'clean out' reset back to a known
state.  A specific cancel seemed to me to be fragile; slight differences
between the setup request and the cancel might mean that 'nothing matched'
and 'nothing would get cancelled', whereas a 'please revoke everything, I
will set it up afresh' seems to enable the site to get back to where it
wants.

 

Well yes, I did forget the removeSiteSpecificTrackingException, but I think
the ability to specifically revoke consent for a subset of embedded
third-parties is important, and mirrors the corresponding capability for
registering consent. The consent mechanism we are defining needs to be as
flexible as possible in the choices it gives to data controllers who may
have contracts in place with some third-parties and not others. They may
also want to offer their users maximum granular control over data collection
by their embedded third-parties, or allow consent to be given to the
first-party but not the third-parties. This later point is important in
Europe because the first-party tracking alleviation would not apply.

 

If my second use-case is accepted then this would be a simple corollary to
it. 



we should extend the API so that script in the first-party domain origin an
existing DNT:0 signal can be reset to the general preference, allowing the
site to register in the user-agent that consent has been revoked. This would
be a minor increment to the work needed to implement a site-specific
exception and should be done for consistency, and to meet the requirements
of regulators at least in Europe.

 

The other use-case I previously pointed out was the ability for a
first-party site in the EU to signal its embedded third-parties, in the case
that the general preference is unset, that consent was required,  for
example because the first-party site or the user was in an EU jurisdiction,
but had not been obtained. This would require the site-specific API to
register DNT:1 so that the third-parties could take the correct course of
action even if the DNT general preference was unset.

 

Ah, this is for the case where the user has no preference set, but the site
is aware that its third parties need to get a DNT:1 because the site is EU
and it needs its third parties (who might serve sites from many
jurisdictions and might not be in the EU) to get an explicit DNT:1?

 

Yes, that was the use-case I mentioned in Boston, and I hope to talk about
on a future TPE call. If EU sites do not have this capability they may be
forced to remove third-party content where they do not have an explicit
agreement, or re-engineer their sites to conditionally edit out some
third-party content when users have not given consent to them.





 

The site specific API should have the ability, for the document origin and a
list of embedded third-parties (targets), to set the following :

.        Set DNT to 0

.        Set DNT to 1

.        Set DNT to the General Preference i.e. 0, 1, or unset

 

This could be done, for example, by supplying another DOMString member to
the StoreSiteSpecificExceptionPropertyBag dictionary, specifying either
"set-dnt-0", "set-dnt-1" or "revoke".

 

In the future we could add qualifiers to this such as ";Expires=Fri,
15-Mar-2013 21:47:38 GMT".

 

It would then be possible for script in the top-level origin to concatenate
calls to the API, for instance to set DNT:1 for a set of domains and DNT:0
for a subset of them. At the moment we do not have the ability to specify
wild-cards or regex expressions for the targets but we do have a rudimentary
way to do it by not supplying an arrayOfDomainStrings, equivalent to *.*. At
some point we should add regex or wild-card functionality to the definition
of arrayOfDomainStrings. 

 

We have resisted wild-cards here because of public-suffix and cross-site
issues.  Do we really need them?

 

This just refers to the embedded third-parties (in arrayOfDomainStrings) so
the cross-site issues do not apply because the DNT signal is only being
controlled within the context of the implicit top-level document origin.
The cross-site and public suffix issues only arise if we use the API to
register consent within other top-level domain origins, which I agree we
should avoid. 

 

This would also give sites the ability to identify embedded resources
differentiated by more than just the domain origin.

 

 

-Mike

 

 

 

David Singer

Multimedia and Software Standards, Apple Inc.