Concerns raised today for header design

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

Received on Wednesday, 25 January 2012 22:48:36 UTC