- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Tue, 2 May 2017 21:01:15 +0000 (UTC)
- To: Mike O'Neill <michael.oneill@baycloud.com>, "'Matthias Schunter (Intel Corporation)'" <mts-std@schunter.org>, "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <2073403102.1099688.1493758875432@mail.yahoo.com>
Mike, As a general tool it would be great to see a list of all 3rd party resources on a page but, yes, for the DNT specific use case receiving a list of those domains that were blocked would be the key information needed to branch activities from that point forward. I'm not as strong on the TSR as if required we could go the WKL for each domain to pull information. Most RTB occurs S2S (server-to-server) so the auction and bid will occur prior to the attempt to deliver the ad. If the delivery fails it would be helpful to the exchange to know this occurred but it may not longer technically be a position to see this as typically the link to the ad creative is returned and that is the end of the ad exchange's visibility into the process (unless they are the holder of the ad creative which isn't very often). - Shane Shane Wiley VP, Privacy Yahoo From: Mike O'Neill <michael.oneill@baycloud.com> To: 'Shane Wiley' <wileys@yahoo-inc.com>; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; public-tracking@w3.org Sent: Tuesday, May 2, 2017 10:13 AM Subject: RE: Transparency vs. Fingerprinting #yiv1329195006 #yiv1329195006 -- _filtered #yiv1329195006 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv1329195006 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv1329195006 {panose-1:0 0 0 0 0 0 0 0 0 0;}#yiv1329195006 #yiv1329195006 p.yiv1329195006MsoNormal, #yiv1329195006 li.yiv1329195006MsoNormal, #yiv1329195006 div.yiv1329195006MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv1329195006 a:link, #yiv1329195006 span.yiv1329195006MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv1329195006 a:visited, #yiv1329195006 span.yiv1329195006MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv1329195006 p.yiv1329195006msonormal0, #yiv1329195006 li.yiv1329195006msonormal0, #yiv1329195006 div.yiv1329195006msonormal0 {margin-right:0cm;margin-left:0cm;font-size:12.0pt;}#yiv1329195006 span.yiv1329195006EmailStyle19 {color:windowtext;}#yiv1329195006 .yiv1329195006MsoChpDefault {font-size:10.0pt;} _filtered #yiv1329195006 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv1329195006 div.yiv1329195006WordSection1 {}#yiv1329195006 Hi Shane, Just so I understand, you only want to know what domains were blocked, you do not need the DNT header that was/would have been sent, right? I assume you would like the TSRs to be there. They would already be parsed so there is not much point in having to go get them again server-server. The TSR, if it was generated dynamically, might betray whether the DNT header was set or not, but that could never be relied upon (by bad guys that wanted to fingerprint). What about ad exchanges, would they want to know what descendant subresources were blocked? i.e. are we only talking about the top-level browsing context? Thanks, Mike From: Shane Wiley [mailto:wileys@yahoo-inc.com] Sent: 02 May 2017 17:18 To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; public-tracking@w3.org Subject: Re: Transparency vs. Fingerprinting Matthias, I respect your (overly?) conservative stance on fingerprinting concerns. I believe if we're able to provide domain level lists that publishers will likely go with the path of least resistance and not allow those parties to serve ads or other elements on the page - versus requesting a full consent from the user again. Due to all the dynamics we've discussed (coarseness of any fingerprint threat, balance in transparency to the publisher, and ultimately a better user experience) I'd suggest we go forward with providing the full top-level domain list to the publisher for allowed/blocked 3rd party domains. - Shane Shane Wiley VP, Privacy Yahoo From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org> To: public-tracking@w3.org Sent: Monday, May 1, 2017 11:58 PM Subject: Re: Transparency vs. Fingerprinting Hi Shane, thanks a lot for the input. I agree that most users will usually allow/disallow all third parties. However, one could turn this argument around and argue that sendingpublishers the information "all your third parties made it" or "not allof your third parties made it" would be sufficient in this scenario:For most users (the all or nothing guys), the information would be correct. The "not all your third parties made it" information would be sent iff1. A valid site-wide exception for this third party existed (either "*" or a specific site-wide pattern that covered this TP)2. The page actually tried to load the third party and it was either not loaded or did not receive a DNT;0 For a few users (the geeks), the UA would return "your TPs did not makeit" while some made it. In reality, this could mean that the geeks endup in the paywall even if they (worst case) only blocked a single TPthat was not even important. Would you agree? If yes, we could make this "all or nothing" info a MUSTfeature and declare the detailed debugging API an optional (MAY)feature. I agree that the full information is useful also for debugging(also for the publisher-triggered blocking); however, you need notobtain this information from each and every user. Opinions/feedback/concerns? Regards,matthias PS: In addition we should think about the information returned tominimize fingerprinting risks. The corresponding Question: When to put agiven TP into the list that is returned to the publisher? Same Conditions:1. A valid site-wide exception for this third party existed (either "*" or a specific site-wide pattern that covered this TP)2. The page actually tried to load the third party and it was either not loaded or did not receive a DNT;0 PPS: Second Question: If a TP was blocked on behalf of the publisher,should the publisher be notified anyway (i.e. a TP occured that was notlisted in other-parties and -at the request of the publisher- wasblocked). Again a MAY function could enable publishers to debug withsome UAs while not requring this information from all users.
Received on Tuesday, 2 May 2017 21:01:51 UTC