wiki.webvm.net/ webvm/ FAQ

This section discusses some of the issues that are commonly raised in connection with WebVM.

How does WebVM relate to Liveconnect?

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.

Also see liveconnectcomparison.

How does WebVM relate to Google Gears?

Google Gears is a browser plugin that gives websites access to specific APIs and platform services. The main service currently provided is access to a database (for persistence of data, and thus support for offline working), but work is underway to add API support for location and other services.

Gears is a significant contribution to the device API problem, and it is quite possible that, over time, the Gears APIs will become de facto standards.

The main difference between WebVM and Gears, is that any Gears deployment will still fix the available APIs at the time of device manufacture. Also, 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.

How does WebVM relate to Android?

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.

Which mobile browsers are supported?

All NPAPI-capable mobile browsers are supported right now - this includes Webkit (Safari), Gecko (Mozilla Firefox), and Opera.

An ActiveX version of WebVM is under development, which will mean that PocketIE is supported, as well as third party browsers on Windows Mobile.

A WebVM SDK will be available which will permit WebVM to be integrated with any other browser that does not support a standardised plugin API; the only restriction is that the browser must support scripting of plugins.

Which Java APIs are available?

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:

Which Java VMs are supported?

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.

I need to use a WebVM API. How do I find the one I need?

Like Firefox extensions or Programmable Web list of APIs we will maintain a list at first on apis directory as a wiki blog page.

Can WebVM be used to emulate Motorola WebUI APIs?

Yes. A standard emulation of these APIs is under development, and will be released once the Motorola APIs are stabilised.

Can WebVM be used to emulate Adobe AIR APIs?

Yes, in principle, but no work is currently underway to do this.

When will the WebVM SDK be available?

A beta version of the SDK will be available in Q2 2008.

Why isn’t the MIDP2 security model good enough?

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.

Authenticity and trust

The MIDP2 security model uses cryptopgraphic 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.

Page vs library permissions

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.

Browser same-origin policy

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.)

Can I use MIDP3 Liblets as WebVM controls?

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