> We probably can't support a well-defined algorithm for detecting
> documents that have distinctive signatures while safely supporting
> formats that don't have them (because there is always a possibility
> that the non-structured format with user-controlled data could be used
> to forge a signature).

It can be argued that the burden of detecting this should be placed on
the server before sending out the response, but this would be a fairly
major shift in what is currently assumed to be the web security model
(with detrimental effect on tens of thousands of existing web apps);
on top of that, it would cripple some legitimate uses of the
non-structured formats: for example, there may be perfectly legitimate
reasons why a text/plain or text/csv document also matches a signature
for HTML.

In general, in the past, in pretty much every single instance where
browsers tried to second-guess Content-Type or Content-Disposition
headers - be it through sketchy proprietary content-sniffing
heuristics or through well-defined algorithms - this ended up creating
tons of hard-to-fix security problems and introduced new burdens for
web developers. It looks elegant, but it's almost always a huge

I think that most or all browsers are moving pretty firmly in the
other direction, enforcing C-T checking even in situations that
historically were off-limits (<script>, <style>, <object>, etc), based
on strong evidence of previous mishaps; to the extent that the spec
diverges from this, I suspect that it will be only a source of
confusion and incompatibility.


Reply via email to