The recent announcement of Alien Dalvik by Myriad Group clarifies things a bit on the Android side, since this product simply allows Android applications to run on other operating systems. My expertise is not deep enough to understand how difficult this is, but the idea sure sounds good at first. Developers are really hard to attract these days, so taking advantage of an existing platform to enrich another operating system looks smart. From my perspective, it also shows the superiority of Google’s approach. This has only been possible because Android is an open-source system, which has been adapted by a third-party company to run on another operating system. This allows Google to reach even more customers, without having to do the work themselves.

Now, the problem is: are there going to be many platforms on which to port this Alien Dalvik? The With Meego’s perspectives being quite somber and iOS an unlikely target, there aren’t that many candidates left.

From Onzo’s Tim Holley and Oracle’s Jean-Yves Bitterlich, this is about Project Hydra. The project starts by healthcare issues caused by an aging population. The problem is to figure out what we can do at the infrastructure level to help addressing tomorrow’s growing helath issues of our elderly. This basically means being proactive.

Telehealth is possible, but the data needs to get out of the home. And since we are not talking about highly connected people, smart meters seem to be a solution. Smart meters bring a communication path into every home, and telehealth only transfers little data. The idea is to integrate new sensors (health sensors, like a scale or blood pressure) into the devices accessible from the smart meter infrastructure.

The idea is to add value-added services into smart meters, making it possible to get a better return on investment on the deployment of smart meters. This is the goal of Project Hydra in the UK. The idea is to integrate telehealth services of weight and blood pressure. The project combines a local Zigbee network to an external GPRS connection at the communication gateway shared by all the meters.

So, why smart cards in this project? The platform need to be able to evolve over time, with remote software updates, or added support for new devices over time. Of course, security is important as well, and isolating the applications from each other sounds like a good idea (the utility company doesn’t need to know about your blood pressure). All of this sounds good for Java Card:

• Protecting valuable assets. Yes, smart cards do that.
• Devices distributed in uncontrolled environment. Yes, we know how to handle that.
• Personalisation during deployment. GlobalPlatform has everything it takes to do that.
• Protecting assets of multiple stakeholders. Easy with a good firewall and a few Security Domains.
• Remote software updates. This one is trickier, but why not …
• High volume, low cost. Yes, we know how to do that.

All these issues have already been addressed by the smart card industry. An interesting bonus is here that smart cards also address some basic smart meter issues, (security in tariff upgrades, management of pre-paid accounts, protection against hacking, etc.)

Naturally, combining Java Card applets and GlobalPlatform security domains, every application gets its own little home in the home gateway. One interesting remark is that the smart card becomes a one-stop shop for people who want to deploy new applications into the smart meters. But then, this raises the question: who controls the smart card in the smart meter? In a deregulated market like in the UK, this question may not be as simple as it seems.

An important point is that applets may address some privacy issues by performing some basic processing directly in the home, and to only transfer select information (for instance, when blood pressure is over a given threshold).

In the architecture, the smart card is pretty much in control, and they have defined a SIM Toolkit-like way of working, in which the smart card provides the terminal with instructions about things to do, like send this data to the outside, or wake me up for the next measurement 24 hours from now.

Java Card 3 Connected would also allow the user to access its own data directly from a Web browser. This provides a partial answer to one of my favorite questions: Would the (younger) family members be allowed to get the information? They have more incentives than clinicians to actually use the information, and such a use raises very interesting security issues, and even more interesting privacy issues, because the elderly have a right to privacy, even with respect to their children.

Surprisingly, the main problem is here to be ready on time, because in many countries, the deployments are scheduled before 2020, which is awfully close when you don’t even have a specification.

Good luck to this project!

Here’s a grabbag from Internet today. First, the good side, with two Microsoft articles pointed by Bruce Schneier:

• The first one is about the authorization dialogs that we face when an application, native or web-based, requires us to take a decision. I was discussing recently with a colleague the fact that these dialogs are sometimes very technical, and that most people are likely to take a decision based on the reputation of the developer or their envy to see the application work. The article is very interesting, and it outlines the interest of graphical interfaces, with icons. It also serves as a reminder that security is often about getting the user to understand what it is about.
• The second one is a bit more specific, and looks at how we can allow an application to use device sensors, and in particular, cameras. Once again, the trick is to make sure that the user is aware of the use that an application makes of a sensor, in particular when it may violate the device owner’s privacy.

These works are interesting, and shows that Micrososft cares about them. However, since they are advanced research works and they are not very conclusive, they also show that the road to good security interactions is going to be long and bumpy.

On the bad news side, there seems to be a surge in fraudulent premium SMS’s (in French). This time, apparently, the fraudsters are sending a SMS that contains a URL, this URL points to a Web page that opens in a browser, and one of the links in this browser triggers the sending of a multimedia message to the victim’s mobile, which is billed 4,50€. I haven’t seen the thing directly, so I don’t get it directly. However, I am a bit curious of the code of this Web page, because I don’t know how a simple click can cost me 4.50€ without me entering any data, and without a direct link to my operator.

Maybe that the solution is in another piece of news. Orange is making some effort to attract developers with APIs, and these APIs seem to cover messaging among other things. However, looking at the definition rapidly, I did not find a way to bill the user.

All of this leads us to an interesting and potentially dangerous future. With BONDI and the like, the boundary between local and web-based applications is going to become very blurry, and all these applications will be able to use and abuse a lot of sensors and billing systems.

I think that I’m going to look into the static analysis of Javascript one of these days. And all this research in security user interfaces is really becoming important.

I got all excited, clicked on the Android button, scanned the QR-Code, and Android Market opened. Things were looking good, but the application was not found. That looked strange, so I went back to the Android page and read the text.

Works with Android version 2.0+

Now, I feel bad, really bad. There is an iPhone version, that I could load on my iPod Touch. But then, a barcode app that I can only use at home by entering the digits is just not fun.

Now, not everything is bad, but it doesn’t look very good:

• BAD. It doesn’t work on my phone.
• BAD. I have no clue if I will ever have the opportunity to upgrade to Android 2.0+ on my phone.
• GOOD. It didn’t allow me to load the application and be disappointed.
• BAD. “Not found” does not properly describe the problem in the app store.
• BAD. It seems that even today, some phones are delivered with older versions of Android.

This is just the beginning: versioning is pretty easy to do. I still remember the first application that I got on the Android Market, which tried to address the physical keyboard that my phone doesn’t have. This gets me a bit afraid about future NFC APIs: Will there be a reference set of APIs to be included? Will they include both a way to address the contactless interface and the Secure Element? It would be nice to have a regular interface on all devices. Gemalto has joined OHA (in the Semiconductor category, which sounds odd, but I guess that the other categories are no better fit), so something is bound to happen at some point. Let’s wait and see.

P.S. If one of you can actually try stickybits, let me know how the thing is. App Store comments seem to refer to privacy issues (everybody sees what you have scanned), which sounds interesting, as it shows room for improvement.

One of the promises of such a deployment is over-the-air renewal of monthly passes. Today, this is handled through long lines in the stations, every month. With NFC, you can see at least two ways to improve that.

• The classical scheme is to load directly the Navigo application on the phone’s SIM card (or any other security element), and to use it through a combination of NFC (for everyday use) and over-the-air SIM Toolkit access (for management over Internet).
• Another scheme is to use a NFC phone as a Navigo card reader, and to update the card information through a mobile application (Java ME supports that, for instance).

RATP has decided to move on with the second scenario (I have a link, but only in French). Of course, since NFC phones are not available, they are issuing card readers, provided by Gemalto.

They are not waiting for Godot NFC.

The sad part about this news is that the lack of readers in homes was already used 10 years ago to justify why smart cards were not used at home. The good part about the same news is that some major actors like RATP are now deciding that it may be worth investing a few euros in a reader for an interesting service that saves time in lines.

In addition to the obvious benefit of the application, RATP is also using it as a way to slowly ramp up their capacity to manage a large number of online transactions on their card management systems, so they can be ready when NFC devices finally arrive massively.

Another funny part comes from the comments, which range from “Card readers are useless” to “Card readers will be hacked” or “Card readers are too expensive” (15€, apparently). A few good questions, though, like “I already have a reader; can I use the reloading service?”. Some ramblings as well, like the guy who claims that “a card that can be rewritten, that’s the security error, with no authentication”.

I don’t think that these guys will do much harm to the Calypso application used by RATP, which is not as insecure as they think. And having 100,000 more card readers around Paris will not change that. However, having a few hundred million contactless card readers (a.k.a. NFC phones) can definitely make it easy for would-be hackers to try something on their cards. Sprinkle a bit of Internet access, and you’ll better have applications with no blatant security issue.

Well, that should keep us (smart card/security guys) busy for a few years.

I have been looking for a such an application for a while for my HTC Magic, and the first one I found (My Tracks, from Google) wasn’t great. It had the same sloppy look that many Android applications have, and the online site really reminded me that it was a prototype from a research team rather than a real product.

My new application is SportyPal. It is a port from an existing iPhone application, it works well, it has a godd-looking Web interface (here is an example), and it was even free.

I consider this really good news, because it means that some companies are feeling that Android is interesting enough to port their iPhone applications.

Maybe that my next step will be to actually buy an Android application …

So what? Well, I started programming something, which happens to be a game for my 3-year old son, currently passionate about spelling and recognizing words. And that brought me back to my natural, geeky state, busy in front of my keyboard on evenings. So now, I can tell you about my first experience as an Android programmer.

Of course, I started by reading a bit. Actually, I did that a few years ago, trying to figure out how Android worked and its security was organized. I did it some more specific reading, though, in the “Hello, world!” category, just to get started.

Then, I upgraded Eclipse on my home computer, got the STK, and started it. It works fairly well. In the first evening, I mostly learnt about what an Activity is and how to use it, and what I got was actually very close to my game’s main screen:

That’s a nice result for an absolute beginner after 3 hours of work, and it motivated me to start designing the thing a bit better. One or two evenings later, I had a menu:

Do the icons look familiar? If you own an Android phone, they should, since they all are default icons. I thought I would do my own icons, until I looked at Android’s Icon Design Guidelines. Now, that reminds you why real application development is team work. I can do a few things with The Gimp, but I know already that even a simple icon will take a lot of time.

The menu, though, took no time at all, at least as long as I didn’t try to put anything real behind it. The first thing I did was add a few options. That took me some time, but this is all XML-based, and it works really well. It actually took me more time to type the string constants than to write the class that make the options accessible to the rest of the code. However, I have to admit that, in order to achieve that, Google has been very useful, this time as a search engine, finding other people who had solved the same problems. One or two evenings, and here is what I got:

The next challenge has been to organize my data. After hesitating a while, I skipped the database for now, because my data looked a bit trivial, and a database didn’t really seem like the right thing to use for this application. I may regret my decision, but at least, I tried to encapsulate things a little bit to make the pain acceptable. The next step, that I expected to be extremely simple, was to build a list in which each element was made of a checkbox and a name, to select the categories of images to be displayed, like this:

How do you specify this? In the simplest way possible: a list of hashmaps. More precisely, in Java, a List>. Not a big deal for a standard programmer, but quite a trauma for a Java Card guy: “You mean that every stupid list displayed requires a list of hashmaps? Okaaaayyyy”. I felt really old for a while, but I went over it.

This is basically where I stand today. My next challenge is to be able to figure out whether or not my checkboxes are checked, which seems like it is easy. My data structure just happens to be wrong, which will require a bit of refactoring. With the summer, the visitors on our beautiful Côte d’Azur, and the upcoming Bastille Day fireworks, this may take a while, though.

More impressions as an Android user in a few.

This particular application store is far from new, and it has been quite a success, working in good intelligence with operators. Of course, it is not very well known in Europe, but Brew is a dominant platform in the CDMA world, and in particular in North America. The Brew store has been generating significant revenues in the past 8 years, which gives Qualcomm a significant experience in the field, and they now want to leverage this experience by offering a global service.

This service is aimed at other platforms, like Java ME, Flash, Blackberry, and later Android, Windows Mobile, Palm, and LiMo. Quite an impressive lineup, and most likely quite a few technical challenges to be addressed as well. Distributing content for all these platforms is not simple, as the constraints are extremely varied, for instance regarding application signature.

Of course, this service somehow looks like Vodafone’s application store, especially as Qualcomm usually goes through operators to market its application store, so their store will become the store of many operators.

Two last things. First, Apple is not mentioned in the list, and it is about the only significant platform not to be mentioned here. Of course, Apple has a strong competitive edge today, and developers are eager to work on their platform. But as touchscreen phones become more common and global application stores become able to reach billions of devices, Apple will need to remain very active in order to keep all their developers.

And last, I have the secret hope that all these application stores will encourage the development of many applications. And since they will not all be nice and clean, there should be a new window of opportunity for static analysis in the mobile application fields. Hopefully, I’ll be ready.

Well, maybe not, or at least not immediately. In order to be really interesting, these applications will be able to use specific Vodafone APIs, which means that they will only work on specific Vodafone-branded phones: pop, another silo!

Whatever happens, this remains an interesting novelty. Once they have an application store, Vodafone is quite likely to look for any possible extension of the store, and they may end up competing with some other app stores. In addition, other operators may follow, like China Telecom, who seems to be really interesting in a branded store.

And finally, I have not looked yet in details at the Vodafone app model, but it seems to be widget-based, and the home page for developers has pointers to the W3C Widget spec. If Vodafone starts supporting standards, the game could become really interesting, since standards are likely to be accepted on many phones.

The funny thing is that this product is really, really far from perfect. First, it is not transparent: the rules for accepting and refusing applications are unclear, leading to many controversies, and the tools used in the application review process, if any, are not available to developers who prepare their applications. Then, it is a closed product for a closed range of devices, for a closed community of developers using a specific closed type of machines; in brief, it is not very open.

But in the end, the Application Store is wildly successful. And in the end, this is what really counts, especially in a market where all previous attempts have more or less miserably failed.