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

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

From: Adrian Bateman <adrianba@microsoft.com>
Date: Tue, 3 Nov 2009 18:30:04 +0000
To: "arun@mozilla.com" <arun@mozilla.com>
CC: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, "Web Applications Working Group WG" <public-webapps@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB0625366D@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Tuesday, November 03, 2009 10:07 AM, Arun Ranganathan wrote:
> Adrian Bateman wrote:
> > On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
> >> 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?

If you look through the bugs reported (and fixed) in the Firefox jar: scheme handler many of them revolve around mishandling origin. The file urn is obviously simpler and also currently refers to a file that the user had to select. However, in future this might be used as part of a larger API that allows certain web sites to access certain files/folders. A vulnerability might involve leaking the URN from one origin to another allowing a site to read a file it shouldn't have access to.

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

At first glance, I imagine filedata: would be easier for us to implement but I haven't researched this yet - I will ask the question. I wonder from a spec perspective whether reusing urn:uuid: might cause problems with this being overloaded for different uses in future.


Received on Tuesday, 3 November 2009 18:33:48 UTC

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