Re: Concerns raised today for header design

On Jan 25, 2012, at 23:47 , Matthias Schunter wrote:

> Hi Folks,
> 
> enclosed are the concerns that were raised during today's roundtable.
> While they were raised while discussing Tom's proposal, they are
> viable input for the alternative version that is to be developed.
> 
> Matthias
> 
> ----------8<---
> 
> - Too complex:
>  a)   Providers were concerned that identifying and sending
>  the 'right' response code may create additional cost.
>  E.g., knowing whether you are a 1st or 3rd party may
>  occur extra cost even if what you are doing is
>  permissible in both cases (e.g., no tracking).

I honestly think the complexity of the response is roughly proportional to the complexity of the tracking you are doing.  If you do none, it's trivial. If you turn off on request, it's fairly easy, and so on.

>  b) Backend services may even be unable to discern the different
>  cases
> - URL to text:
>  A reason not to have an URL that was raised was
>  that the text at this URL may contradict the compliance
>  doc and may thus lead to confusion and/or legal inclarity
> - If a response depends on the request, then
>  this may require extra effort since responses can
>  no longer be statically defined
> - Cacheability":
>  A point raised was that cacheable objects do not need a header
>  since they cannot be used for tracking anyway.
>  Counterpoint here was that if a site is, e.g., 100% cacheable
>  and does not track, a user may still want to know that
>  the site knows and respects  DNT.
> - The current encodings may lead to misunderstanding
> - If the responses  do not correspond to request codes, then
>  this may lead to lead to legal uncertainty. E.g., if a user
>  says "do not track me" and a site says "exemption #3", it
>  is unclear whether this constitutes agreement or disagreement (Rigo)
> - If the responses are very specific, law enforcement gets easier.
>  E.g., I do not use cookies is easier to verify than "I comply with
> DNT": The former can be tested while the later may require to
> investigate all exceptions.
> - response headers need to be able to signal out-of-band/prior
>  consent that is an alternative to the the opt-back-in consent
>  colleciton mechanism (if the site is confident that it satisfies
>  the legal requirements).

I still have the concern that indexing the reason through the site, rather than our spec., makes it appear that sites can make up exceptions and explanations.  

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 26 January 2012 17:16:26 UTC