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

Re: Security Re: File IO...

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 7 May 2008 12:57:25 -0700
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <690DA189-2491-4CAA-805A-08E7ED37475E@apple.com>
To: Charles McCathieNevile <chaals@opera.com>

Hey Chaals,

On May 7, 2008, at 10:39 AM, Charles McCathieNevile wrote:

> On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak  
> <mjs@apple.com> wrote:
> 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).

Before I follow up, can you clarify whether this API is intended to be  
exposed to general Web content, or only to special local "trusted"  
content such as widgets? I briefly discussed the spec on IRC with Anne  
van Kesteren and Arve Bersvendson (who said he was the author of the  
proposal). They both said that this proposal was only meant for things  
like widgets, and agreed with my assessment that it would be a giant  
security hole if exposed to web content.

On the other hand, the way you presented the proposal sounded to me  
like it was intended for general Web content, including content served  
over HTTP. The proposal itself says, "This document describes an  
interface for an abstract File I/O interface where web applications  
can interact with a file system, without any prior knowledge about the  
underlying filesystem." And you suggested that it could replace the  
File Upload deliverable, which I believe was targeted at general Web  

Can you please clarify which is intended?

My security comments were all based on an assumption that this  
proposal is meant for general Web content. I believe the proposal is  
not even an adequate starting point for an API exposed to the Web.  
Designing a filesystem API without concern for security is easy, and  
pretty much the only hard part is figuring out how to fit it into the  
Web security model. As such, I do not think it is particularly helpful  
to throw out a proposal with no security and ask the group to bolt  
security on. I would like to ask that Opera take at least a first pass  
at designing a security model if this is indeed intended as a Web- 
facing API.

If the proposal is only intended for content like widgets, then it  
might be adequate, but I don't think we could count it as fulfilling  
any of our work items for Web-facing APIs. Apple would also prefer to  
see the group put higher priority on Web-facing APIs than widget-only  
APIs. We are unlikely to implement widget-only specs. However, if  
others in the group would like to standardize widget-only API then I  
do not object on security grounds.

Received on Wednesday, 7 May 2008 19:58:07 UTC

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