Real-World Distributed Computer with Ibis

   Interest has grown in recent years, in establishing a means for world-wide computation. This is the motivation behind the development of computational clouds. The researchers at Vrije University in Amsterdam are looking for a solution in their software known as Ibis.
   Ibis employs an integrated system seeking to ease the process of both programming and distributing these computationally difficult applications. Ibis provides a communication library, the Ibis Portability Layer (IPL), and a deployment system. The deployment system consists of a GUI and a library for deploying applications implemented with the Java Grid Application Toolkit (JavaGAT). Ibis has been designed to be highly portable. It follows the paradigm that any application should be compiled once, then run everywhere on the distributed system. Using Java virtual machine technology, they are able to operate in most execute environments. This system is able to dynamically reassign tasks when a resource crashes, as well as redistribute workloads when new resources are added. All the many features of Ibis come with some level of computational overhead, but it is minimal when compared with the runtime of the tasks it is designed to handle.
   Ibis has already received use from notable institutions like INRIA, Jylab, and the Barcelona Super Computer Center. This project is of particular interest because despite the fact that a mobile phone could not operate the entirity of Ibis, it was able to utilize the multimedia servers to obtain a result from transmitting an image in 3 seconds. This software suite has the potential for use in many aspects of computing, and they are presently working on integrating with accelerators with GPU's that would open new avenues of development.

Bal, H.E.; Maassen, J.; van Nieuwpoort, R.V.; Drost, N.; Kemp, R.; van Kessel, T.; Palmer, N.; Wrzesińska, G.; Kielmann, T.; van Reeuwijk, K.; Seinstra, F.J.; Jacobs, C.J.H.; Verstoep, K.; , "Real-World Distributed Computer with Ibis," Computer , vol.43, no.8, pp.54-62, Aug. 2010
doi: 10.1109/MC.2010.184
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5492667&isnumber=5551033

Opportunistic Communication for Multiplayer Mobile Gaming: Lessons Learned from PhotoShoot

   In this paper the authors describe their prototype for mobile “opportunistic communication” called Ibis. Ibis is a middleware that attempts to generate ad-hoc communication between phones without the need for a centralized server. The authors enumerate the faults of the current use of centralized servers for mobile gaming, stating that there are a variety of other means that are simply not utilized. Ibis attempts to make use of all those available. The software attempts to bind to any available network, and allows for communication between arbitrary numbers of send and receive ports. Ibis is evidently lightweight, so we can surmise that the power consumption is low on the hosting phone, though no comment is made to this effect. There are few implementation details discussed aside from the fact that most everything is performed ad-hoc.

   Also covered in the paper is a small game designed to use the Ibis system. The authors call it PhotoShoot. It is a two-player dueling game wherein the users attempt to snap a photo of the other’s face, after pacing off from eachother, within a certain timeframe using a limited number of shots. The face recognition component of the game was limited to the area of the augmented reality reticle located in the center of a user’s screen. This was done in order to cut back on computationally expensive face recognition. User studies showed that the game performed well, though further development to Ibis  must be done to allow it to handle inadvertent disconnects. On a side note, Ibis was originally developed for High Performance Distributed Computing.

Roelof Kemp, Nicholas Palmer, Thilo Kielmann, and Henri Bal. 2010. Opportunistic communication for multiplayer mobile gaming: lessons learned from PhotoShoot. In Proceedings of the Second International Workshop on Mobile Opportunistic Networking (MobiOpp '10). ACM, New York, NY, USA, 182-184. DOI=10.1145/1755743.1755780 http://dl.acm.org/citation.cfm?doid=1755743.1755780

Understanding Android Security

   This paper concerned itself with educating the public of the existing security paradigms in Android applications and the reasons for their implementation. It opens with a rather extended example of a “friend finding” application, and is followed by a short summary of Android components. An Activity defines the user interface, and only one is allowed screen and processing resources at one time. Service defines a component that performs background processing after an activity has ended. Content Providers are databases that may be accessed via SQL queries. The final type is Broadcast Receivers which handle the communication between applications.

   For the most part inter-component communication or ICC is handled by the examination of security permissions labels that are located in a security manifest document. Here users may explicity state whether each component is private, public, or requiring a specific permission. All defined permission policies are set at install time and cannot be changed without a reinstall. Most components including broadcasts have only one permissions label to be defined by the developer. Content Providers have two to allow for both read and write permissions control. There is also a tertiary feature called service hooks which allow developers to define additional security measures within their coding. This is particularly useful in the case of a Service, which is only allowed one permission label to govern both starting, stopping, and rebinding the component.

    These permissions are themselves protected by application levels attributed to them. These are namely “system”, “normal”, “dangerous”, and “signature”. System level permissions are required to modify the telephony API. Normal permissions are public and distributed to any application that requests them. Dangerous permissions are granted to a user only after they successfully identify themselves. Signature permissions are only granted when an application is “signed by the same developer key as the package defining the permission.” 

Enck, W.; Ongtang, M.; McDaniel, P.; , "Understanding Android Security," Security & Privacy, IEEE , vol.7, no.1, pp.50-57, Jan.-Feb. 2009
doi: 10.1109/MSP.2009.26
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4768655&isnumber=4768640