Re: Supporting TPE on sites/subdomains where a user does not have control of the server (ISSUE 15, ISSUE 10)

On Feb 4, 2017, at 1:26 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
> But the following points need to be considered:
> 
> 1)	With HTTP cookies alone a first-party site cannot obtain consent for
> sub-resource origins, i.e. transitive consent, because the SOP stops cookies
> being stored in unrelated origins. It could be done perhaps by elaborate
> dynamic insertion of iframes (for example) like the way transitive opt-out
> in AdChoices works now, but we know this is cumbersome, error prone and
> slow. Not having transitive consent has been claimed in last comments to be
> anti-competitive because it is easier for "first-party" companies like FB to
> do it than those without a first-party presence.

I would expect consent to be obtained by the first party site and indicated
via the request URI (not cookies) of third-party subrequests.  This might
be enforced by contract and regulatory rules.  Likewise, I would expect
first party content to be adjusted accordingly to ensure that only
pre-approved third parties are accessed in later subrequests.

Of course, none of that is easy.  But it's better than nothing.

> 2)	Site-specific consent is hard if not impossible to implement. Once a
> cookie is stored it will always be sent in requests even to the same
> subresources on different first-party sites (where the user did not give
> their consent). Site-specific consent is important because users can
> understand it and are far more likely to agree to publishers if they know
> tracking (by subresources) will be restricted to the site. Hardly anyone
> will freely give web-wide consent. They might be prepared to give consent in
> particular situations e.g. site-specific or restricted web-wide (which I
> mentioned recently) , but only if it is implemented in a way they can
> understand and trust.

Yep, can't be done with cookies.  But consent is granted according to
what the first party site presented to the user.  What matters is that
the user makes an informed and specific decision, not who received
that decision.  Hence, a site can ask a user for consent to use some
branded ad network, or adhere to some branded set of standard policies,
and then the site can use that consent to inform its partners of
their limitations. Eventually, users might be able to configure their
browser to automatically provide consent for sites that claim to
adhere to certain standard policies.

The only cookie stored would be for the first party site that asked for it.
That cookie would indicate the specific consent(s) given and some sort of
low entropy generation number (to indicate when consent needs to be
re-obtained due to a change in policies).  All sites would still receive
the DNT:1 signal, so a third party would look for DNT, the first party
cookie (in case the user already gave them web-wide consent), and any
passed consent via the request URI.  A third party can thereby limit
its tracking (if any) to the extent consented by the user even when
it is receiving DNT:1.

IOW, this still allows a tracking network to obtain web-wide consent
as a first party (perhaps in exchange for something valuable to the
user) and receive that consent cookie (or authentication info) in
later third-party requests.  Naturally, sites that act as both first
and third parties using the same cookie domains would have to be very
careful to check the consent is specific.

> 4)	Any approach needs to be transparent and verifiable. User agents and
> regulators/researchers need to clearly see that consent is claimed, if only
> because proof of consent is required in the GDPR. This means the (DNT)
> overriding cookie needs to have a "well-known" name, maybe a new Cookie
> prefix similar to those described in 
> https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-coo
> kie-prefixes.md

It is already transparent to the user agent (the one making the requests).
We don't have perfect transparency in the real world, so this relies on
trust and verifiability by regulators.  That's good enough.  After all,
the only way to get perfect transparency is to track 100% of requests.

> 5) 	A10 (also see R23)  of the EPR will mean that third-party cookie
> blocking will be more prevalent and probably more restrictive than now. At
> the moment cookies are blocked (e.g. Safari) from being stored in an
> embedded context, in future they will probably have to be blocked from being
> sent in that context. This will make it a lot more difficult to get
> transitive consent (it can maybe be done via link redirection but that
> loophole will probably be closed)

That would be seriously stupid.  All that would accomplish is to move
more of the Web behind walled gardens and gateways, where everyone is
tracked, all of the time, using permanent identifiers.

Not all tracking is bad.  Data retention is far more of an issue.
We just need to find a way for the various parties to communicate
their true intentions and let them come to agreement among themselves
on how to act in accordance to the user's expressed consent.

....Roy

Received on Monday, 6 February 2017 09:22:56 UTC