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 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC