Confirmed users
717
edits
WebAPI/Security/DeviceStorage: Difference between revisions
no edit summary
mNo edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
picture, select a song to play. | picture, select a song to play. | ||
Authorization model for uninstalled web content: Explicit ( | *Authorization model for uninstalled web content: Explicit (web activities) | ||
*Authorization model for installed web content: Explicit (web activities) | |||
Authorization model for installed web content: Explicit ( | *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?). | ||
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) == | == Trusted (authenticated by publisher) == | ||
Use cases for authenticated code: Photo gallery | Use cases for authenticated code: Photo gallery | ||
*Authorization model: Explicit | |||
Authorization model: Explicit | *Potential mitigations: 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. | ||
Potential mitigations: 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 (vouched for by trusted 3rd party) == | == Certified (vouched for by trusted 3rd party) == | ||
Use cases for certified code: File manager | Use cases for certified code: File manager | ||
*Authorization model: Implicit | |||
Authorization model: Implicit | *Potential mitigations: None. | ||
Potential mitigations: None. | |||
==Notes== | ==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 | 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 | ||
photos. If the type is a string literal when the code is reviewed, that | (device-storage-music) would be needed. Also has the benefit that it allows the permission prompt to be more explicit about what is being | ||
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__ | ||