BONDI Feedback Security
From MemberWiki
Contents |
About this wiki page
This wiki page is one of several wiki pages that OpenAjax Alliance will use to collect feedback from its members via its wiki about the BONDI 1.0 Release Candidate specifications. The key review period goes from 'Feb. 12-25, 2009. See BONDI for more information about this BONDI review and feedback initiative. The full set of wiki pages is as follows:
- BONDI - Main wiki page
- BONDI Feedback APIs - Feedback page relative to the general approaches that OMTP is using for its APIs. Are the APIs understandable, familiar in approach, and convenient to JavaScript developers?
- BONDI Feedback Security - Feedback page relative to the security features in BONDI. Is the design robust? Are there any security holes? Are the security features easy enough to use?
- BONDI Feedback Enterprise - Enter any detailed spec errors on this wiki
- BONDI Evangelism - Possible ways that OpenAjax Alliance might be able to help evangelize BONDI
- BONDI V2 Wishlist - OMTP will start discussion about future versions of BONDI in March 2009. This wiki page collects any feature requests from OpenAjax members.
- BONDI History - Quick introduction of historical activities leading up to BONDI initiative
BONDI Feedback: Security
Introduction
This wiki page contains feedback from members of OpenAjax Alliance on the security features in BONDI. Is the design robust? Are there any security holes? Are the security features easy enough to use?
Feedback
IBM feedback
(Jon interviewed Larry Koved and Suresh Chari, who specialize in Web security issues within IBM Research)
High-level feedback: BONDI security looks good from a conceptual perspective. However, need to see concrete examples of usage scenarios with sample policy files in order before it is possible to judge whether BONDI security is useful in any meaningful way.
During the interview, some brainstorm scenarios that possibly could grow into concrete examples:
- Personal pictures use case. Several applications might save images to the phone's disk. Often, there should be separate sandboxes for different sets of images. For example, your personal photographs should not be available to any application that gains access to the camera.
- Barcode reader application via camera. For example, suppose there is a pharmaceutical application that includes ability to read a bar code that contains prescription information. This application should only be given access to a restricted set of camera features (e.g., ability to take a picture, but no ability to open or save pictures onto the local disk) and should be able to upload/retrieve data to/from a single web site (prescription service provider).
- Neighborhood watch use case. All of the people in a given neighborhood install the same mobile application which allows people to send emergency SMS's to each other and the local police department.
BONDI virtues:
- Good that BONDI addresses both browser and widgets
- Good that BONDI defines standards URLs for various device services
- It is good that BONDI includes provisions for digital signing
Concerns:
- Pushing bubble: Until we see concrete examples, there is a concern that BONDI's policy framework might simply "push the bubble" and not provide any meaningful help towards adding security to mobile applications. What we mean here is that having a standard XML file for describing policies might not actually help if the truly difficult issue is decided what the policies should be, who should define the policies (browser vendors? device manufacturers? operators?) and which software should enforce the policy
- All-or-nothing policies: One worry is that phone policies will tend to be all-or-nothing, where a user grants or denies access to an entire database, such as the local phone book. Simplicity always has its advantages, but also can lead to granting access to more information that the user would have preferred. Studies have shown that if users are given yes/no choices on granting access to an application, they often will choose yes when they don't understand the implications. One option to consider is a 3-way choice on access to certain data stores: deny, allow all, or one-at-a-time prompts. A local address book might contain a combination of family members, friends, community group members, and business associates. A particular application often might target only one of those domains. For example, your community group (e.g, neighborhood watch) might all install a common mobile application that sends SMS messages to the various members when something significant comes up (e.g., robbery in the neighborhood). For this application, you would only want to share your community contacts, not your family, friends or business associates. [However, it is not clear in this use case that the phone has such a capacity, or that users will understand how to use it. I do agree that UI considerations will be absolutely critical in determining whether this ends up being a success or a security nightmare. --chaals 11:16, 19 March 2009 (UTC) ]
- Tradeoff between simplicity and flexibility: An effective security system must offer the right balance between something that is simple enough that users and developers can make use of it, yet flexible enough that it provides meaningful value. The Java world historically has been plagued by security systems that were either too simplistic or too complicated. Again, without seeing concrete examples, it is impossible to tell whether BONDI has succeeded with the tradeoff.
Notes and questions:
- Nested applications or services: What happens if a mobile widget wants to include the equivalent of a DLL (i.e., a dynamically loaded shared component or embedded application), such as a mini-browser or a map. Is there a well-defined policy within BONDI for how to address security in such nested scenarios?
- Sandboxed file systems and databases: The file system access feature in BONDI seems to have some provision for sandboxing into volumes, but we haven't figured out how it works completely and how rigorous the requirements are for isolating the sections of the file system used by particular applications from each other. Does BONDI have a database feature? If so, will data for one application be isolated from another application?
- Extensibility: Is there a hook in BONDI for logic to perform security checks in case the policy language isn't sufficiently expressive? Is it possible to put custom elements and attributes in the BONDI XML format? Ideal if BONDI security meets world's needs with a fully declarative approach with custom markup, but most systems find the need for extensibility.
