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
<adria...@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*
