RE: Are we in agreement?

Nobody is suggesting we change that. I suggested we add another parameter to
enable innovation, but that is another issue.

The otherParties array is not about who gets DNT, it is about communicating
information from responsible publishers so UAs can help protect their users
from malware, or having their personal data unlawfully processed. 

DNT is managed by the API.



-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 03 May 2017 19:07
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>;
public-tracking@w3.org
Subject: 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:54:04 UTC