Re: Are we in agreement?

> On May 3, 2017, at 10:47 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> If there are subresources that a site or a parent subresource must have
> consent for as a unit, then they should not mind putting them all into an
> otherParties array.

They already put them into the arrayOfDOMStrings

> In could help this use case also because content
> blockers will eventually (hopefully) not block domains on it, or be
> configured by default that way.

I guess we are silent on the question of whether you issue the HTTP request at all; but we are clear that if you do, you match the granted exception.

> 
> 
> 
> 
> -----Original Message-----
> From: David Singer [mailto:singer@mac.com] 
> Sent: 03 May 2017 17:48
> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
> Cc: public-tracking@w3.org
> Subject: Re: Are we in agreement?
> 
> 
>> On May 3, 2017, at 1:34 , Matthias Schunter (Intel Corporation)
> <mts-std@schunter.org> wrote:
>> 
>> Hi David,
>> 
>> 
>> thanks a lot for your input! This is exactly the discussion I wanted to
>> trigger to ensure that we are all on the same page and potential
>> ambiguities of the spec are minimzed ;-)!
>> 
>> I double checked and Section 7 indicates that the user has the final say
>> and can edit/revoke/delete exceptions. My personal interpretation was
>> that this also means that I as a user can decide to partially honor an
>> exception by e.g. blacklisting a site.
> 
> explicitly disallowed in the current spec.:
> 
> "User-agents must handle each API request as a 'unit', granting and
> maintaining it in its entirety, or not at all. That means that a user agent
> must not indicate to a site that a request for targets {a, b, c} exists in
> the database, and later remove only one or two of {a, b, c} from its logical
> database of remembered grants. This assures sites that the set of sites they
> need for operational integrity is treated as a unit. Each separate call to
> an API is a separate unit."
> 
>> You make a valid point for an "all-or-nothing" approach to exceptions
>> which makes sense for publishers and is also easier to handle. Currently
>> IMHO the spec is not clear about this (since the user has the final say).
> 
> I beg to differ (quoting the sentence above).
> 
>> 
>> A consequence of this approach (to the other discussion threat) is that
>> there is no sense reporting back detailed subsets of sites that were
>> blocked: Either you complied with the site-wide exception or you did not.
>> 
>> IMHO both aspects should be aligned:
>> - If users can only choose all-or-nothing for a site-wide exception
>> - Then publishers should only get all-or-nothing feedback
>> 
>> 
>> Do others have a opinion to what extent a user is permitted to interfere
>> with exceptions? If it is all-or-nothing:
>> - You usually can no longer blacklist a third party globally
>> (I never want to be tracked by nasty-tracker.com)
>> - You cannot constrain a web-wide exception (e.g. facebook
>> is not allowed to track me on medical sites).
>> If you have those desires and exceptions are all-or-nothing, you need to
>> reject most exceptions to be honest to your publisher (even if they are
>> likely to be fine).
> 
> Dave Singer
> 
> singer@mac.com
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 3 May 2017 18:08:00 UTC