Amazon started with the books, as all my Kindle books are stored online, with all the information, and can be instantly retrieved anywhere, anytime. They are now moving to music, which consumes significantly more storage and bandwidth. Video is probably next. Now, will they stop there, or will they move into other types of content, like office documents?

Another interesting thing is the mobile client. We know that Amazon is a friend of Android, especially since they have launched their own Android application store. However, they have gone a bit further here, since the Amazon Cloud Player is only available for Android for the launch. No iOS version at this time, which is quite a bold statement for a product that launched only in the U.S. Of course, an iOS version must be somewhere in the works, but Amazon knows that, eventually, Apple is not going to like their competition. After all, loyal iTunes customers can now upload all their iTunes music into Amazon’s Cloud, and stream it. Maybe an indication why they can only do that on an Android device: It’s a free world.

Disagree with http://bit.ly/hq5J6H on raising entry fee of #android dev: organized gangs will still pay. Genuine individuals no.

It sure sounded to me that I agreed with Axelle, and not only because I plan to register as an Android developer one of these days. I checked on the proposal on the naked security blog, and it confirmed that I do disagree with them. Making developers pay for submitting and testing an application is a bad idea; this is what mobile operators and other application distributors were doing before Apple’s App Store, and it didn’t work, because it increasing artificially the cost of developing applications. The cost of vetting an application is an App Store cost, and the idea is that the revenues from the store should cover this cost. Of course, this may not be very easy for Android Market, because their revenue is lower than Apple’s store revenue, but it nevertheless remains their responsibility.

Making application development accessible to developers always makes it just as accessible to hackers and malware developers, but this remains the way to go. If you consider Java Card, it has never been really accessible (just try to get sample cards to run a Java Card application, and you’ll understand what I mean); hackers have largely stayed away from it, and so did developers: creativity on the Java Card platform is dismal, and it sure doesn’t come from independent developers.

So, what can Android Market do about these deliverables? Well, like we said before, vetting is a key element here (i.e., having Google analyze the applications carefully before to actually put them on the market). This is a part where Apple is far from transparent but potentially efficient: few people know the kind of vetting performed on iPhone applications. Of course, malware developers can test concepts, but the opacity of the process allows Apple to update it rapidly when malware is detected.

Let’s follow a few of Crypto Girl’s suggestions, on her Fortinet blog, and on IBM’s blog, to get a few more technical detail. These reads are quite interesting, because they show how the exploits have been embedded in the code. I am not an expert on Linux exploits and I may be wrong, but I have the feeling that a static analyzer could identify a few things that would trigger a security analyst’s interest.

As a lot of people mentioned in the past months, there is increasing interest for mobile malware, especially around Android and iOS, and we expect a race between the good guys and the bad guys. What worries me a bit here is that I don’t see much sign of Google engaging in the race to protect Android. Applications like DroidDream should be caught and rejected before they are released, rather than recalled after being downloaded by thousands of developers. Let’s hope for Google that they get serious before their Android Market becomes completely discredited, because Android is an open system, and competitors could show up.

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.

Basically, this attack shares the following characteristics with many other ones:

• Exploit Android permissions. Android permissions are very wide, and labeled in simple terms. This means that there are many ways to abuse people, especially with combinations. In that particular case, the use of two collaborating applications is a way to hide combinations, but it also makes the attack more difficult.
• Use a side channel for leaking data. Some side channels are obvious (like leaking data on Internet together with other data), and this one is trickier. In fact, there is always a tricky way to leak data, especially when you can do it one bit at a time.
• Be a proof-of-concept. This malware works, but only in a lab. In the real world, it needs someone to download two pieces of malware, dial a credit card support hotline, type a credit card number, and do that for another reason then blocking the card. Possible, quite unlikely.

My main claim is that such a malware is quite unlikely to represent any kind of danger. The scheme is so complex that by the time people get credit card numbers stolen, the malware is very likely to be detected. My second claim is that the Android permission system is not worse than the others around: iOS doesn’t really use permissions, MIDP uses overly detailed ones (granted by network operators in most cases), etc. My third claim is that what really count is that the Android Market is able to vet applications; even if it doesn’t do much today, we can rest assured that Google will make sure that 2011 doesn’t become the year of mobile malware.

Nevertheless, the paper points a few interesting things about Android permissions, and some of them could be fixed:

• The Read contact data permission gives access to the call history. I am not sure that I see the need for that. In fact, my main issue with that is that, in terms of privacy control, I believe that it’s very different to know who I know and who I actually call. I believe that this one should be fixed.
• The Record audio permission allows an application to record the content of phone communication (as well as recording audio in the background, actually). In fact, that’s again a privacy issue: an application that records audio while it is the currently running application is fine; allowing that application to record audio from the background is a very different thing, which worries me. This one also deserves to be fixed.
• The side channel actually doesn’t use any permission in most cases, since it uses channels that don’t require any, like setting the volume repeatedly. Here, I don’t think that there is a big problem, because getting data out is most likely not the main problem today. Five years ago, everybody was worried about connected applications; today, most people consider it normal for an application to be somehow connected to the net (for instance, an application can always claim to backup things, to have a social side, etc.). Malware doesn’t need to be bundled with sensitive, intelligent software, so complicated side channels probably represent a futile complexity.

To conclude, a word about hidden communication channels. I have worked on information flow static analysis, and we haven’t found many practical ways to identify hiddne information flows. Usually, these hidden flows do not use variables or communication APIs to leak data. Instead, they often leak a trickle of information using either an unnecesssarily convoluted computation (which is likely to attract the attention of a human reviewer, but is difficult to find for a static analyzer), or by looping on an apparently innocuous API method (this is what is done here, and we may have detected it using a static analyzer).

Connecting home appliances sounds kind of obvious, and the ubiquitous availability of smartphones and tablets makes it even more obvious. I have many times left my clean laundry sit in the washer for hours, just because I turned the thing on and forgot about it; no doubt that a message on the phone in my pocket would be a welcome reminder.

The devices shown by LG seem to be rather high-end stuff, with rather large LCD screens for the interface (and no buttons, so these screens must be tactile). Apparently, these devices are running Android, which could mean that we will soon find Android applications targeted at washers and refrigerators. This is great news at least for one point: I have no doubt that independent developers can imagine applications on appliances that LG wouldn’t dream about, and opening this market could lead to real improvements.

Now, I am wondering: do we need a smartphone in every home appliance? Do we need a 7″ screen on every appliance? A few rich geeks may answer yes, but most people are quite likely to stick with much simpler interfaces and cheaper electronics. You may have guessed already where I am heading: Java Card 3.0 Connected is the way to go. It has many qualities required to do that:

• Web-based application model. A Java Card 3.0 servlet can provide the required communication link between an appliance and the controlling device, using a fairly simple and well-known application model.
• Dynamic management of applications. With the addition of GlobalPlatform specs, Java Card 3.0 supports a wide range of application management models, and it could in particular be used in an application store model. For those who doubt, we can remind that the Java Card/GlobalPlatform is already used on a few billion devices, so scaling up is not a major issue here.
• Small footprint, possible single-chip integration. Adding a full Android device to a US$1,000 washer is not a big issue, but adding the same device to a US$100 coffee machine will have a significant impact on its price.

Of course, it lacks a few things, in particular regarding I/O’s. In order to control an appliance, Java Card 3.0 needs to be able to control a few I/O ports, including a small display. But these APIs already exist in other embedded Java dialects such as MIDP, so why not doing it?

The bottom line is here that we can achieve with Java Card 3.0 Connected results that are quite similar to what is possible with Android, while making it accessible to a much wider range of devices. The only question is: Who is going to define the few missing APIs and make a reference design for a network extension board for appliances? I would definitely like to be part of that, but I’m not the one who will do the electronics part.

First, the upcoming Nexus S will support NFC. This is big, because one of Google’s objectives (the main one?) with Nexus phones is to provide a reference design for Android devices. And now, NFC is part of that reference design (and of Gingerbread, Android’s upcoming release).

Then, Eric Schmidt talked about NFC. He started by a tag reading demo; of course, it didn’t work, because the network was too slow (typical in such environments). He gave a little description, and then switched to contactless payments, even mentioning the use of a secure element. Now, that was nice: Google is not only thinking about reading tags.

Later in his speech, he mentioned how the combination of location-aware, tag reading and mobile payment could change the way commerce works, using terms that would have been largely appreciated at a NFC conference.

To please me even more, he even threw in a mention of voluntarily provided information, which is of course limited by the fact that Google is an unlikely VRM supporter. But yes, if the system is able to integrate that I am actually looking for a new pair of pants, it may provide me with very useful information.

Finally, Eric Schmidt went as far as mentioning security several times, and even saying that “the technology has to be secure,” which is nice to hear for many of my colleagues. And his reason is rather simple: there is money involved directly, so security is a must.

One of the best parts of his vision is to remind us that mobile is personal, secure, and an aggregating technology. So when we think about what we can do with NFC or whatever we add to that, we need to figure out what it brings to the big picture, and how the technology can best be used with all the other mobile technologies.

OK. Enough ramblings. Here is an approximative transcript of what he said about Android (a bit raw, so if you have 10 minutes to spare, take a look at the video):

Q: There has been a lot of talk about a new operating system aligned with a potential hardware device, coming from Google. We’d love to see it if that was possible.

ES: OK. How about instead a demonstration of some software.? So, I happen to have here an unannounced product that I carry around with me. That is an Android device, and we have taped over its origin.

You see, this is a placemark [showing a placemark panel, obviously with a tag in it]. The neat thing you could do with this new technology called NFC (which stands for Near Field Communication), and we think that Android should support that. It’s been around for a while, by the way.What you do is, these are chips that are embedded in things, eventually in clothes to prevent people from stealing. These chips are senders, and we are incorporating support for the reader-writer, so the way it works is you turn this thing on and you basically just tap like that, and it tells you, in the particular case, where you are.

What’s neat about the NFC chip is that the whole notion of location takes an entirely new meaning, because now I can just tap, I don’t have to take a picture, I don’t have to scan a barcode.

Q: So this is basically gonna be in presumably many of the new Android phones.

ES: It’s actually gonna be in the new operating system called Gingerbread that comes out in the next few weeks. So we think that the overall mobile market, which is already extraordinarily excited about these payment systems, will benefit from having those, because it is a secure element, and the secure element really is very hard to steal if you will.

Q: So, the secure element allow you basically to do payment.

ES: One way to think about this is that is that it will replace your credit card. The term of the industry is called tap and pay. The theory of the case is that you will be able to take these mobile devices from everybody, to walk into stores, do commerce, you’ll be able to figure out where you are, again, with your permission, all that kind of stuff.

Q: Effectively, bump for everything.

ES: Yes, bump for everything, and eventually, replace credit cards.

Q: It also turns the phone into a much more powerful form of identification.

ES: It’s an example of what I have talked about for a while, which is “mobile first”. I don’t think that people understood how much more powerful these mobile devices are going to be than the desktops. You think of the desktop machine as having all this power and tremendous network, beautiful screen, but because these things are so highly personal, and because they are location aware, …

Q: They also have network

ES: Yes, with LTE networks coming to the United States, first in the world, for a change, roughly in January-February around the country, it is a really really god day for mobile.

Q: With the theme of points of control, it strikes us that one of the points of control is having tons and tons of credit card numbers; Amazon has tons, Paypal has tons, Apple has a lot. Combined with this kind of technology, it strikes me that it could possibly change the game. Do you agree with that, and where does Google stand with that.

ES: Well, we see ourselves as a technology provider in this, we’re not trying to compete in those spaces, but ultimately this technology is personal, it’s secure, and it’s an aggregating technology. So it makes sense that you put everything in it and carry it around. It has to be secure, because it’s obviously going to be used as money repository.

Q: But still, if you are doing payment, somebody is doing the payment processing.

ES: There are industrial partners for all the initiatives in the industry, with very sophisticated payment processors, and regulations, and all

Q: You expect to be a partner there rather than …

ES: Absolutely.

Q: But you do have Google checkout.

ES: Remember, Google checkout is just a piece of this. Payment processors do something different. They actually deal with the merchants, moving the money around, you know with fraud and so forth. The reason why this NFC dhip is so interesting is because the credit card industry thinks that the loss rate is going to be much better, because they are fundamentally more secure. And ultimately, the money that brings us all to this wonderful venue comes out of commerce in one way or another; advertising in Google’s case. My guessis that there will be 500 new startups in the mobile payment space as these platforms emerge, with all these new and interesting things that we can do.

Q: What I’ve been fascinating by is the idea that this is gonna change is shorten the loop between the search and acquisition of a product. Right now, we see this in buying an app: you search for the app and then you buy it on the phone. But this really makes it possible in the real world. You can search for something, and …

ES: But, forget search. Well, I shouldn’t exactl say that, but that’s a joke. Imagine I am walking down the street, and instead of typing my search, my phone is giving me information all the time, and it happens to know that I need new pants or something. You can imagine all sorts of linkages between autonomous search, and location-based search, where you are, where your favorite stores are, what your preferences are, again if you opt in to these situations. Its likely to drive a very very large mobile commerce business and mobile e-commerce business. And the scale of commerce is 14 trillion dollars, which is the global GDP, so some large amount of money is to be gotten in these new platforms over time.

Q: And you can really how this could be a fabulous tie with groupon, because it tells you that there is a crowdsourced offer.

ES: Again, if you look at groupon as a very good example of a very very successful local merchant, they today use e-mail as their primary acquisition mechanism, but they have competitors which are using other techniques. What we know is that people like a deal.

Q: One last question on Android. What are you dissatisfied about with regard to the platform, and what do you think need to be fixed, if anything.

ES: You score Android against the historically leader in the space, which is the iPhone, and I do this as a proud former board member of the Apple world. There is a set of things that the iPhone really did a brilliant job of bringing out in a closed system. Brilliant design, the app store, the platform and so on. So most people judge Android by how we are doing relative to that. And it’s clear that from a reach, choice, and so forth, we are in great shape. The next real focus is at the applications layer. So I think that if I want to be critical, I would have liked to put more emphasis on the application side earlier. It’s hard, because remember, the application decisions are made based on developers, who do it based on volume. So you have to establish volume first, which is something that I think we have done with Android. And for all of these players at the third-party level, and again I know that we have a lot of developers here in the audience, it’s fundamentally about the math of the platform. So we understand platforms very well, we think that Android will be, if not the leading platform, a leading platform.

Q: That brings up a question that I have been thinking about. As there are more and more applications, it becomes a search problem to figure out which one to choose, and that’s one of your sweet spots. But you don’t have some of the same mechanisms for identifying the best apps. How are you thinking about search as a competitive advantage as the application space grows, where the Android Market is the Google of the app space?

ES: We don’t think of it as a competitive edge, we just try to do it better, and the competitive environment will win. As a comment, I think people are obsessed with the competitive landscape, where what they should really be focusing on is how much bigger the market is getting. And because it’s, including the leadership that you guys did with Web 2.0 so many years ago, this is a very large universe, that is getting much larger very quickly, bringing more and more people into it. So the competition is healthy, what’s really happening is you’re growing the market. So with respect to the applications and application search, there’s all sorts of interesting ways of doing that; Admob, for instance, is doing on the order of a billion ad impressions a day now, and that kind of information, in theory, is useful as part of a search problem, because ads have a real value, and we really believe that. There are many many ways in which the information people are using, usage patterns, can be used to provide better choices. But you’re correct that these markets tend to overcorrect; They have millions of apps, whatever, but then ultimately, the leaders emerge.

Q: One of the things that Steve and Apple did right is the about divorce from the carriers, the ability to pretty much say: I don’t want your stuff on my phone. Do you think that Android is ever going to be truly free of that …

ES: I certainly hope so, in the sense that the Android model is different from the Apple model, very distinctly on pretty much every point. It’s open system vs. Closed system, and closed systems have their advantages, and open systems have their advantages. Google made a bet on open systems. We are willong to let the vendors, the carriers, and so forth, set their pricing, set their distribution terms, and so forth. I think that ‘s the right model.