Re: action-249, action-316, action-168, tracking status qualifiers

On Nov 6, 2012, at 22:23 , "Roy T. Fielding" <fielding@gbiv.com> wrote:

>> 
>> A qualifier MUST only be used when the site conforms to the requirements in the compliance document, if appropriate, for that status.
> 
> A qualifier MUST NOT be used unless the site conforms …

better, thx

> 
>> Then one that is NOT a 'permission':
>> !    partial implementation, no compliance claimed
>> 
>> The partial implementation qualifier may be used to indicate that a given site does NOT claim compliance under this specification. It may be used when a site is in the process of engineering, verification, or other validation for compliance under this specification. Sites using this qualifier are explicitly non-compliant.
>> 
>> (It is a little more complicated then that, since we also need to update the sections where we say that the presence of a tracking status implies compliance.)
>>    http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0148.html
> 
> I do not believe this belongs in qualifiers.  The tracking status
> value is where compliance is indicated and I do not believe qualifiers
> will be implemented by anyone.  They do not belong in the header
> response, regardless.

Well, you originally proposed this as a TSV, I now realize, in <http://www.w3.org/mid/6FC18020-A426-4EE3-AE95-D52B1CF406AB@gbiv.com>.  The advantage is that as a qualifier, to my mind, one can say all the things one would have said when compliant, but tag with the extra "!" to say "but I am not there yet".  Replacing the main TSV obscures what status I was working towards.  E.g. compare

P   (not yet claiming compliance)
with
3s!   (third party claiming short-term storage permission, but not yet claiming compliance)

In the latter case, once the site believes it is compliant, it stops appending the "!" to its status values, and it's done.  In the former, it has to change the base value (and get it right).

Also, the second supplies more information -- the information that will be sent once compliance is claimed.

> 
>> Finally, 'service provider, to qualify either a '1', '3', or 'C' (1st or 3rd party, or 3rd party with consent)
>> p   service provider to the 1st or a 3rd party, or 3rd party receiving consent
>> 
>> (It has been suggested that 'service provider' should be a tracking status value, but I think it's better as a qualifier as it allows indicating the status of the party to whom service is provided.)  
> 
> I object to this being included in the specification without an
> indication of why it is needed.

That is the text below:  to *permit* sites that *wish to* to clarify why they claim, for example, consent or 1st party status, when the user might not otherwise think that they have that status.  If they don't want to clarify this, or don't need to, they don't have to.

I can see why you would object to this ever being required, but for the life of me I cannot see why you object to it being possible.

> 
>> Then, when to use the service provider qualifier (action-316):
>> 
>> (We need similar text for each qualifier; when is it valid, when recommended, and when - if ever - mandatory)
>> 
>> When a site operates under a formal service provision to another (it is a 'service provider'), the 'policy' link of the tracking status resource on the service provider site SHOULD refer to the policy on and of the site to which service is provided, which confirms that the same policy is in effect, and identifies the site to which service is provided.  
>> 
>> The "same-party" array allows a site that a user is expecting to interact with (the first party) to proactively declare other domains which, to the extent they are referenced by the site, share the same data controller and ought to be considered within the first party. This information might be used by a verifying user agent to
>> differentiate origin servers that have been declared by the site from any other (unlisted) origin servers referenced.
>> 
>> The service provider qualifier is never mandatory. However, it is recommended in cases where the service provider does not appear to be part of the same party as a party that operates under a status that allows tracking, such as a first party or a party with consent.  This reduces the possibility that the service provider will be mistaken as operating under, for example, first-party rules when it does not appear to enjoy first-party status.  (The service provider might appear not to be a part of such a permitted site because, for example, the hostnames do not share a non-public suffix.)
> 
> "recommended" is a synonym for SHOULD.  

OK, we should replace that word.

> And, no, it is not recommended.
> Service providers are not even remotely concerned about being mistaken
> for a third party while operating a service for the first party,

For those that don't care that the user might, for example, block them, because they appear to be 'rogues' claiming a status they don't enjoy, I don't care either.  I rather assume that some businesses might care.

> nor
> would an indicator help in such a use case because an evil third party
> would be the first to send "p" if it were helpful.  

Evil parties can claim not to be tracking in the first place.  I am not trying to impede the evil, but help the honest here.

> For accidental
> inclusion on web pages, the first-party indicator (via a new member
> or the policy link) is more useful to a verifying UA.

That is also useful.

> 
>> When the service provider qualifier is used, the Tracking Status Value MUST indicate the appropriate status for the party that this site is providing service to, e.g. '1', '3', or 'C'.
> 
> Redundant -- the same is true of all sites.

No, the service provider is not "the same party" as the party it is providing service to, and so this is not clear.  Stating it, at the very least, makes it clear.

> 
>> I believe that the correct indicator in section 6.7, action-168 (Rigo on providing service to a 3rd party) is '3p' or 'Cp' (depending on whether consent was given to the main party).
> 
> Likewise, service providers to third parties is irrelevant
> because they are restricted to the third party requirements (or
> restricted by the consent purposes) regardless of their ownership.


The particular concern is a service provider to a third party that received consent, I think.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 7 November 2012 14:21:28 UTC