Re: TAG requests addition to section 3.2.1 of Part 3 [#155]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Nottingham writes:

> As you may know, the WG has already extensively discussed Content
> Sniffing, in
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155>, and we
> thought we were in a position to consider the issue closed.

Indeed we are aware of that.

> The discussions leading up to the current text were voluminous
> (search the mail archives for messages with a subject including
> "155" and/or "sniff"), so while we can certainly talk about adding
> more, I'm reluctant to do so unless we get good review. In
> particular, has the TAG coordinated this proposal with the HTML5 WG?

Sorry to be slow in replying, and we certainly understand that
re-opening closed issues is not to be requested lightly, but the TAG
is very concerned about the security and architectural implications of
the current draft, and feels that it is important that these are
called out.

Please note that we are _not_ asking you to reference any other
discussion of sniffing.  Nor do we challenge the basic thrust of this
section, which leaves the final decision about sniffing outside your
spec.  In particular we do not believe the proposed changes are
inconsistent with anything the HTML5 spec. currently says or the HTML
WG intends.

What we are asking is that the spec. not be silent about the _risks_
of sniffing, or of what it really means.

I've included public-html to this discussion, per your request, and
repeated the suggested amendment below for their information.

ht, by and on behalf of the TAG (ref ACTION-370)
========
Suggested addition to the end of section 3.2.1 of Part 3 of HTTP bis [1]:

  If the Content-Type header field _is_ present, a receipient which
  interprets the underlying data in a way inconsistent with the
  specified media type risks drawing incorrect conclusions.

  In practice, however, currently-deployed servers sometime provide a
  Content-Type header which does not correctly identify the content
  sent, with the result that some classes of recipients have adopted a
  policy of examining the content and overriding the specified type.

  Such 'sniffing' SHOULD NOT be done unless there is evidence that the
  specified media type is in error (for example, because it is
  'text/plain' but there are bytes in the data which are not legal for
  the specified or defaulted charset).  In any case recipients SHOULD
  NOT override the specified type if the change would significantly
  increase the security exposure ('privilege escalation').

  Deploying any heuristic for detecting mistaken Content-Types risks
  overriding user intentions and misrepresenting data---accordingly
  recipients SHOULD provide for users to disable sniffing in general
  and/or in particular cases.
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFLpntvkjnJixAXWBoRAvC8AJ4nZO9x3fFkG0A2UoKiT9F1Y0F5NgCbBZnE
ZppJf+ZDxucq8t6uYK7kiyk=
=k3yq
-----END PGP SIGNATURE-----

Received on Sunday, 21 March 2010 20:03:35 UTC