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

Re: Meaning of the term "optional" in the TPE spec

From: Nicholas Doty <npdoty@w3.org>
Date: Thu, 13 Sep 2012 18:37:56 -0700
Cc: <mts-std@schunter.org>, "'Roy T. Fielding'" <fielding@gbiv.com>, <public-tracking@w3.org>
Message-Id: <85703487-FAAF-4BA0-BB59-8082048D3864@w3.org>
To: Mike O'Neill <michael.oneill@baycloud.com>
Hi Mike,

Thanks for the note, but I'm not sure I understand this case yet. If a site uses client-side means to obtain consent (which, by the way, if it did with the JS exceptions API it wouldn't require these response values anyway), the script at some point will still initiate an HTTP request when it calls back to the server with information -- I would think that HTTP response would be an appropriate time to send a Tk:U header, and/or that subsequent responses (which would also presumably have the user's consent) can include a Tk:C header. Could there be a case where the server is retaining data related to a request based on the user's consent but wouldn't know that it had consent and would be unable to signal that to the user in its response?


On Sep 13, 2012, at 5:48 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:

> There are existing use cases where it would be difficult or impossible to
> dynamically insert a C status (or U status) in a TK response header. There
> are many implementations in Europe where consent is ascertained by client
> side script (perhaps acted on by deleting cookies and/or localStorage when
> it is not given). Client side script cannot change the response headers (and
> it may not be possible to signal the server to do it). If you email me
> off-list I can point you at some of them. Why not allow a JS API to indicate
> OOB consent?
> Mike
> -----Original Message-----
> From: mts-std@schunter.org [mailto:mts-std@schunter.org] 
> Sent: 13 September 2012 17:58
> To: Roy T. Fielding
> Cc: Matthias Schunter; public-tracking@w3.org
> Subject: Re: Meaning of the term "optional" in the TPE spec
> Hi Roy,
> thanks for the clarification. It shows that you are a standards veteran and
> it is great to have you on board!
> For the rest of us, we need to double-check that there are no objections to
> the fact that optional fields are purely optional, i.e., the only member of
> the well-known resource that all sites MUST declare is the tracking status.
> Sites can then freely choose whether they want to provide additional
> transparency by adding information through the other fields:
>                same-party
>                third-party
>                audit
>                policy
>                *( vs extension )
> Only for the "control" field, the spec mandates that a site SHOULD populate
> it iff it uses out of band consent ("c").
> Opinions?
> Regards,
> matthias
> However, the current spec does not mandate this additional transparency.
>> On Sep 10, 2012, at 1:19 PM, Matthias Schunter wrote:
>>> another potential clarification that we discovered is that we as a 
>>> group need to validate that we agree when the TPE spec uses the term 
>>> OPTIONAL (defined by RFC2119 as fields/features that are completely 
>>> optional, i.e., servers and user agents can freely choose to 
>>> implement them or not).
>> The spec should already do that.  If a field is optional except under 
>> certain circumstances, then it should say that.  The fields that are 
>> purely optional do not have any dependent requirements yet.  If there 
>> is a mistake in the drafting, please note it as a bug.
>>> I believe that this is the right meaning for some of the fields in 
>>> the TPE spec. An example is the extensions to the DNT header or the 
>>> third-party field of the tracking status resource.
>>> However, we need to double-check that all fields that are declared 
>>> OPTIONAL are never needed for any critical use case.
>>> If we are honest to ourselves, we should usually only claim that our 
>>> spec implements a use case iff this use case does not depend on such 
>>> optional fields.
>> Yes, nobody has claimed otherwise.
>>> fyi:  for the fields of the tracking status resource, I believe the 
>>> following to be true:
>>> - we agreed that the third-party fields is truly optional (sites can 
>>> freely choose whether they may or may not declare third-parties)
>>> - for the "same-party" field, this is less clear. Without this field, 
>>> user agents may be confused if multiple sites say "intended for 1st 
>>> party use" without declaring each other to be part of the same party.
>> What do you mean by "it isn't clear"?  Right now, same-party is not 
>> required under any circumstances.  I think that's pretty clear.  The 
>> only reason it was proposed as optional is because it is an 
>> implementation burden on first party sites.
>> In order to make it required, somebody in the WG (which includes the 
>> draft authors) needs to propose that it be required. Since nobody has 
>> done that yet, AFAIK, it isn't required.
>> Are you making that proposal?  If so, please just do so and let the WG 
>> discuss.  If there are no objections, it goes in.  If there are 
>> objections, we make a call for consensus and the the chairs decide.
>>> Did we overlook spec language that contains these requirements? If 
>>> not, how would you clarify this issue?
>> I did not overlook it.  We simply haven't made it a requirement yet.
>>> Should we go through the fields one-by-one and discuss which fields 
>>> should not be completely optional?
>> I would hope that people are doing that while reviewing the document.
>> ....Roy
Received on Friday, 14 September 2012 01:38:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:00 UTC