Re: [widgets] Content-Type Processing Model

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