W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [FileAPI] Latest Revision of Editor's Draft

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 03 Nov 2009 10:06:42 -0800
Message-ID: <4AF07132.4000404@mozilla.com>
To: Adrian Bateman <adrianba@microsoft.com>
CC: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Web Applications Working Group WG <public-webapps@w3.org>
Adrian Bateman wrote:
> On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
>   
>> On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
>> <adrianba@microsoft.com> wrote:
>>     
>>> On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
>>>       
>>>> But like Arun, I suspect that this feature is the most controversial
>>>> in the spec. Apple expressed concern about having a string represent
>>>> a
>>>> handle to a resource, and when we talked to Microsoft they briefly
>>>> mentioned that they has concerns about this feature too, though I
>>>> don't know specifically what their concerns were.
>>>>         
>>> The main concern I had was whether the URN feature was a must have
>>> for v1 given Arun's desire that this be the simplest spec that we could
>>> then build on later. Implementing a new protocol handler is more
>>> complex than just supporting the API part, for us anyway.
>>>
>>> I am also concerned about introducing new origin semantics - in the
>>> past this has been a source of security bugs and so I question whether
>>> we need to rush into this part (I accept the use case is valuable but
>>> I'm not sure it is initially essential).
>>>       
>> I'd really like to try to keep it in version 1. One of the use cases
>> we hear most often for this API is for uploading images. For example
>> to photo management sites like Flickr, but also for profile pictures
>> on sites like twitter. In both these cases it's possible to use
>> data-uris, but that will most likely result in the several copies of a
>> several-MB-sized data-uris living in memory. I think the situation
>> might be even worse in IE which if recall correctly there's some
>> fairly low limits on how big data-uris can be (is this correct?).
>>     
>
> There is a limit on the size of data-uris in IE8 (32K I think). I expect addressing this will be a higher priority than a new handler but I agree that copying around large strings is problematic.
>   

FWIW, the specification makes a provision for URL length limitations in 
certain user agents, so that a file (as a Data URL) that exceeds a 
URL-length limit will force an ENCODING_ERR when the readAsDataURL 
method is called on a FileReader object. 
>   
>> Are you concerned about security bugs in the feature design or in the
>> implementation?
>>     
>
> Mostly in the implementation - it increases the surface area to be concerned about and there might be a different approach.
>   

This feedback as a potential implementor is important :-)

1. Can you give us an example of an exploit, or expand on your concerns?

2. From an implementation perspective, do you care whether we define a 
scheme (such as filedata:) or reuse something like urn:uuid:[UUID] ? Are 
there any barriers with respect to either one?

> This isn't something I feel really strongly about. I imagine that when we look at implementing this we will start with just the API part and look at the URN handling separately.
>
>   

This is in fact pretty much the approach we have taken with Firefox 3.6 
(currently in beta).

-- A*
Received on Tuesday, 3 November 2009 18:07:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT