Re: Are we in agreement?

Mike,
Disagree as links to those resources may change on a dynamic basis and therefore human readable approaches will work whereas machine readable lists may not.  
If this entire conversation is going to circle back on automated blocking for browsers on mandated lists let's drop it as this is Tracking Protection Lists all over again which the group agreed to move beyond.
- Shane Shane Wiley
VP, Privacy
Yahoo

      From: Mike O'Neill <michael.oneill@baycloud.com>
 To: 'David Singer' <singer@mac.com>; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org> 
Cc: public-tracking@w3.org
 Sent: Wednesday, May 3, 2017 10:49 AM
 Subject: RE: Are we in agreement?
   
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. 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.




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