This section discusses some of the issues that are commonly raised in connection with WebVM.
Liveconnect is another mechanism that bridges Javascript and Java, and it is commonly found in the Java plugin installed in desktop browsers.
Many of the underlying mechanisms are common between WebVM and Liveconnect, but they have slightly different aims, and they target different Java technologies.
Liveconnect aims to provide a way for the Javascript programmer to include Java code directly inline in a script. This exposes the full Java platform API (which is heavyweight and has a very large footprint), and the mechanisms it uses (ie the JNI API) are not available on a CLDC-class JVM as is commonly found on a mobile phone.
However, probably the biggest difference is the way the programmer is expected to create applications. WebVM aims to keep a completely standard Javascript development environment, but augments it with certain additional APIs (which are in turn implemented in Java, but this fact is hidden from the user of the API). Liveconnect aims more to migrate the programmer away from pure Javascript to a mix of Java and Javascript, which results in code that cannot be ported away from that specific desktop Java environment.
Further, Liveconnect does not provide a security model with the richness of the WebVM model, so it is unable to satisfy many of the requirements we have identified for WebVM.
Google Gears is a browser plugin that aims to pioneer HTML5 standards.
The main difference between WebVM and Gears, is that Gears APIs are controlled by Google. In order for your API to be included into Gears,
The Gears security model is not as rich as the WebVM model, so the more advanced applications of WebVM are not possible with Gears.
Of course, WebVM could be used to implement Gears APIs. In addition, WebVM and Gears can coexist without any difficulty.
Android is a complete platform which includes a Java VM, a user interface and a series of applications and frameworks built on top of them. One of the key frameworks is Webkit, which is presented as a component in the UI system, so applications can be build using it as an interactive building-block.
Android provides a mechanism to bridge between Javascript code executing in a Webview and the underlying Java runtime. It allows a developer to define and implement any arbitrary API in Java, and then expose that API to the Javascript programmer by attaching a Java instance (that implements the interface) to a Webview. A peer object is created within the Javascript global namespace which delegates all method calls to the associated Java instance.
In this respect, the Android mechanism is very similar to the WebVM mechanism - and, like WebVM, Android does not define any specific device APIs at the Javascript level.
There are some important differences between WebVM and Android. First, Android does not permit access from a remote website to Java functionality - it relies on applications being packaged and installed locally. As a result, the system is not as flexible as WebVM in many respects, and the security model is not as rich.
Another important difference is that Android is a complete platform, and this functionality is therefore only available on phones built from Android - whereas WebVM aims to enable the creation of interoperable content across all handset platforms by virtue of being a portable plugin.
BrowserPlus is focused at the Desktop. WebVM is focused on mobile devices. WebVM uses native bindings instead of using a protocol interface used by Browser Plus.
PhoneGap takes a different approach, by hosting a Web application in a WebView container and exposing the mobile’s APIs via the SDK. Phonegap is probably a good approach on the Apple Iphone platform where native plugins are not allowed (unless you are Google). On Android there is already Gears. On other platforms where SDKs are of lesser quality or rather less integrated, the browser plugin approach that WebVM takes is better.
All NPAPI-capable mobile browsers are supported right now — this includes Webkit (Safari, Iris), Gecko (Mozilla Firefox), and Preso (Opera) engines.
An ActiveX version of WebVM exists, which supports Internet Explorer and PocketIE.
Any Java API that is supported by the Java runtime on the handset is accessible by WebVM - subject always to the security configuration permitting that access. Phones shipping today will usually include most or all of the following APIs:
Currently, WebVM supports any JNI-capable JVM, and the Aplix JBlend CLDC VM.
CLDC VMs typically do not have JNI features, therefore requiring extra integration work which is accomplished by Aplix’s JBlend CLDC VM.
WebVM technology has been chosen by OMTP to enable BONDI APIs.
Yes. A standard emulation of these APIs is under development, and will be released once the Motorola APIs are stabilised.
Yes, in principle, but no work is currently underway to do this.
In general, a browser security model is typically different from the MIDP2 model defined for locally installed applications; WebVM itself introduces some additional issues for the browser security model. Further, browsers themselves differ in terms of the detailed security model, and WebVM must be capable of working within multiple browser environments. All of these factors must be taken into account to define a usable and effective security framework for WebVM.
The MIDP2 security model uses cryptographic signatures to verify the authenticity and integrity of a downloaded application. A certificate validation chain is established which links the certificate of the signer of the application to a root certificate from a known and trusted entity (such as a certification authority, or CA).
This public key infrastructure is typically used to verify the validity of the signature applied by the signer of the application, and hence the authenticity of the application package; having reliably identified the author, the user can then make a decision about the trust that can be placed in application. However, MIDP2 makes a significant simplifying assumption, that the level of trust can be decided on the basis of the owner of the root certificate in the certificate chain - that is, the identity at the other end of the certificate chain. By doing this, it really confuses authenticity and trust, and places control for determination of trust with the root certificate owners (ie the operator and device manufacturer) rather than the user.
Security considerations for a WebVM library are different from those for a standalone Java application. When a web application makes a request to a WebVM library, which in turn makes a call to a security-relevant platform API, the request is ultimately being made on behalf of the web application, not just the library. Therefore, it is not appropriate to grant permission for an operation solely on the basis of the trust assigned to the library; the identity and trust level of the originating web application must also feature in the security decision. A framework is needed that supports this.
Current browser security policies are based in part on a philosophy that regards the client code (in the browser) and the server code as a single composite entity; security-relevant actions that are confined within that composite entity (such as a connection request back to the originating website) are treated differently from actions that go outside that entity (such as a connection request to an unrelated domain). This is the basis of the same origin policy, wherein HTTP requests can be made by an app to servers in the same domain but not others, and there are similar restrictions in the visibility of JavaScript global variables. It must be possible under the WebVM framework to create security configurations that implement this same philosophy. (Note that under the usual MIDP2 security model this is not possible, because granting permission to make HTTP connections does so without regard to the destination domain.)
Currently, we do not believe this is possible. The reason is that the MIDP3 specification forbids a compliant implementation from executing code in a Liblet except when invoked by a MIDlet. There is no other technical reason why Liblets could not be used. WebVM: unlocking the power of the mobile web