- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Tue, 3 Feb 2009 15:39:10 +0000
- To: Adam Barth <w3c@adambarth.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-webapps <public-webapps@w3.org>
Hi Adam, On Fri, Jan 30, 2009 at 6:51 PM, Adam Barth <w3c@adambarth.com> wrote: > Hi Marcos, > > On Fri, Jan 30, 2009 at 8:17 AM, Marcos Caceres > <marcosscaceres@gmail.com> wrote: >> As our Widget packaging >> spec [2] has some dependency on content sniffing, we would like to >> contribute to this specification where possible. > > Great! Currently, the draft is optimized for resources retrieved over > HTTP. In particular, it balances the concerns of compatibility with > existing web content with the security risks posed by servers that let > users upload content. It seems like widgets have neither of those > constraints, so the draft might not be optimized exactly for your use > case. Right. >> Particularly, we >> would like to make sure that sniffing and appropriate MIME mappings >> are made when resources are read from local storage. > > Forgive my ignorance of widgets, but what is local storage? Sorry, I realize now that that was a dumb term to use. I meant directly from the file system or not from something that communicates over HTTP or knows anything about MIME. >> At the moment, [1] reads: >> >> " For resources fetched from the file system, user agents should use >> platform-specific conventions, e.g. operating system extension/type >> mappings." >> >> We are concerned that operating system extension/type mappings might >> cause issues for widget engines because those mapping could be >> incorrect, or come from arbitrary sources etc. > > We have the above text so that users that point their browsers at > their own file systems get types that are consistent with the types > they get by looking at the files in Windows Explorer or the Finder, > etc. I wouldn't think that widgets would trigger this clause, just as > HTTP resources fetched from a disk cache don't trigger it. As some widget engines work with file:// so there is a risk that the above is happening. We explicitly want to avoid that from happening. However, I understand if that not a concern for your specification. >> So we are looking to >> collaborate to resolve this issue and wondering if that can be >> standardized as part of [1]. Our current approach in [2] has been to >> provide a table with a bunch of file extension to MIME mappings. > > Why is the magic number approach insufficient? Personally, I don't know :) Coupling explicit extension to MIME mapping with magic numbers as a fallback seemed like a reasonable solution to me. However, some people keep getting paranoid about the current solution in the widget spec. This is why I thought we would work with you guys on this as you have more experience and understand the security problem better. However, I also understand that this might just be something that widget specs need to deal with on their own. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 3 February 2009 15:39:52 UTC