RE: CFO Issue 22

David,

The same-party description is similar, lots of use of mays and mights on how the UA will deal with it. This is at least extensible (because it is an array of objects, and objects can have additional properties) and its meaning is clear - all the domains a controller is aware of that can appear as subresources, and are not same-party. If the browser supports the JS API the site can add to these with domains the user has given consent to, so anything that is not in same-party, other-party or arrayOfDomainStrings can be suspect if the UA is designed that way.

Mike

-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 13 June 2017 18:40
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: public-tracking@w3.org
Subject: Re: CFO Issue 22

Mike

unfortunately, a CfO works by accepting only one alternative; no compromise or editing. I raised these concerns in the debate, but for whatever reason, they were not addressed.  

Your answer below is full of ‘would’s and ‘could’s, which actually serves to make my point: the field, as specified now, is woefully under-specified. It strays so far into flexibility and away from anything normative (and hence standardized) that I can’t agree it strikes any kind of balance at all.



> On Jun 13, 2017, at 10:33 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> How the domains are allocated or categorised would often be a legally determined. A compliance document could describe this and another property (on the other-party object) could convey the category names. "other-party" refers to  domains, so there will always need to be a "domain" property, and there are several of them so it needs to be an array (of objects). Other properties (on the object) can convey further information, depending on the jurisdiction or the requirements of the site or service. 
> 
> I think this definition strikes a reasonable  balance between standardisation and flexibility. If we are allowed further time maybe others would agree to more detail?
> 
> -----Original Message-----
> From: singer@apple.com [mailto:singer@apple.com] 
> Sent: 13 June 2017 17:18
> To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
> Subject: Re: CFO Issue 22
> 
> I get that people would the tracking resource to say something useful about other parties, but I urge people to read the specification text proposed, and understand that it is so imprecise that it could contain a random list of sites. There’s nothing there that anyone can rely on.
> 
> As Roy says, if someone else is going to write a crisper, actionable, clarification, then that specification could simply supply the whole definition. Instead of writing “The other-parties field MUST contain [x] and MUST NOT contain [y]” they write “the well-known resource is extended with a field other-parties, which…”. There is no value derived from, and a lot of potential problems caused by, us under-defining a field: it would be ‘polluted’ in practice, with unusable values, and no one would be able to rely on it for anything.
> 
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 13 June 2017 19:17:55 UTC