(unknown charset) Re: Concerns raised today for header design

Hi Ed/Dave,

Eds point was right: This was yesterday's list of concerns ;-)

Today when designing the response header proposal we emphasized that
the site should communicate how its intended use is "this resource is
intended for use as a 1st party" (and follows the guidance for 1st
parties as put forward in the compliance doc).

The site cannot tell whether it is 1st of 3rd party (e.g., being
embedded without your knowledge).

However, if a site says "I do not track" then embedding is safe while
it might be unsafe if the resource says ""this resource is intended
for use as a 1st party" .


Regards,
matthias

On 1/26/2012 6:15 PM, David Singer wrote:
> 
> 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:55:26 UTC