I do think that having the concept of installation has nice security properties because there are some capabilities that the user should not be prompted about, but not every single website should have (it would be annoying).
However, one aspect of the user experience worries me. When someone is given a link to Facebook.com/whatever/foo/bar.php, and the user has the app installed, which opens? The app or the site? It seems like it is undesirable for there to be two versions of the same "web presence" for the user to choose between; and one is more powerful but maybe doesn't understand normal links. (I'm sorry if this has already been discussed, the previous thread was too long for me to read it all.) On Thursday, March 22, 2012, Lucas Adamski <[email protected]> wrote: > == Goal == > Determine a baseline for the different types of applications in the B2G app ecosystem. > > We are not going to evaluate operating system level issues (such as processes sandboxing, OS hardening and updates) just yet, as this part of the conversation should strive to remain OS agnostic so it can apply to apps on many different platforms, including desktops and non-B2G mobile devices. > > Once we've determined these general categories of applications, the next step will be to evaluate the security implications of each WebAPI for the app categories, followed by discussing threats and mitigations for each app category. > > == Overview == > To kickstart the conversation, 3 categories of web / B2G applications seem to have clarified in the recent discussion: > > 1) normal web pages utilizing a set of WebAPIs > 2) installed web applications utilizing a set of WebAPIs > 3) installed web applications requiring access to OS-level APIs > > Please take a look at the descriptions below and comment. Hopefully we came move through this part quickly and start discussing the properties and risks of each webAPI. > > === Web pages === > Description: A normal web page can request access to a certain set of WebAPIs. > > Use cases: Web pages would like to perform functions historically limited to plugins or other binary browser extensions. They might want to capture audio or video input to stream to a server or process client-side, use various cool input devices for games, enable desktop notifications for new emails or tweets, etc. It might optionally be possible to "bookmark" a given web app, but this does not imply any additional trust. > > Technical characteristics: No manifest, does not need to be installed or cached locally, and has no client-visible versioning scheme. No restrictions on transport or content outside of normal browser model (because it is just normal browser content). > > Security & Privacy Characteristics: The user does not necessarily have any relationship with or trust in this site, so these APIs require explicit user opt-in at runtime, and should present users with a choice where they can be realistically expected to understand the inherent security and privacy risks. Its possible these APIs may be limited entirely to things that only present privacy or annoyance risk, but not security. > > Scope: Security permissions are granted for a fully qualified domain name. > > === Installed applications with WebAPI access === > Description: A web application installed from a specific server, discovered from one of potentially many web app stores. > > Use cases: Persistent apps that the user opens to perform specific tasks. They perform functions that native apps on a given platform would be expected to perform. While some runtime dialogs might be expected, a typical feature-rich app should not result in a flood of permission requests. Social networking is a typical use case, where a single app may require access to camera/microphone for chat, contacts for integration, access photos, send SMS, trigger notifications, determine user's location, etc. > > Technical characteristics: A app manifest is referred to from an app store and retrieved from the app host. An app store is required (is it)? The app store can limit the privileges the app is granted. The app is stored in the appcache on the client. The manifest contains version information and an explicit list of files that comprise the app, so that the appcache can be effectively updated from the server when necessary. Otherwise app is always instantiated from local appcache. > > Security & Privacy Characteristics: User makes choice to install an app, which implies a limited degree of trust. That limited trust may permit implicit access to certain low-risk APIs, and explicit access to the bulk of the rest. Implicit access to API's that could compromise the intergrity of the OS or expose the user to direct financial risk is prohibited. Note there's a big difference between a user approving a OS mediated app dialog to dial a number, and an app that can dial a phone # directly without user any involvement. > > Scope: Security permissions are granted to code enumerated in the manifest. > > === Installed applications with OS-level API access === > Description: Some apps are integral components of the device UI, and need direct access to highly sensitive APIs. These apps are approved by a trusted 3rd party (ie. carrier or manufacturer) app store for implicit access to dangerous APIs. > > Use cases: User might want to swap out their default phone dialer or SMS client for a different one. Some APIs may be too difficult to secure so such apps may only be granted privileges after the app store has obtained certain assurances from the developer. > > Technical characteristics: Largely the same as the previous "Installed applications with WebAPI access" category, except for the extra trust granted to it by the store. > > Security & Privacy Characteristics: Implicit access to dangerous APIs means the risk to the user or carrier should this type of app be compromised is very high. For example, this type of app can dial a phone number directly without any user involvement or knowledge. > > Scope: Security permissions are granted to code enumerated in the manifest. > > > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
