- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 7 May 2008 12:57:25 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: "Web API WG (public)" <public-webapi@w3.org>
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 content. 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. Regards, Maciej
Received on Wednesday, 7 May 2008 19:58:07 UTC