Android 2.2: Droid Safety
With the new release of Google’s Android 2.2, there are several observed pros and cons for the adaptation of its security features.
One of the Android’s assists is its high degree of Source Code Openness, which is the degree of accessibility to view and modify the devices codes or the degree which systems operate within boundaries. This accessibility is advantageous for developers and also for Original Equipment Manufacturers (OEM). Unfortunately, Source Code Openness also makes it difficult for IT Pros that deal with any security and support organizations effectively.
An additional feature is a new device management API; the Android 2.2’s form of management will enforce the lowest level of security. It allows the user to erase all data on the device and replace it with the factory settings. This is done by the use of a local device pin or password. The ease of this wipe makes it an excellent feature for small and medium sized businesses. A frequent use for the new device management API will be to incorporate it with an Exchange Activesync capable user, so he has the option for the erase/wipe capability.
Though the new device management API is sufficient for smaller organizations, it is not adequate for security in larger firms. An issue with the Androids 2.2’s management is that the implementation details are left up to the OEMs or the Independent Software Vendors (ISV). Meaning, different Android 2.2 devices will contain different levels of security. Mobile information workers, as in users, also tend to get blocked from key work situations by IT pro policy. A resolution to this issue is to enable a device management that allows for the implementation of security. A fix to the differentiation in security levels is through standardization, by using ISV-built applications.
Another major issue with the Android 2.2 is that the devices are obligated to report the use of public interferences to the user when they install an application. However, more often than not, users tend to click the “yes” or “ok” button without fully understanding what they are agreeing to. The unfortunate side affect of this tendency is that the application they are installing may be or enclose a virus. Because the system does not have or allow complete control over the applications your device is susceptible to any intrusion.
Along with the aforementioned problems, there are also problems with IT support due to the lack of standardization. The Android 2.2’s open source temperament means that the devices have unknown code changes made by the OEMs. This makes it very difficult for support to cope with any problems that may arise.
In general, what ITs want and are looking for from the Android is to have platform standardization along with centralized management. The Android does well in situations where the enterprise selects a device and molds it to align with its needs, because the Androids variability allows for adaptation. However, it will have a difficult time breaking into conditions where the organizations are IT security support heavy and reliant.
[Photo courtesy of startlr.]
