Subject: [websec] scope of mimesniff: roles vs. contexts vs. delivery channels

From: Larry Masinter <[email-masked]>
Date: Wed, 11 Jan 2012 10:36:37 -0800

Going back to the "scope" question, should the mimesniff document cover sniffing in contexts other than browsers, e.g., by web servers during file upload, by proxies or firewalls or gateways, by spiders or search engines, etc.?

Within the browser context, does it cover sniffing in special applications like font, video, style sheet, script contexts, where more is known about the type that is wanted?

The dimension of 'roles' is somewhat orthogonal to the dimension we were talking about previously (whether the specification should cover sniffing of content delivered by means other than HTTP.

It seemed that the sentiment previously was to cover a broad scope of delivery channels: sniffing should cover the broad scope of sniffing of content delivered by FTP or through (mounted) file system access, etc., and that the intent was also to cover a broad scope of contexts (including font, video, style sheet, etc.).   

But what about the other roles? I think we could address them at least to some degree, if only to lay out what the constraints are, or what, say, a firewall should do (scanning content in a firewall should likely scan the data as it might appear in the likely formats that any recipient might interpret the data, for example.)

Larry
--
http://larry.masinter.net

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 11 Jan 2012 22:29:36 +0100

* Larry Masinter wrote:
>Going back to the "scope" question, should the mimesniff document cover
>sniffing in contexts other than browsers, e.g., by web servers during
>file upload, by proxies or firewalls or gateways, by spiders or search
>engines, etc.?

I note that the current draft does not seem to address web browser up-
loads (if a browser uploads a GIF as image/jpeg, and the server echoes
data and label back verbatim, and then the browser treats that as a GIF
even though it just said it's a JPEG, that would seem to be bad), but 
more generally I would rather have a "web browser only" specification
soon and then talk about what other components might be relevant and
how to address those, than try and address all of it at once.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 12 Jan 2012 12:11:31 +0800

<hat="individual">

Personally I believe we should include in the scope the possibility of 
other sniffing contexts (web servers, uploads, filesystem, ....) and 
actually would feel that this should not add a significant burden on the 
document.

However, if it does add a significant burden/delay on the document I 
would agree with Bjoern, that rather have a web browser document now 
than getting stuck discussing the other scenarios.
So give it a shot, but if you see too much controversy, reduce the scope.
(Thinking about human behaviour: In the end I believe even if we go only 
with web browser context, if other channels sniff, they will most 
certainly copy the web browser behaviour anyway - no matter what we say 
in the RFC.)

Best regards, Tobias

On 12/01/12 02:36, Larry Masinter wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec