W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: Security Re: File IO...

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 07 May 2008 10:57:30 -0700
Message-ID: <4821ED8A.4060004@sicking.cc>
To: Charles McCathieNevile <chaals@opera.com>
CC: Maciej Stachowiak <mjs@apple.com>, "Web API WG (public)" <public-webapi@w3.org>

Charles McCathieNevile wrote:
> On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak <mjs@apple.com> 
> wrote:
>> On May 7, 2008, at 6:39 AM, Charles McCathieNevile wrote:
>>> Hi folks,
>>> Opera has a proposal for a specification that would revive (and 
>>> supersede)
>>> the file upload API that has been lingering so long as a work item.
>>> In a nutshell, it provides the ability for a web application to get a
>>> filespace, by asking the user to identify such a space, and making it
>>> available to that application something like a virtual file system.
>> I am concerned about the security implications of this proposal. File 
>> upload in HTML is based on the user explicitly selecting a particular 
>> file. This has relatively low security risk, since the user is 
>> choosing one specific file that he or she wishes to transmit, and all 
>> that can be done with that file is upload its bytes.
>> However, this API grants much more power than that.
> Yep. That's the idea.
>> Here are some of the more obvious security issues:
> [several obviously interesting things]
>> 6) Despite clearly having major security considerations, the document 
>> has no Security Considerations section.
> Indeed. (It also has no table of contents). There are obviously security 
> issues any time you give access to something like the filesystem. That 
> said, there are valuable use cases for access to the filesystem. The 
> idea of standardising this currently rough proposal is that we identify 
> and deal with those. An obvious approach would be to limit availability 
> of this to "trusted content" for some definition of that (and different 
> browsers currently have different definitions).
> As a work item we can happily raise the security issues and provide 
> guidance about what circumstances open what kinds of risk. Which is what 
> we would like to do, as part of making the functionality available to 
> application developers in some way.

For what it's worth Firefox has no concept of "trusted content".

That is, other than the code that makes up firefox itself, but that 
obviously doesn't need to use any standardized APIs.

/ Jonas
Received on Wednesday, 7 May 2008 17:59:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC