It seems more and more sensors are being used in wireless communication modules with each new version of a device. We have accelerometers, gyroscopes, compasses, and more just in smartphones. These components are often integrated with other components – such as, Bluetooth, Wi-Fi, NFC, etc. – for enhanced data sharing. Such functionalities are helping to usher in the new age of the Internet of things (IoT). But, as devices and their applications share more data with each other, security risks increase. Manufacturers are addressing this in part by having implemented another layer of security: the Sandbox mechanism.
Apple recently rolled out Apple Pay with the hopes to push and popularize e-wallet payments based on NFC. It is known that Apple uses the Sandbox technique to secure its applications. On iOS, this is done at the OS level. Sandbox is a security method used to isolate running programs from each other at an application or OS level. With it, developers can restrict applications or devices from accessing certain OS resources. It can add a layer of protection for user data when hackers exploit vulnerabilities in an applications or systems.
More companies like Apple, Google and Microsoft are moving to secure systems and web browsers with Sandbox. But, it may impact end user and developer behavior. For example, some users would rather root their devices to obtain more system rights, which circumvents Sandbox. If users or developers are willing to squander an added Sandbox layer of security, another question begs asking. Is it necessary to enforce a Sandbox technique on an OS or with web browsers?
Sandbox for Mobile
The capabilities of applications running in Sandbox mode can be extremely constricted. But, explicit policies can be setup to grant permissions. For example, an application can be allowed to access key system features and specific user data. Apple and Android devices provide a Sandbox mechanism. It’s popularly known that Android is more flexible in allowing applications to obtain greater permissions. Almost anyone who has downloaded an app is familiar with how Sandbox is implemented. When an app is installed, sometimes a user will be prompted to review permissions and decide to enable or disable them. Thus, he or she implemented Sandbox policies for that app.
Android’s enhanced security flexibility includes more possibilities without rooting. For example, users aren’t always restricted to downloading apps only from Google Play. They can download and install them from unknown or other sources. While it can present a greater security risk, this flexibility does help satisfy additional user requirements. Obviously there is a tradeoff between having more restrictions and being more open. It’s commonly known iOS is the most locked-down mobile operating system. Apple has restricted access to the OS far more than Google has for Android. In a way, iOS more automatically protects users whereas on Android, most users have to judge and apply restrictions. In some cases, users might not even understand what permissions they may or may not want to grant. So, it becomes easily arguable that an Android device is at much greater risk at getting infected by a virus or worm compared to an iOS devices. But, it’s also easily arguable that Android is more flexible in application use.
The industry needs better balance. A new question has to be addressed. How can manufacturers better balance an even more flexible user experience while enabling an even safer environment? The Sandbox technique must adapt to address this necessary shift.
Sandbox for Desktops
The Windows and Mac OSes provide official application stores for users and the stores employ the Sandbox mechanism. For example, by default in Mac OS X unverified third-party applications are now disallowed. But Sandbox on a desktop OS is different from a mobile OS. Mobile OSes were born with Sandbox. The desktop was born more open. For users who touched iOS before Mac OS, Sandbox comes across more acceptable and even convenient. But, for old users and developers that lived on Mac OS first, it is a little bit odd and harder to accept.
On Windows 8, the oddness is a bit different. For example, we can install Skype as a Windows App from their app store with Sandbox enforcement. But, we can also install it from the Skype website without Sandbox enforcement. The app version is different than the desktop version in other ways too. But, to users, Skype on a single machine should probably just be Skype. It’s difficult to grasp the same application appearing twice, operating slightly different from one another, including permissions. For many years on desktops, people were able to install applications with a few or no restrictions, let alone prompts to allow this or not allow that. Thus, it’s likely that on desktops the Sandbox mechanism will be an alternative but, not a replacement security measure.
Sandbox for Web Browsers
HTML5 technology is fast becoming mainstream in web browsers. As a result, leading browser developers are abandoning certain components. We’ve seen IE abandon ActiveX and Chrome abandon NPAPI, etc. More and more, web browsers are using Sandbox to replace old security techniques and disallow plugins from directly accessing system resources.
Sandbox can provide end users a more secure browsing environment. But, Sandbox might also be inconvenient for users and developers. Let’s explain. When web browsers automatically update in the background, users will likely not be aware of what web browser features have been changed. That is until they suddenly cannot access or use certain features or functionalities that previously worked. For example, an online banking systems might have been using ActiveX for password input and verification. If ActiveX is – unknowingly to the user – abandoned, how will users access their account? Thus, it’s likely that banks are in no rush to update their systems.
As more web browsers move to enforce the Sandbox mechanism, developers will have to figure out new plugin solutions. For example, WebSocket might be the answer to upgrade from old to new as soon as possible.
What’s the Path?
The Sandbox mechanism has proven itself excellent for securing devices, though not without hurdles. Developers by now fully understand it comes with tradeoffs. The main one is more application and device restrictions which obviously results in less freedom. Thus, it is hard to cover all user requirements. There’s no doubt that providing multiple options for the Sandbox security mechanism is ideal. It’s undeniable that more and more devices will talk to one another. The same is true of their applications. Thus, developers should move to face the challenges in Sandbox security now rather than later.