On 23 Mar 2012, at 08:51, JOSE MANUEL CANTERA FONSECA wrote: > > > El 23/03/12 07:45, "Lucas Adamski" <[email protected]> escribió: > >> == 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 === > > Why don't you call them 'Trusted Installable Applications'? The user could > also install a Web Application but which has not been discovered through > an app store and as as result, it might not be trusted ... > >> 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 === > > Why don't we call them 'Trusted Core Applications'? > >> 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. > > Or they could be pre-installed on the device by the Carrier / Manufacturer > ... > >> >> 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. > > And probably after the carrier manufacturer has verified them
See: http://www.w3.org/TR/widgets-digsig/ > >> >> 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. > > Or by the carrier / manufacturer > >> >> 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. >> > > What do you mean by 'Code Enumerated in the Manifest'? See: http://www.w3.org/TR/widgets-access/ > >> >> _______________________________________________ >> dev-webapi mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapi > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
