- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Mon, 29 Jul 2013 00:14:31 +0100
- To: "'Shane Wiley'" <wileys@yahoo-inc.com>, "'Rigo Wenning'" <rigo@w3.org>, "'Chris Mejia'" <chris.mejia@iab.net>
- Cc: <public-tracking@w3.org>
- Message-ID: <000601ce8be8$37d591e0$a780b5a0$@baycloud.com>
Shane,
No, the idea is to store a wkn cookie in the first-party origin that gets
cloned site-specifically into its embedded third-party domain origins. The
cookie will stay there so it will be sent to the third-party in every
subsequent request when rendering the first-party page. The cookie is like
the "double-keyed" cookie that has been discussed in that it is only
inserted into requests to embedded third-parties when specific first-party
pages are rendered, but it is persistent.
This needs new UA code but it leverages the site-specific data store already
implemented to support the UGE API.
The first transaction to the third-party might miss the cookie (it depends
if it is a static or dynamic iframe, and when it gets rendered), but all
later ones will have it. If the detection code is run in the third-party
iframe it would need another turnround anyway.
Mike
From: Shane Wiley [mailto:wileys@yahoo-inc.com]
Sent: 28 July 2013 23:45
To: Mike O'Neill; 'Rigo Wenning'; 'Chris Mejia'
Cc: public-tracking@w3.org
Subject: RE: ISSUE-151 Re: Change proposal: new general principle for
permitted uses
Mike,
No easy way for 1st parties to easily communicate with 3rd parties as many
ads today are still served in iFrames and load in parallel with the main 1st
party page. So that option is off the table as it would require serializing
page loads which would significantly impact user experience in a negative
manner.
- Shane
From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
Sent: Sunday, July 28, 2013 3:26 PM
To: Shane Wiley; 'Rigo Wenning'; 'Chris Mejia'
Cc: public-tracking@w3.org
Subject: RE: ISSUE-151 Re: Change proposal: new general principle for
permitted uses
Shane,
Also if first-party script reads a null from the window.doNotTrack property
but the server is seeing a DNT header it could also signal its
third-parties. If the third-parties did this on their own (which would be
possible in this case) they would need an extra turnround to detect it
(using a horrible XHR or something). My method uses an immediately
detectable cookie. Again it might not be there on the first transaction but
after that it would be.
Mike
BTW IE11 has not implemented window.doNotTrack yet, unless it has a
different name - I cannot find it if it has.
From: Shane Wiley [mailto:wileys@yahoo-inc.com]
Sent: 28 July 2013 22:31
To: Mike O'Neill; Rigo Wenning; 'Chris Mejia'
Cc: public-tracking@w3.org
Subject: RE: ISSUE-151 Re: Change proposal: new general principle for
permitted uses
Mike,
Current implementations appear to alter the existing DNT header if there is
one so there are no contradictions:
"first-party page detects contradicting DNT signals"
- Shane
From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
Sent: Sunday, July 28, 2013 3:08 AM
To: Shane Wiley; Rigo Wenning; 'Chris Mejia'
Cc: public-tracking@w3.org
Subject: Re: ISSUE-151 Re: Change proposal: new general principle for
permitted uses
Shane,
My suggestion is an enhancement of Rigo's idea for checking if the UGE API
is present. The third-party advertiser just checking for the existence of
the API would work for say IE10 but not for IE11 intercepted by a
DNT-injecting router, proxy or other software component. It would also
require an extra turnaround as you point out.
The idea would be that script in the first-party page detects contradicting
DNT signals and causes this to be communicated to third-parties. The
publisher wants the advertising revenue so, if it detects DNT, will attempt
to get consent for its third-parties using a UGE. If a script library finds
that DNT is set (using window.doNotTrack) and a) The API is not present or
b) navigator.confirmSiteSpecificTrackingException returns false, it creates
a cookie e.g. W3CTP=DNT=I which is cloned into the third-party advertisers
domain. This cookie will always be placed by the library on every execution
of the library in that browser so does not need to be hardened, but
subsequent requests from the illicit browser to the third-party will contain
the cookie. There may be an edge case when it is not communicated in the
first request to the third-party, but this will be rare. Even in the IE10
case this is better because there is no need for the third-party to execute
JS and wait for the response in another transaction, the cookie will simply
be immediately present in the request header.
In general the W3CTP cookie could anyway be hardened to the same extent as
the DNT header, that is one of the reasons it has a well-known name.
Regarding the other proposal, I think cryptographically signing the DNT
header would be tricky because of the difficulties in keeping the encryption
key(s) secret so IMHO is a non-starter.
As an aside I have been testing the (illicit DNT) idea using IE11 but I
discovered that the only way to check for the existence of the API is to
execute a call and detect a thrown exception. So
confirmSiteSpecificTrackingException stores an "exception" if it is present
and throws an exception if it is not. This illustrates the confusion that
using the "exception" word is bound to cause.
Mike
From: Shane Wiley <wileys@yahoo-inc.com>
Date: Sat, 27 Jul 2013 22:24:46 +0000
To: Rigo Wenning <rigo@w3.org>, Chris Mejia <chris.mejia@iab.net>
CC: "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID:
<DCCF036E573F0142BD90964789F720E31410F9E5@GQ1-MB01-02.y.corp.yahoo.com>
Rigo,
So it appears we have several possible solutions emerging:
Solution 1: UGE Check
Desc - On each 3rd party call that receives a DNT:1 -
bounce a UGE check call to determine if the User Agent repeats with a
DNT:1
Pros - If a 3rd party software/network solution is
injecting the DNT signal, the UGE check will come back with a DNT:0
or DNT:<null>. The Server would honor the UGE check signal.
Cons - All 3rd party calls would universally need to
ping the UA before transmitting their call back to their
servers. This could be expensive from a timing perspective - especially in
an environment where we're already pressed for time. More
testing needed.
- Non-JS scenarios have no solution.
Solution 2: Signed/Keyed DNT
Desc - the DNT header signal would be signed against a
digital certificate
Pros - Removes the lazy non-compliant software
package/network appliance from the problem
- Is the same approach industry would likely
take if we discovered opt-out cookies were being
turned on by default without user interaction
- Depending on approach would likely work with
non-JS environments as well
Cons - Not sure how to handle cert signing in this case
in a manner that a 3rd party software
package or network device wouldn't be able to thwart in an easy manner
- No trusted intermediary to validate cert
through
- If effective, 3rd party software could move
to simply activating DNT:1 within the UA via a config
file or macro activation
Neither is a silver bullet but definitely worth further discussion. I
didn't list Mike's cookie option as I don't believe it's a fair starting
point to require validation through cookies which can be cleared in mass
whereas the DNT signal is more persistent. DNT validation should be on
parity with UA persistence.
- Shane
-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org]
Sent: Saturday, July 27, 2013 3:02 PM
To: Chris Mejia
Cc: Shane Wiley; public-tracking@w3.org
Subject: Re: ISSUE-151 Re: Change proposal: new general principle for
permitted uses
On Friday 26 July 2013 21:40:32 Chris Mejia wrote:
> Yes, W3C is responsible, it's your spec. See "DNT user agent vetting
> registry service" (above) for next steps on cleaning up the
> marketplace mess that's been created.
A registry is certainly another valid way forward. But many people still do
not understand what claiming conformity really means in DNT. And that is
part of a discussion we still have to have.
>
> You wrote "If you can't distinguish between a browser and a router, I
> wonder about the quality of all that tracking anyway."
>
> Rigo, this is why you are a lawyer, and not a technologist.
> Technically speaking, we are not talking about distinguishing between
> browsers and routers, we are are talking about distinguishing between
> validly set DNT signals and ones that aren't. You'd need to
> understand how HTTP header injection works to fully appreciate the
> technical problem. The best technologists on both sides of this debate
> have not been able to reconcile this issue. Neither have the lawyers.
The lawyers will tell you that you need a rule: "You shall not inject false
headers or transport false or injected headers". That doesn't buy you
anything either. I suggested to require the presence of the UGE testing bit.
In fact you can test already whether you have an exception.
That test can be used to determine whether the signal is valid.
>
> You wrote "I do not believe, given the dynamics of the Web and the
> Internet, that we can predict the percentage of DNT headers for the
> next 3 years; let alone the percentage of valid DNT headers."
>
[...]
> Please stop
> asserting that our technical and business concerns are trivial or ill
> informed-- they are not. Most of your replies below are not helping
> us get closer to a workable DNT solution-- you are only further
> exacerbating our concerns.
Chris, re-read my reply to Shane. He is having a creative semantics party by
claiming an "opt-in regime" I would rather be interested on a less
distorted technical discussion. Shane is only mildly reflecting the
solutions that the browser makers have considered viable, especially the UGE
testing bit. And even I earned a lot of criticism by insisting on a "D"
signal that allows you to say that you do not accept a signal. The elements
are there...
You're a technician, what would be your answer? A registry is not bad.
But most web-geeks hate registries. I suggested the UGE verification bit.
Perhaps not perfect, but viable. Is there a better solution? Shane suggested
that we could make the DNT-signal signed. This could be a fixed set of
elements so that you don't need a key to verify the signature but just the
same elements.
--Rigo
Received on Sunday, 28 July 2013 23:15:06 UTC