- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 May 2010 15:11:57 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, ietf-http-wg@w3.org, public-html@w3.org, www-tag@w3.org
On 19.05.2010 14:05, Mark Nottingham wrote: > ... > My reaction to reading that is that these requirements are so watered down as to be meaningless; they require implementers to make very subjective judgement calls based on evidence of errors and security exposure, with almost no guidelines. > > Would the TAG be satisfied if this were rewritten in advisory language (i.e., without RFC2119 keywords)? > > E.g., keep the first two paragraphs, but change the third to > > """ > There are two risks of such 'sniffing.' First, the sniffed type may not be > that of the actual document, preventing the server from having their > intent honoured. For example, a simplistic HTML sniffing algorithm might > be fooled by a text/plain document containing the word 'HTML' near its top. > > Secondly, sniffing exposes implementations to security escalations. For > example, if a server sets a content-type of an uploaded file to text/plain, > but a client sniffs it as text/html, an attacker might take advantage of > this to mount a cross-site scripting attack. > """ +1 Sounds good. Maybe the first of these two should also mention that there are use cases where text/plain is chosen because the intent *is* to display the HTML as plain text, and not render it. >> 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. > > This will make almost all current implementations non-conformant, and I don't have much confidence that they'll become conformant to this requirement any time soon (implementers, I'd love to be proven wrong here). I don't think that adding a SHOULD here (compared to RFC 2616) will have any effect on implementations in practice. Let's rephrase it as advice. > Also, any thoughts about putting this in Security Considerations instead? +1 to moving it there. Best regards, Julian
Received on Wednesday, 19 May 2010 14:12:46 UTC