How about un-install an app, update an app (assuming that the app has a cached component and we can distinguish when cached components change, and also that we desire that the user can control when an app is updated). I also think that the risks for some of the APIs vary. For example, getSelf() doesn't seem like a risk. un-install an app seems much higher (if an app can un-install others locally stored data would be lost), and the list of installed apps has the potential for fingerprinting (though also potentially useful for an app developer cross-selling another of their apps if you don't have it already). Maybe we just group the permissions into two buckets with the low/no risk APIs always granted and the others needing permission.
On Apr 16, 2012, at 2:08 AM, Lucas Adamski wrote: > Please reply-to [email protected] > > Name of API: Open Web App API > Reference: https://developer.mozilla.org/en/OpenWebApps/The_JavaScript_API > > Brief purpose of API: The Open Web Apps JavaScript API is a programmatic > interface for installing Web apps and for managing a client-side collection > of Web apps that a user has installed. > > General Use Cases: > * Install an app - navigator.mozApps.install(url, [install_data]) > * A web page can check if it is installed - navigator.mozApps.getSelf() > * Return a list of installed apps installed by this domain - > navigator.mozApps.getInstalled() > > Inherent threats: > * Installation grants some minor additional privileges > * Access to install an app on another domain introduces risks > * Privacy (users can be identified by list of apps) > > Threat severity: Low for Installation API, High for Management API > > == Regular web content (unauthenticated) == > Use cases for unauthenticated code: Just the general cases as above. > Authorization model for normal content: Explicit for install (OS Mediated), > Implicit for check status > Authorization model for installed content:Explicit for install (OS Mediated), > Implicit for check status > Potential mitigations: getInstalled() only returns the apps installed by the > current domain > > == Trusted (authenticated by publisher) == > Use cases for authenticated code: > A "dashboard" can manage and launch Apps on the users behalf > A "dashboard" can monitor the state of logged in applications > Authorization model: Implicit, execpt Remove App is Explicit (OS Mediated) > Potential mitigations: > > == Certified (vouched for by trusted 3rd party) == > Use cases for certified code: Same as trusted > Authorization model: Implicit > Potential mitigations: > > Note: not sure if management functions belong in trusted or privileged. This > is probably a subject for discussion. > > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
