comments inline below Michael
----- Original Message ----- From: [email protected] To: "mozilla dev webapps" <[email protected]> Cc: [email protected], [email protected], "Mozilla B2G mailing list" <[email protected]> Sent: Sunday, June 3, 2012 6:53:05 PM Subject: Re: [b2g] WebAPI Security Discussion: Device Storage API (Final call for feedback - Please reply-to [email protected].) I'd like to finalize the permissions model for this API, but there hasn't been any feedback here, and I am not confident original proposal is effective or accurate. The problem I see with the proposal below is that it doesn't address the threat of existing files being deleted/modified (see https://wiki.mozilla.org/WebAPI/DeviceStorageAPI for more discussion). Does anyone have thoughts on the following questions: - Will there be separate shared file stores (e.g Photos, music, videos I assume yes, maybe this is a b2g specific thing though?) > separate file storesmay be needed to support different security requirements, > e.g., DRM on music files, but not for photos - Will access in some cases be only granted to one specific file store (I am thinking here to support a prompt like "Do you want to grant access to this app to read your photos" >> I would favor letting the use control which apps have access to specific >> file stores. This will help with privacy issues which are likely to get more >> attention in the coming years - Will create/read be a separate permission to edit/delete (I think it should be, or there should be some way to prevent untrusted or even trusted apps from deleting all your media) > agree, nothing worse than adding or removing a new app and then losing a lot > content - Paul On Wednesday, 9 May 2012 08:59:49 UTC+10, [email protected] wrote: > Please reply-to [email protected] > > Name of API: Device Storage > Reference: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI > > Brief purpose of API: Let content access files based on name and type. > Can be enumerated. > > Inherent threats: Use excessive resources (file space), read files, > change or delete files. Files could potentially contain confidential > information. > Threat severity: high to critical - privacy concerns, loss of user data, > access to confidential data. > > == Regular web content (unauthenticated) == > Use cases for unauthenticated code: Access a previously taken profile > picture, select a song to play. > Authorization model for uninstalled web content: Explicit (OS Mediated) > Authorization model for installed web content: Explicit (OS Mediated) > Potential mitigations: Make sure the user knows what files is being > accessed when asking permission. No option to remember permission. OS > mediated interface (like file picker - via intents?). > > == Trusted (authenticated by publisher) == > Use cases for authenticated code: Photo gallery > Authorization model: > Implicit: Create (e.g. camera saving a photo to the camera roll) > Explicit: Read, Modify (delete,rename,overwrite,edit) > Potential mitigations: Granting permission only for a particular type of > file (images, pdf, etc). > > == Certified (vouched for by trusted 3rd party) == > Use cases for certified code: File manager > Authorization model: Implicit > Potential mitigations: > > Notes: Permission should be given on a type basis. So giving > permission to access music doesn't automatically give permission to > photos. If the type is a string literal when the code is reviewed, that > would mitigate the issue. Otherwise sub-permissions for types > (device-storage.music) or separate permissions for each type > (device-storage-music) would be needed. Also has the benefit that it > allows the permission prompt to be more explicit about what is being > granted. _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
