Javia blog

While physical buttons were the standard for mobile phones in the past, it seems that the industry is gradually adopting touch-screen interfaces. The iPhone is the best example of a touch interface, but other manufacturers (e.g. Sony-Ericsson, Motorola) are also producing mobile phones with touch-screen interfaces (either exclusively touch-screen, or in addition to physical keys).

Talking about the physical keys, we can imagine that their design, shape and size was the result of elaborate ergonomic studies in order to make them as easy to use as possible (hoping that the trendy look of the device was not the only factor deciding the design of the keys).

Perhaps taking inspiration from the physical keys, the touch buttons usually have a rectangular shape (sometimes with rounded corners). But is the rectangular shape the best one? and if it is, which is the best width/height ration of the rectangle (e.g. a horizontal rectangle, a vertical one, a square, etc). Of course, the answer may depend to some degree of the particular device and the particular user, but perhaps there are also general characteristics of a good touch-screen button shape/size.

I describe below a simple experiment which allows to discover the optimal shape/size. Ask the user to touch a specific spot (’target spot’) on the screen, and record the place where the touch actually occurs. Repeat this many times. Afterwards, you can visualize the area where the actual touches occur, which likely is a shape around the target spot.

This area, the place where the actual touches occur when the user is trying to touch the target, describes the optimal shape of a touch button. It gives information about the size of the button — it should be large enough as to embed the area of the actual touches, and about its shape.

I expect that the touch area resulting from such an experiment describes an ellipse (a ‘flattened circle’). While this is not a big surprise (as it’s normal that the actual touch occur ‘around’ the target, and the ellipse is the generalization of a circle), there is valuable information in the ratio of the ellipse (how flattened it is), and in its size. While the ellipse can be covered with a rectangular button, the rectangular ratio should follow the ratio of the ellipse.

I’m so happy I’m blogging again!

So, everybody knows already that I am the author of the Arity Arithmetic Engine, a nice little open-source library for evaluating arithmetic expressions. In this library I put quite some attention on the elegant and minimal code, and on performance. The functionality is mainly split in two parts: compiling an expression (takes a string and returns a Function object), and evaluating the Function.

For example, compiling the string “g(x)=x^2″ produces a Function instance. Calling eval(5) on this function returns 25. These two operations (compilation and evaluation) are separated because you typically compile an expression once, but evaluate it many times (for example when plotting the graph of a function).

On a desktop computer, Arity can do about 50,000 compilations/second, and about 1,000,000 evaluations/second. So the compilation is about 20 times slower than the evaluation.

Why is the compilation so slow? well, you may be surprised, but the bottleneck during compilation is the parsing of a double value from a string (using the java.lang.Double.parseDouble(String)).
And Double.parseDouble() is not only slow, it also does quite some memory allocations (which again result in slowness when the GC is invoked to collect that memory).

One key advantage of the Arity library is that it compiles not only on JavaSE (desktop Java), but also on JavaME/MIDP (mobile Java). So last weekend I decided to measure its performance on my mobile phone (a modest Nokia 6300). I wrote a tiny midlet for the benchmark, and the result is:

On the mobile phone, Arity does about 500 compilations/second, and about 10,000 evaluations/second. So the 20 times factor between compilation and evaluation speed is the same as on desktop.

And the key information, the mobile phone is about 100 times slower than the desktop computer (from Arity’s point of view).

Still, 10,000 evaluations/second on the mobile phone is not bad, I am quite happy with this performance.

PS: go check out Arity: http://arity.googlecode.com/

I have just made available the source code for my projects
Menstral and Javia Calculator under the liberal MIT License.

To get the source code you need a subversion client.
The svn repositories are here:
Menstral Source Code and
Javia Calculator Source Code.

Enjoy,
Mihai

Disclaimer: this article is in draft state, I plan to come back and improve it upon checking the facts, so take it with a grain of salt.

The fact that a midlet is signed by the author (vendor) certifies two things:

1. that the author really authored that midlet
2. that the midlet is in original state (i.e. it hasn’t been modified by a third party)

The purpose of signing a midlet is two-fold:

1. to gain access to security-sensible operations on the phone (such as sending an SMS or opening a TCP connection)
2. to make sure that a (malicious) third party can’t present a different midlet as the original one

Digital signing makes use of two concepts: public-key cryptography (a.k.a. asymmetric cryptography) and digital certificate.

Signing works like this: a secure hash (also called message digest) of the midlet is computed, and this hash is encrypted with the private key of the signer. The signature is checked like this: the encrypted hash is decrypted using the public key of the signer, and is checked for equality with a computed hash of the midlet. If the two (the signed hash, and the actual computed hash) are equal it means that the midlet signature was verified successfully.

The idea is that only the owner of the private key can sign the midlet (so that the signature is verified with the corresponding public key), and that any modification to the midlet after the signing will cause the signature verification to fail.

As you see, all that is needed to check the signature is a public key. The result of the signature verification is a yes/no to whether the midlet was signed by the owner of the private key corresponding to the public key used.

But in order to be meaningful, the result should be whether the midlet was signed by a real-world entity (the midlet author/vendor, a person or company). So the public key must be associated to the identity of some author/vendor. This association between a public-key and a real-world identity is achieved using digital certificates.

A digital certificate claims that some public key belongs to some entity (a person or a company). A digital certificate contains the pair: public key, name of the entity (who owns the key). A certificate is also signed (using the same signing procedure we’ve seen above) in order to prevent the situation that a fake certificate is built by a malicious entity which claims a different identity for its key.

The midlet is signed and the midlet signature is verified against a certificate (which contains the public key needed to check the signature, and the name of that key’s owner). This certificate is also signed, and the certificate signature is verified against another certificate, which contains the public key for checking the first certificate’s signature and the name of this key’s owner. This second certificate (which signs the first certificate) is at its turn signed with another certificate. And so on, we have a chain of signatures.

This chain of signatures ends with a certificate which is not signed by any other certificate (a detail is that this original certificate is self-signed, meaning that it’s signed with its own public key, but this has the same effect as not being signed at all). The only way to be sure that this self-signed certificate is not fake is to have it in a list of trusted root certificates.

For example, your browser has a list of trusted root certificates, which contains certificates from well-known and trusted companies such as Thawte and Verisign. Any chain of certificate signatures is followed until it ends with some such trusted root certificate.

But if the final (self-signed) certificate is not found in the list of trusted certificates, then it can’t be trusted (it’s authenticity can’t be verified), so the whole chain of signatures can’t be verified.

Now let’s go back from this general signing stuff to our midlet signing. Any mobile phone comes with a list of trusted root certificates (used for verifying midlet signatures). This list contains root certificates selected by the manufacturer (e.g. Nokia) and usually also contains the root certificate of the network operator (e.g. Orange) in the situation when the mobile phone is distributed by an operator.

Let’s consider a practical example: I am a midlet author. I write a midlet, and I want to sign it, what do I have to do?
First, I need to buy a certificate from some certification authority (i.e. seller of digital certificates), such as Thawte, Verisign, GoDaddy. Because I want to use this certificate for midlet-signing, I have to be careful to select a code-signing certificate (there are also other kinds of certificates, most notably SSL certificates used to certify the identity of web sites, which can’t be used for midlet signing). So I choose to buy a code-signing certificate from Thawte for $200/year (note, the price is per year, recurring, as with a domain name).

To buy the certificate, I first generate a pair of keys, private-key and public-key. I keep the private key secret, and I send the public key to Thawte for inclusion in the certificate. Thawte checks my identity (using perhaps some photo ID that I fax them, and a phone call from them), and afterwards sends me back a certificate containing my public key and my identity (my name). Most importantly, this certificate is signed with Thawte’s root certificate (this is what for I paid the certificate’s price of $200/year).

Using this certificate I just bought, I sign my midlet, and I start distributing the signed midlet. Now some user tries to installs my midlet on his phone. The phone automatically checks the midlet signature, i.e. it follows the signature chain, starting with the midlet, my certificate, and ending at Thawte’s root certificate. If the phone has Thawte’s certificate in its list of trusted certificates, it’s all dandy and the signed midlet is installed. But if it happens that the particular phone model doesn’t contain Thawte’s certificate in its list, the signature verification fails, and the midlet isn’t installed, and the user can’t use it at all. This situation means that I paid the certification money to Thawte for nothing.

Now you may think, perhaps this example is un-reallistic, I surely may buy a certificate which is recognized by all phones? Well, no. Different phone manufacturers (and even different models from the same manufacturer) have different sets of trusted root certificates. For some phones Verisign works and Thawte doesn’t, for other phones Thawte works and Verisign doesn’t, for others neither Thawte nor Verisign works, and so on. The practical solution: buy as many certificates from different certificate vendors as you can afford (all for the same public key), and use them all when signing your midlet. When your midlet is installed on a phone, if at least one of those certificates works, the midlet signature can be verified and all is good. The downside of this method: it costs a lot of money, and it generates a lot of clut and redundant work.

What’s more: while some phome models allow the user to edit the trusted certificate list (perhaps in order for the user to add a root certificate he finds missing), many phone models do not allow it. (I can’t understant why the manufacturer would disallow the user to add new trusted certificates, I consider this a crippleware tactic. For example, Nokia S40 2nd edition allowed user access to the trusted certificate list, while the more recent S40 3rd edition doesn’t allow it anymore.)

So, let’s turn back to my case study (and publicity plug). I developed two freeware midlets (Menstral and Javia Calculator), that I distribute free of charge. Let’s say that, for the security of my users (in order to protect them from a malicious distributor who tries to impersonate my midlets), I want to sign my midlets, as to to certify that it’s really me the author, and that the midlet hasn’t been tampered with. So what do I have to do? Pay $200/year for the certificate, and have my midlets fail to install anymore on part of the phones because my certificate isn’t recognized… this is why there are so very few signed midlets.

You’d think it can’t get worse than that? why, it can: Motorola, Nokia, Siemens, Sony-Ericsson and Sun saw there is a problem and they promptly found the ’solution’: create a new certificate, and have every phone support only this new certificate, and create a signing program which will bring them more money (and have the midlet authors pay).

This new initiative is called Java Verified. The new certificate, which is the only one supported on newer Nokia phones (see Nokia 5300 at “Java verified root certificate”) is called UTI Root (Unified Testing Initiative).

And how does this Java Verified, Unified Testing Initiative works? Simply: you pay! No, really: you send your midlet to one of the Java Verified Test Providers (like CapGemini), who runs a series of tests of your midlet. For example, they check that your application provides a Help command and an Exit command, that it doesn’t hang, that it doesn’t do anything malefic (but they don’t have access to the source code), etc. They do this by running the application a few times on a real device. If they find some problems they send you back a problems report, and (after attempting to fix it) you have to pay again for one more try at the Java Verified certification. Pay, and repeat.

How much does it cost? With CapGemini, it costs 240 euro for the first submission, and 210 euro for subsequent submissions (after failing certification on the previous attempts). This price is per midlet and per targeted device. That is, if you want your signed midlet to run on multiple phone models, you have to pay once for each phone model (see a list of devices supported by Java Verified, you have to pay for each one).

So Java Verified considers that a midlet author should specify the targeted device for the midlet, the targeted device being something like Nokia 5300 or Nokia 6131. So much for the portability of JavaME applications, which says that a JavaME midlet should be able to run on a wide range of devices, from different manufacturers, with different screen sizes, etc. (And Sun, who should be the main pusher of java portability, is a member of Java Verified.)

For example, my Menstral midlet is supposed to run on any MIDP device with a color screen at least 128×128 pixels in size. I guess such a ‘targeted device’ counts as many tens of Java Verified devices.

So again, that’s why there are so very few Java Verified midlets…