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 > >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'? > >_______________________________________________ >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-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
