Confirmed users
1,340
edits
No edit summary |
No edit summary |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Device Storage == | |||
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. | |||
*Create files with incriminating / illegal information, then call the cops | |||
*Create files that other apps can look for to control their behavior | |||
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, | Threat severity: high to critical - privacy concerns, loss of user data, | ||
access to confidential data. | access to confidential data. | ||
References: | |||
*https://wiki.mozilla.org/WebAPI/DeviceStorageAPI<br> | |||
*Security discussion: https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9b5e3f55ea2c42f8 | |||
{| border="1" class="wikitable" | |||
! Type | |||
==Notes== | ! Use Cases | ||
Ideally permission should be given on a type basis (i.e. enforce the "intended usage" at runtime). So giving permission to access music doesn't automatically give permission to | ! Authorization Model | ||
photos. If the type is a string literal when the code is reviewed, that | ! Notes & Other Controls | ||
would mitigate the issue. Otherwise sub-permissions for types | |- | ||
(device-storage.music) or separate permissions for each type | | Web Content || None || No direct access (access via web activities) || | ||
(device-storage-music) would be needed. Also has the benefit that it | |- | ||
allows the permission prompt to be more explicit about what is being | | Installed Web Apps || None || No direct access (access via web activities) || | ||
|- | |||
| Privileged Web Apps || Photo gallery, camera app that displays photos, any app that saves data will likely want to read it back. ||Explicit || | |||
*Granting permission only for a particular type of file (images, pdf, etc). | |||
*In the short run we will rely on the "intended usage" to communicate to the user the risk of permitting this access. | |||
|- | |||
| Certified Web Apps || Notify an app if the user is idle. || Implicit || | |||
|} | |||
===Notes=== | |||
Ideally permission should be given on a type basis (i.e. enforce the "intended usage" at runtime). 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. | granted. | ||
__NOTOC__ | __NOTOC__ | ||
[[Category:Web APIs]] | |||
[[Category:Security]] |