Monday, 24 May 2010

Sandboxed vs. Trust, sandboxing wins

One of the most basic principles on Windows, in order to prevent malware, is that you trust your software provider. There are many trust mechanisms, including driver signing, website signing, remembering whether a file was downloaded or was produced locally etc. The idea is, that if you can trace the origin of the file, you can make the provider liable. If you need to break the trust chain, for instance if you download an unsigned setup.exe file that you want to install, you need to confirm that you want to do that.

On the other hand, we have sandboxing techniques. JavaScript originally had a lot of access to the local browser, for instance, one web page could access info from another web page. Obviously, this had to be changed, each untrusted web page must be isolated from other web pages. Google Chrome even added a second sandboxing layer inside the code, so that if there are bugs in the JavaScript API implementation, the JavaScript could probably not break through the second layer. This has given Google Chrome a very good security record. Other IT technologies also implement sandboxing or are in effect sandboxing: virtual machines, managed code. Google NaCl can also be considered a kind of sandboxing, although it's basically native code "at least as safe as javascript".

Web apps have grown to be extremely popular, despite being expensive to develop and often with low usability. The main reason is that they are very simple to deploy: you don't need to install anything and it works everywhere, and data is saved on the server. This is not entirely true: You need to install an adequate browser, which means that it doesn't work everywhere, and even server/client software often only stores data on the server. So, why are web apps different?

Here is the key: Web apps are usually much easier to install/configure, and you can use web apps from untrusted sources.

Both iPhone and Android solved these parameters for local apps: It is almost easier to install an app than to bookmark a good web app, simply because the search for a good app is guided using the app store/market, and installation is as simple as bookmarking a web page. Using software from untrusted sources is handled using sandboxing. I have no idea if the provider of my currency exchange rate app is evil or not, but it cannot access anything except the internet connection, so it cannot be used to wiretap on me. I am completely sure that it will not know my location, for instance. Android Market still requires signatures, but it does not need to be a signature with trust - the security is in the sandbox.

In addition to being at least as easy as web apps, iPhone and Android apps provide better usability because they are designed for the user interface hardware, and they provide better functionality because they can work offline and with access to hardware, if you permit it.

Most Android and iPhone users that I know, have more apps installed on their phone than on their computer. The reason is not that the apps on the phone are smaller - but there is an inherent problem with Windows app: If you don't trust them, you won't install them on a computer that needs to be safe. Many IT departments lock down Windows computers so that you cannot install anything. Many employees in large organizations don't have the possibility to install even small simple apps, so web apps are their only choice - the browser is the only widespread sandboxing system on Windows.

The future is sandboxed.

Saturday, 24 April 2010

How Android beats Windows 7 laptops

Lately, many have started to use their phone for tasks, for which they previously used a PC - including updating online spreadsheets etc. The PC features much better input and output devices (keyboard, mouse, screen), so why use the phone for these tasks? Here is a list of why it makes sense to use an typical Android phone instead of a Windows 7 laptop for many tasks:

* The laptop does not have built-in GPS, so location information cannot be used to assist tasks by searching locally, looking up addresses, providing context-dependent functionality etc.

* The laptop does not have a log over what has been done lately while away from the PC. So it does not know who the user has been talking to, where the user has been driving, which destinations/shops the user has looked up etc.

* The laptop cannot easily exchange information via SMS or MMS, so in order to quickly exchange a link to someone that you have just been talking to, things become a lot more complicated than if you just grab your android phone.

* The phone is always turned on and online. This means that some tasks are usually done on the phone, and even if the laptop should be online, it is easier to keep with the usual way of doing things.

* Both devices have reflective screens, but it is much easier to avoid reflections on the phone, because the laptop is more restrictive on work positions.

* It is much easier to take a picture of a piece of paper using the phone than a laptop's built-in webcam, besides the fact that the webcam usually does not have an adequate resolution. This means that some information simply starts being created on the phone, not on the PC.

* Windows does not have a market place that makes it easy to find productivity enhancing apps - and installing software on Windows is much more tedious, too.

* Windows does not sandbox applications. If you install the whiteboard photo & filtering & email app on Android, it cannot access your files, but it is not easy to prevent file access for a similar app for Windows.

Sunday, 11 April 2010

In defense of the iPhone 4.0 SDK section 3.3.1

There have been many blog posts about the new iPhone 4.0 SDK which do not like section 3.3.1 of the developer license agreement, which says:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Apple's introduced restrictions on original programming language, which has been considered an attack against Adobe Flash. However, there is more to it. The market for smartphones has been very diverse for a long time. Microsoft has attempted to standardize smartphones on Windows Mobile, which failed because of its power consumption and because it was always a bit late to the market. Apple made a huge hit with the iPhone, because they combined new technologies that made it possible to give a great smartphone experience, earlier than what would otherwise have been possible. They were rewarded for innovation.

Now, that everybody is catching up on the basic technology, like touchscreens and sensors, other software vendors are seeking ways to standardize the ways that software is written for many platforms. There is a huge saving if software vendors can create one application that can be deployed on iPhone, Android, Maemo, Bada and others, and on many different form factors. What would the result be for Apple? They would just be one of many, and they would probably not have any significant advantage over the competition. This means that their margins would drop, in a market where prices are already going down, and they would earn a lot less money. Apple does not want that, of course.

For the consumer, that would mean a lot of apps, which do not exploit each platform well - the feature lists would focus on the lowest common denominator for the target platforms, and few platform-specific features would be used for marketing apps. It would be hard for phone platform developers to add new capabilities that the developers would love to use.

Apple's strategy is to separate itself from the apps on other platforms, giving the user a unique and different experience, which they believe will be better than usual. If you have three features, and Apple does the first two perfectly but not the third, and the competitors do all three in a mediocre way, many consumers will pick the Apple product. A good example is the HP Slate: It supports flash, but nobody cares, consumers still want the iPad.

The iPhone and the iPad will never become devices that can do everything. Of those who had this expectation, many will be unhappy about Apple's latest move, but anyone who wants innovation in smartphones, great user experiences and real choice, should be happy about the new section 3.3.1.