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

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.

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

Cheers,

Adrian.

Received on Tuesday, 3 November 2009 17:23:36 UTC