RE: Transparency vs. Fingerprinting

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 <mailto:mts-std@schunter.org> >
To: public-tracking@w3.org <mailto: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 sending

publishers the information "all your third parties made it" or "not all

of 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 iff

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

 

For a few users (the geeks), the UA would return "your TPs did not make

it" while some made it. In reality, this could mean that the geeks end

up in the paywall even if they (worst case) only blocked a single TP

that was not even important.

 

Would you agree? If yes, we could make this "all or nothing" info a MUST

feature 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 not

obtain this information from each and every user.

 

Opinions/feedback/concerns?

 

Regards,

matthias

 

PS: In addition we should think about the information returned to

minimize fingerprinting risks. The corresponding Question: When to put a

given 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 not

listed in other-parties and -at the request of the publisher- was

blocked). Again a MAY function could enable publishers to debug with

some UAs while not requring this information from all users.