The Future of Android

I read a really interesting Article on the growth of android over the past years. It also introduced some new products that will be hitting the market with android’s new ice cream sandwich os. The article talked about androids rapid growth and shows that it now holds 53% of the market. Over the past year android grew 11% from 42% and continues to be the most popular mobile operating system. This article continued to talk about a few new products that will be hitting the marked with android.

1)                   Shows a designer phone made by prada. Android it’s getting a new pretty face with this phone. Prada is trying to remove the nerdy geeky appeal of android and go for the fashanistas if you will.

2)                   The next is a $100 tablet. This caught my attention because it was exactly what the guys from one laptop per child were talking about. It will be interesting to see if it is really below the $100 bar. It states that the tablet will also have all the goodies. Camera, long battery life, nice size (tim’s favorite size 7inch). If a tablet with that amount of usability is released for under 100 dollars that could completely change the mobile market, making android readily available to almost everyone.

3)                   EE Pc will be replaced with a tablet linking to a keyboard to make up a small netbook! This would really give the user the best of both worlds. You could have the tablet for on the go and a keyboard to make typing and searching a breeze. I’m really excited to see how this android powered tablet/netbook will do in the next year

Finally the paper talks about Adobe changing its direction with flash.  It will no longer be aiming to support flash on mobile devices but aim for html5 and adobe air in native apps. This also caught my attention because one of the articles we read this summer was about html 5 and if we thought it would start to take over. I remember I was cynical and now it looks to be happening.

Article

 

Understanding Single-Handed Mobile Device Interaction

A while ago, I took a class with Rick Alterman and learnt a coupla things that computer scientists need to understand before and while developing software. I was particularly drawn to  understanding how human interaction with devices affected various aspects of cognition. I  found this article( http://hcil.cs.umd.edu/trs/2006-02/2006-02.html) somewhere and thought I would learn a bit more about this subject. The article speaks of one of the  major challenge faced in the design of mobile devices . The paper mentions that main problem is that mobile phones are typically used when the user has limited physical and attentional resources available. The paper clearly illustrates how this has been so, and sheds lots of light on factors that lead to single or two hands use of a device. I like the analysis and the narrow scope of cognition that the paper focuses on. As much as they acknowledge that designs are done after some survey, they emphasize that most features inhibit single-handed use,  and there has been relatively little systematic study of enabling technologies and interaction techniques. I think that mobile device size should  not a factor in how quickly users can access objects within thumb reach. The design however should make it so easy for the user to manipulate the device and get most out of it. All in all, an impressive design aids in skill acquisition and makes users optimise their devices

The future is here, and the main thing we have to worry about is our battery life.

In “Micro-Blog: Sharing and Querying Content Through Mobile Phones and Social Participation” (henceforth – “the paper”), Choudhury et. al. (henceforth – “the authors”) present a compelling vision of a unified method for (local and ad-hoc) community dialog in both virtual and real space.

Magazines like Wired and Popular Mechanics have been excitedly predicting the digital “tagging” of physical locations for years. For a while, the enabling technology was going to be RFID tags. Before that, barcodes. Now, the ubiquitous mobile phone / mobile internet combination will deliver us into this promised land.

The vision that the authors present is reasonably compelling – people can “report” on anything they want, and automatically tag their location as they do so. Using that, others can use their traditional computing devices to collate data, ask questions about a location to anyone who might happen to be in the area, or adjust their settings. Lastly, users can subscribe to blog “channels” that might send them audio reports whenever they happen to be in a specific area.

Given the promise and potential of this setup, you might expect the authors to dwell on the possibilities of their creation. Instead, the plurality of the paper is spent on an arcane and technical discussion about the difficulties of balancing battery life and location integrity.

Why the digression? Well, an observer might flippantly say “this proves that the paper was written by engineers, and not sociologists,” and she would have a point. However, I’d like to go further. This setup has applications for journalism, politics, community organization, pedagogy, business, and other areas. The potential is staggering, while the actualization is likely to be rather small (most start-ups fail, after all). Rather than trying to cope with that dichotomy, the authors found it safe to retreat into the minutae that is more easily grasped.

Beyond that, a few passages in the paper caught my attention.

“Unfortunately, colluders could also initiate bogus queries and responses to artificially inflate their query totals. We draw upon existing graph theoretic approaches to address this problem. A directed link between two nodes, (i, j), can denote a query; the cost of the link can represent the number of queries from i to j. If a clique of nodes are identified such that the cost over all the links are greater than a threshold, then these users will be under suspicion of misbehavior. These users can then be penalized either through a reduction in their query credit, or by some other mechanism.”

This was maddeningly vague. Which approach in graph theory are they using? Why does this trigger (the cost over all links in a clique is greater than a threshold) work?

“How- ever, with commoditization of mobile phones, applications and services will play a critical role in customer retention. Trends show that services will be offered free to customers, as a value added package to basic voice communication. Micro- Blog is envisaged to be one of the applications included in such a package.”

Here, like in a previous paper (Mist? Argos?) the cost of internet plans is acknowledged as a limiting factor, but handwaved away. Sure, it’s not the author’s job to fix our nation’s broken telecommunications landscape. Hell, one of them even works for Verizon, a company which is both a symptom and cause our dysfunction. Still, rather than pretend that a rosy solution will magically appear, perhaps they could acknowledge reality when it is staring them in the face.

Thirdly, the long discussion about the battery-draining problem with location-aware services makes me think of the problems with HappySad. I know I was upset that Google’s proposed method of dealing with location was overly cumbersome, but it seems that was because no one has found a broadly-accepted method of balancing battery life with location accuracy, not even Google.

Lastly, the spam ‘solution’ tries to deal with spam by artificially restricting /consumption/ of media. Yet, this can’t take care of the problem by itself. They need to deal with the /production/ of spam as well. Then again, mobile phones are harder to come by than IP addresses, so perhaps the spam problem will be easy to deal with through the simple methods of community rating and bannings.

Challenges in Android Security Pt III A look at papers past

Paper: Designing System-level Defenses against Cellphone Malware

Though this paper was written relatively recently (2009) it seems to be from an age long-gone, an age where you could do research on Symbian phones with a straight face, and where you could refer to “linux-based smartphones” without necessarily meaning Android.

This paper continues the transition towards understanding the Malware threat model instead of just focusing on the phone’s active security features. It focuses on two “malware attack strategies:” launching a new process to do the dirty work, and hijacking a legitimate process and abusing its access rights.

For vector one (launching a new process), the paper notes that the Symbian and Windows Phone OS’s have poor to no access control, and launching a new process is simple, so the majority of attacks use this method. It also explicitly assumes that the kernel is secure because there have been no mobile rootkits.

Oh, what halycon days. Now, of course, mobile rootkits are a reality, and most attacks come from vector 2: hijacking existing activities or processes and using their rights.

To deal with these two attack strategies, the authors propose an SE-linux inspired access control model, and what they grandiosely call an “Artificial Intelligence Technique called a Graphic Turing Test”. In other words, a CAPTCHA.

Reading the paper today, we see that Android does have a robust access-control model similar to SE-Linux, just as they were proposing. The CAPTCHA, thank goodness, hasn’t seemed to take off.

Tags: security

Challenges in Android Security Pt II

The paper: “Andromaly”: a behavioral malware detection framework for android devices

The previous paper relied on a static analysis of application binaries to root out threats. It used the argument that a constantly-running monitoring software on the computer would take up too many system resources to be feasible. The team at Ben Gurion University want to prove them wrong.

In the “Andromaly” paper (Israeli academics seem to love cutesy names for technologies they come up with), they present a “framework [that] realizes a Host-based Malware Detection System that continuously monitors various features and events obtained from the mobile device and then applies Machine Learning anomaly detectors to classify the collected data as normal (benign) or abnormal (malicious).”

Pretty cool, huh? Unfortunately, despite the well-publicized android malware that Google has been detecting since August 2010, they couldn’t get their hands on any to train the machine-learning algorithm, and had to create 4 malicious apps by hand.

In addition to the bad “training” sample for malware, there is another big problem. In order to avoid false positives, the detector will only raise an alarm after repeated suspicious behavior. While this repeated behavior happens in seconds, not days, one focused burst of action will not trigger any alarms.

This paper only came out in January of 2011. I can’t wait to see this project mature.

Tags: security

Challenges in Android Security Pt 1

Paper title: Using Static Analysis for Automatic Assessment and Mitigation of Unwanted and Malicious Activities Within Android Applications

So by now we all understand the Android security model. If not, check out this paper for a quick primer (the premise of the paper itself is rather weak. They just propose a new security service for Android without doing any of the intellectual or engineering codework to get it off the ground. But to pad out their useless paper they did do a good job of explaining how the Android security system works.)

This model has many problems. One of them is the following – the permissions structure is a static, take-it-or-leave it affair with coarse controls. In other words, you’re only asked once for whether to allow the app to do all sorts of things, you can only either approve or deny it (there are no options), and the sorts of categories that you can allow (eg “check phone state”, “access the internet”) are too broad.

In the Static Analysis paper, the authors found a way to get around this. They created a program to automatically decompile apks, inspect them, present the information in an understandable way to the user, possibly patch insecure code, then recompile the apk and install. That’s pretty neat, huh?

Reading the paper, I was pretty amazed by the relative ease they could interpret the “decompiled” code. I’ve always thought of reverse-engineering code as super hard, but they made it seem so easy!

In action, their system might notice that an app the user just downloaded (and is about to install) reads the phone number of the user, then sends an encrypted stream to a server right after. It can notice that pattern in the binary, before installation alert the user, and then patch the binary so that a fake phone number (or UUID) is sent instead, so the user can still use the functionality of the app without the privacy invasion.

This is just one approach to Android security. There are others, and I’ll get into at least one more of them.

An approach to the diversity of smartphone usage

I chose an article that focused on one of smartphones major problems: battery life! (URL: http://enl.usc.edu/papers/cache/Falaki10.pdf )

We all know that smartphones are amazing and can offer endless entertainment and utility, from managing your email, getting gps directions, to hardcore gaming and streaming videos and music. The only drawback is that our modern day battery hasnt caught up with smartphone technology and at best lasts 24 hours, but usually falls short.

To clarify, this article does not deal with the technological requirements needed to create a better battery. Rather, the article focuses its attention on the necessity to create better and smarter software that learns from a users behavior patterns to manage the phones energy consumption.

To clarify once more, the article does not actually delve into any technical theories or research on creating this better software. Instead it presents research done on 255 smartphone users and the types of data usage recorded for them. The results? You guessed it, everyone uses their phones differently! The number of applications used over the course of the study ranged from 10 to 90, the number of data used per day ranged from 1 to 1000 MB, and the number of sheer phone interactions used ranged from 10 to 200! These data points were gathered by the researches software that recorded the internal interactions. For example, for us android app developers, to record app usage the research recorded every time the onStart onRestart onResume onPause onStop and onDestroy methods were called to gather the appropriate data.

The conclusion is that there is no one size fits all energy consumption manager. Rather smartphones need software that will adapt to users usage of the phone to give users the best experience of being able to use the phone for what they want, and not have to worry about their battery running out in the middle of the day.