Re: [widgets] Content-Type Processing Model

On Tue, Feb 3, 2009 at 7:39 AM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>>> 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.

I'm happy to change that sentence.  How would you like sentence changed?

>>> 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.

I'd recommend the following:

1) Provide a mechanism for the widget author to specify a mime type
via some sort of metadata (analogous to the HTTP Content-Type header).

2) Use the magic number sniffing algorithm if authors don't specify a mime type.

Looking at the mime types in the widget spec, the only ones that
aren't readily identifiable using magic numbers are
application/javascript, text/css, and text/plain.  Those mime types
only matter if they are displayed in the main content area (e.g., the
<script> tag doesn't care about mime types).

For things like GIF and JPEG, the magic numbers have to be right
anyway or else the image won't display, so you're more likely to get
the right answer from the magic number than the file extension anyway.

The remaining interesting case is image/svg+xml, which we don't have
in the sniffing spec.  We can probably add it though, if that would be
helpful.

Adam

Received on Tuesday, 3 February 2009 18:23:33 UTC