Hey Chaals,
On May 7, 2008, at 10:39 AM, Charles McCathieNevile wrote:
On Wed, 07 May 2008 16:47:06 +0100, Maciej Stachowiak
<[EMAIL PROTECTED]> 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
