Re: explicit-explicit exception pairs

Hi Matthias,

Another point in favor of explicit / explicit is the possibility for 
publisher to be sure that third parties called from their website are 
known. There seems to be a market for auditing services that verify that 
no unexpected third party is called from a website (see 
http://www.krux.com/pro/whatwedo/control/data_sentry/ 
andhttp://www.krux.com/pro/whatwedo/case_studies/data_sentry_case_study_wsjdn/ 
). With site specific exceptions some publishers could crowd source that 
service. When a third party is denied an exception by most users, which 
could raise a flag on the publisher website (that could be a valuable 
feedback).

For the UI of explicit/explicit exception, I believe we could use a 
collusion-like view where each edge between a first party and a third 
party would represent a granted exception. Users would just have to 
click on the edge to deny (or grant) an exception.

Vincent


On 4/30/2012 3:55 PM, Matthias Schunter wrote:
> Hi Nick,
>
>
> I agree with your points.
>
> Two remarks:
> - While this is an UI issue, I would like to avoid adding features where
> we cannot perceive a useful/usable UI.
> - As an alternative to the Javascript API, we can also declare that
> sites MAY declare the third parties
>    used at their well-known URI.
>
> Two questions:
> - Why do you (and/or other members of the team) feel that this feature
> is important enough to
>    justify the added complexity?
> - Once we know and agree what shall be achieved, we may find other ways
> to achieve these objectives...
>
> Let's discuss this topic on Wednesday.
>
>
> Regards,
>   matthias
>
>
>
>
> On 30/04/2012 09:24, Nicholas Doty wrote:
>> On Apr 25, 2012, at 8:21 AM, Ian Fette (イアンフェッティ) wrote:
>>
>>> Also, I don't think we should just punt something by saying "It's a UI issue." The spec has implications on UI that should not be ignored. explicit/explicit means we have to come up with UI to support this, where so far we have failed, it means sites now have to worry about corner cases they didn't before, etc.
>> I agree with Rigo that this is a UI issue in the sense that user agent developers are completely free to decide whether or not to create what kind of UI they want. (We were able to discuss this confusion in DC, but only briefly, so I'll try to recap.) If Google Chrome decides that its users never want or need to see a list of domains, even when a site requests exceptions for a specific list, Chrome need not present any such UI; the browser can just display whatever UI the Chrome team creates for a site-wide exception and the team doesn't have to come up with any other UI. The browser also may choose not to store the list version of the permissions but just store a site-wide permission, or not to store the permission at all, the spec explicitly leaves all of these choices up to the user agent implementation. (Section 6.5 lists several other UI decisions that are also completely up to the user agent developer.) I expect user agent UIs to vary -- some browsers will use a simple built-in UI to avoid burdening their users; a developer of plugins for particularly privacy-conscious users might build a more complex configuration panel. Vive la différence.
>>
>> What are the corner cases that sites have to worry about that they didn't before? In the current self-regulatory opt-out cookie system the publishing site never gets an indication of whether one of its advertisers received an opt-out signal (unless it communicates on the server side) and the site may have a mix of advertisers that received opt-out cookies or not. Sites that only wish to ask for site-wide exceptions can always call requestSiteSpecificTrackingException with the "*" parameter; that some unrelated sites specify a list of origins in the parameter need not affect them. Of course, even sites that always use "*" may still receive visitors where some of their parties receive DNT:0 and others receive DNT:1, but that situation will exist whether the JavaScript API takes a list parameter or not.
>>
>> Hope this helps,
>> Nick
>>
>>
>