W3C home > Mailing lists > Public > public-tracking@w3.org > November 2012

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 6 Nov 2012 16:23:09 -0500
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Message-Id: <22FA11BD-F371-4EE0-9B1F-FD04E7C03EE0@gbiv.com>
To: David Singer <singer@apple.com>
On Nov 6, 2012, at 9:48 AM, David Singer wrote:

> (with some help from Roy, who is nonetheless blameless as I am not sure we reached complete consensus)
> 
> 
> First, action-249, align with compliance:
> 
> Currently the qualifiers are:
> 
> a	Audit: Tracking is limited to that necessary for an external audit of the service context and the data collected is minimized accordingly.
> c	Ad frequency capping: Tracking is limited to frequency capping and the data collected is minimized accordingly.
> f	Fraud prevention: Tracking is limited to that necessary for preventing or investigating fraudulent behavior and security violations; 
>        the data collected is minimized accordingly.
> l	Local constraints: Tracking is limited to what is required by local law, rule, or regulation and the data collected is minimized accordingly.
> r	Referrals: Tracking is limited to collecting referral information and the data collected is minimized accordingly.
> 
> but I am instructed to align with the compliance document, plus one or two
> 
> So, looking at compliance, I suggest:
> 
> s   short-term data-retention
> c   frequency capping
> a   auditing and financial logging
> f    security and fraud prevention
> 
> These two don't seem to affect the amount of tracking going on, so I am not sure that they need qualifiers. Then, maybe they don't need permissions either:
>     contextual content
>     content based on data collected as a 1st party
> 
> 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 ...

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

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

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

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

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

....Roy
Received on Tuesday, 6 November 2012 21:23:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:38 UTC