On 24-04-2014 13:16, Gao, Shawn wrote:
Hi,
In “Intent to Implement - Native File API”, “requestNativeFileSystem”
has path parameter, which points out where is the root of this file system.
This will lead many security issues. Hence, I suggest changing the path
to type of directory, which can be translated to real path by this
extension. That will avoid expose whole storage to developer.
Following types are under consideration.
1. Normal resources path on user storage, Downloads, Documents, Videos,
Pictures.
2. AppPath, root directory of this application.
3. InnerStorage, root directory of inner storage, like “storage0” on
Android.
4. ExternalStorage, root directory of external storage.
Developer has full read/write/create/delete ability in these directories.
It looks like provide much more directories to developers. Maybe we can
remove some directories out of this list. Or, only grant read permission
for some of directories.
Any advice?
Thanks,
Shawn
But isn't accessing the whole filesystem the whole point of this API? I
think it is only a security issue if you manage to access a directory
that you don't have the rights to.
The criticism towards this kind of API is exactly that:
- We could use something like IndexedDB to store data in a sandboxed
filesystem.
- We could use some "Media Gallery" type of API to have access to
"media", like documents, pictures, videos, etc.
I'm not exactly aware of the requirements of this API, but I think it
might make sense to keep it like it is and make sure you need a very
special type of permission to use it.
Also, I expect the platform where we are running Crosswalk to take care
of sandboxing the filesystem. The filesystem API should not be the one
enforcing these restrictions.
Cheers,
_______________________________________________
Crosswalk-dev mailing list
[email protected]
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
