Mark L. Murphy's Blog, page 71

The DMCA, the Play Store, and You

The generally-reviled Digital Millennium Copyright Act (DMCA) has long been applied to apps out on the Android Market/Play Store. Sometimes, the complaints are legitimate, sometimes not. However, a recent thread on the android-developers Google Group suggests that there is may be a significant flaw in the system and how Google is handling it.

The DMCA uses a notice and counter-notice system. A notice causes someone like Google to block access to purportedly infringing material; the counter-notice requires the block to be revoked. However, section 512(g)(2)(C) of the DMCA provides a loophole for the party filing the notice:

unless [the service provider’s, e.g., Google’s] designated agent first receives notice from the person who submitted the notification under subsection (c)(1)(C) that such person has filed an action seeking a court order to restrain the subscriber from engaging in infringing activity relating to the material on the service provider’s system or network.

IOW, if the person filing the notice says that they are suing the purported infringer, access must be blocked again, with no actual provisions anywhere to undo the final block.

Also, much of the details of the implementation of the notice, counter-notice, and the filed-action claim are left up to the “service provider”, which is Google in the case of the Play Store.

According to the person who started the android-developers thread, Google received a DMCA notice, received the counter-notice, and then received a filed-action claim, thereby blocking the person’s apps. However, there is no evidence, from Google or anyone else, that the entity filing the notice actually has “filed an action seeking a court order to restrain the subscriber from engaging in infringing activity relating to the material on the service provider’s system or network”.

This, alas, seems all too plausible.

Perhaps someday laws like this will be rescinded, or amended to put penalties on fraudulent filings. Or, perhaps a few class action suits to stop DMCA-based racketeering will help, courtesy of RICO laws and treble damages.

Until then, developers will be at risk of app distributors who fail to require adequate documentation of DMCA-related court filings, let alone fail to pass that documentation along to the affected party.

I have been advising, for nearly four years, that developers have multiple means of distribution. DMCA trolls make that all the more important, particularly for free apps. Putting all your eggs in the Play Store basket makes it that much easier for trolls to make an omelet. Whether you go with multiple “app stores” (e.g., also list in Amazon AppStore), multi-national self-distribution, or both, you make it that much more difficult for trolls to completely shut you down.

This is another reason for directing your marketing efforts to your own Web site, rather than straight to a Play Store listing. In case of trolls, you can point your Web site to other points of distribution.

Seeking Global Android Developer Support Sites

TL;DR Edition: If you know of a discussion board, mailing list, or other question-and-answer site that exists to support Android app developers, where the primary language is not English, please send me:

the name of the site

the URL to the site

the language(s) supported by the site

And if anyone knows somebody else who already has a collection of such sites, please let me know, so I do not duplicate their efforts!

For this, reach me at globaldev@commonsware.com, or post something to @commonsguy on Twitter.

While StackOverflow and the android-developers Google Group are fine places to get help, they are English-centric. This is great for somebody like me (an American rumored to speak Engilsh now and again).

However, the Android development community has now grown well past the point where English-only support resources are the best for everyone. Many developers will be uncomfortable asking, or answering, questions in English. And questions that are difficult to understand, due to unfamiliarity in English, are less likely to be answered.

I presume that there are forums, lists, StackExchange installations, and the like out there that cater to other languages. I would like to build a page that lists as many of them as we can aggregate, so that there is a single place we can point developers to get help in their native language. However, I am unlikely to find the right sites by random Internet searches, which is why I am looking for suggestions of sites to list.

Right now, I have:

A Spanish site from Argentina, courtesy of @Macarse

A Russian StackOverflow equivalent, courtesy of @sergey_sergeich

Once I have (hopefully) a few more in my starting set, I will publish the roster in HTML and JSON forms on Amazon S3, backed by a public GitHub repo, with the data all licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported license, so anyone can use it. Also, we can see where the gaps are – and I expect there will be many – so interested parties can consider setting up a developer support site in their language.

Thanks in advance for any contributions!

USB Debugging May Be Hazardous To Your Health

Being able to debug apps on off-the-shelf Android hardware is a major blessing, one that countless Android developers (including myself) are grateful for. However, there are costs involved with this feature.

Specifically, if your device has USB debugging enabled, anyone who gets their hands on your device can blow past the keyguard (swipe, PIN, password, whatever) and access your device directly. No reboot is required, and so whole-disk encryption is of no benefit.

I will not go into details of the attack here. If you want details, the attack has been written up in a couple of places (or, if I know you, drop me a line). Suffice it to say it is not, strictly speaking, relying on any undocumented security flaws or the like. Instead, the attack uses a combination of standard OS capabilities, each of which have legitimate uses, but happen to combine to cause this privacy issue.

Unfortunately, presumably because of this, the official answer from the Android Security team is that “this is not a bug”, despite the privacy implications for Android developers.

The safest course of action is to disable USB debugging on any device that has access to private information of yours. However, this is an annoyance for developers whose only Android device for testing is also the device they use for daily personal or business affairs.

Ideally, IMHO, the OS would have two capabilities:

It would expand the USB debugging option in Settings, replacing the current checkbox with a three-option list: off, always on, or on-while-connected. The latter option would cause the OS to automatically turn off USB debugging when the USB cable is unplugged.

It would have a built-in app widget to toggle on and off USB debugging.

These would allow developers to manually turn on and off USB debugging without wading through a couple of layers of the Settings app. The combination of the app widget and the on-while-connected setting would make it easy to keep USB debugging off except while actively working on development – just tap the app widget when plugging in the USB cable to debug, and unplug the USB cable to turn off debugging.

Alas, this does not exist. While it is possible to implement this as an SDK app, it would require an everlasting service or frequent polling (to monitor the state of the USB debugging option) and would require a rooted device (to install the app on the system partition, to be able to change the state of the USB debugging option).

Developers with rooted Android devices can find app widgets on the Play Store and elsewhere that allow toggling on and off USB debugging, though this does not help those with unrooted devices.

In practice, the risk caused by this issue is not that great for most people. It requires you to lose your device and for that device to wind up in the hands of somebody who knows about this exploit. However, it is a bigger deal for developers who lives put them at constant risk of incarceration (e.g., dissidents in Arab Spring-style movements), as it is reasonably likely that smartphone forensic tools incorporate this exploit.

Be Careful What You Wish For

Every time there is a non-trivial Android release, the hue and cry goes up “when will we get «insert tasty treat here» for «insert device here»?” As a result, there is some amount of pressure placed on device manufacturers to get upgrades out the door, and sometimes that is not to our benefit as users.

For example, for my recent trip to the UK for Apps World Europe, I brought along my ASUS Transformer Infinity (with keyboard), instead of a notebook. My presentation was going to be delivered from a conference notebook, not my own, so I did not need to worry about projector connectors, and the Infinity is a lot easier to tote around than is a 15.6” notebook.

However, shortly after arriving, ASUS pushed out an update for the Infinity, moving it to Jelly Bean.

On the surface, this is perfectly delightful. However, the devil is in the details:

Unlike some devices, which will nag you once about an available upgrade and then shut up, ASUS’s version of Android will nag you every couple of hours. This gets old very fast. On the plus side, from ASUS’s standpoint, is that users are unlikely to stick on the older OS for long, reducing their long-term support issues.

However, the upgrade failed to work. After the upgrade’s final reboot, the device would not complete its boot cycle, getting stuck on an ASUS logo screen with a “spinning dots” indefinite progress indicator. Several reboots, warm and cold, had no effect. Research (done from a desktop PC from the hotel’s business center) indicated that the only way I had to recover would be a full factory reset.

However, while the full factory reset did get me back into the tablet, with Jelly Bean running, my attempts to re-encrypt my device, using Android’s full-disk encryption, brought me back to my original state. Hence, the problem appears to be that ASUS’s Jelly Bean version for the Infinity does not support full-disk encryption. And it appears that I am not the only one reaching this conclusion.

Had ASUS not been such a pest about upgrading the device, I would have held off until I returned to the US and was no longer dependent upon the Infinity. As it stands, the ASUS “won’t you please upgrade” nagging combined with a testing gap (not trying their upgrade on full-disk encrypted evices) to cause me a fair bit of headache.

(and for those subscribers wondering why I canceled Tuesday’s office hours without notice, now you know…)

So, be careful what you wish for. Android updates are good, but when speed negatively effects quality assurance, speed is not necessarily your friend.

The Busy Coder's Guide to Android Development Version 4.2 Released

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 4.2, in PDF format, with the other formats to follow in the next few hours. Just log into your Warescription page and download away, or set up an account and subscribe!

This is a rather small update, courtesy of a variety of things that fouled up my writing schedule this month. I apologize for the reduced amount of new content and will aim to do better next month.

This update includes a new chapter on animators, including animating fragments (e.g., Gmail-style three-pane navigation). It also adds a short chapter on AdapterViewFlipper to the widget catalog. And, there are the typical array of errata fixes.

If you encounter any problems with this update or your Warescription in general, please contact wares@commonsware.com, and be sure to provide your Warescription user ID.

Trust and the Mobile OS

I wish today’s disclosure that some Samsung devices have a USSD code that can wipe the device would be completely surprising, but it is not. As I noted in a recent blog post, Android has massive surface area to try to secure. Mods of that OS — such as Samsung’s — may increase this surface area.

One of the fundamental attributes of an OS is trust: device owners have to trust the OS to work on the device owners’s behalf and not on anyone else’s. Samsung’s flaw, Canonical’s decisions regarding searching Amazon by default, and so on simply degrade the user’s trust in those OS distros.

The problem is that our options are limited.

In Android, in theory, independent ROM mods would offer potential for increased trust. And there is little doubt that they are more trustworthy than the built-in firmware in many cases, as CarrierIQ, today’s flaws, and so on illustrate. However, too many independent ROM mods “play fast and loose” with software licensing, distributing drivers, the Play Store, and so forth without obvious rights to do so. While none of that directly impacts security, one must wonder whether such mods might also “play fast and loose” with other aspects of their distros, in ways that might impact security. Trust is weakened by the licensing issues, and that weakened trust affects matters across the board.

What would be awesome would be a tiered approach:

Tier 0 is the AOSP proper, as distributed by Google today.

Tier 1 is the AOSP, with the minimum possible changes, and installation scripts/recipes for various devices, with an emphasis on transparency (i.e., we all know what those scripts do) and license integrity (i.e., either upgrade in place or copy necessary binary blobs off the device on the fly, to avoid distributing such blobs).

Tier 2 would be based on Tier 1 with security fixes applied, potentially including fixes that Google declines to apply. For example, in recent weeks, I have been told by Google that flaws that allow third parties to blow past the keyguard via USB cable “is not a bug”, and that flaws that malware can exploit to prevent the user from using their device “are considered below our security bug bar”. Tier 2 might also be independently vetted for security issues, providing further fodder for fixes.

Regular ROM mods, designed for users, business, etc., would be built off of Tier 1 or Tier 2 as desired.

Tier 1 and 2 could be maintained by an independent foundation, perhaps based on the Mozilla model, with a wholly-owned corporate subsidiary (akin to the Mozilla Corporation) that sells things to fund the foundation’s work (e.g., enterprise ROM toasters). The objective of the foundation is to be trustworthy, above and beyond all technical prowess, as it is only via trust that tech wizardry will matter.

Perhaps something like this exists and I am simply unaware of it — I certainly am not deeply embedded in this segment of the Android ecosystem. If anyone knows of such an initiative, please let me know.

Perhaps something like this is technically infeasible at the moment (e.g., avoiding distribution of closed source unlicensed binaries), or there are other issues that make this impractical of which I am unaware.

But somewhere, we need a solid independent foundation of trust.

Knowledge Transfer vs. Support

I caught a bit of flak over my last blog post, suggesting that Google’s relationship to developers amounts to “benign neglect”. As I noted, individuals at Google, including everyone I have met or otherwise interacted with from Developer Relations, are exemplary.

However, I was not especially clear in that post as to what I thought constituted the “benign neglect”, and I think I understand where the discrepancy lies between my expectations and the expectations of others. It is a question of knowledge transfer vs. support.

The Developer Relations group for Android does a number of things to help the rank-and-file developer, including posts on the Android Developers blog, posts on personal Google+ accounts, and various bits of sample code (hats off to Roman Nurik, in particular, for the latter). They also contribute to the SDK documentation (e.g., the Android Training series of pages), speak at events (from Google I|O down to smaller affairs), and so on.

This is all wonderful, and I am grateful for every byte of it.

It is knowledge transfer, one to many. In effect, it is all part of the overall Android documentation, just housed in a disparate set of locations.

However, knowledge transfer is not support.

Support is getting individual answers for individual questions, as those questions arise. Support is a fairly commonplace need with technical products, and so having means of asking questions and getting answers is pretty much expected for lots of products, including those designed to be used by developers.

Occasionally, the two constructs overlap. For example, Developer Relations has been holding various Google+ Hangouts. On the surface, they represent support, insofar as they take questions from developers and answer them. However, they only have time for a couple of dozen questions per week across the hangouts — StackOverflow gets that many questions in a couple of hours of a typical month. Hence, the value of the hangouts is more in knowledge distribution, as many more people can watch (or listen to the podcast editions). Any support structure that results in publicly visible answers has a knowledge transfer component, and the knowledge transfer may be more valuable than the support overall.

The question then is one of scale.

Presumably, Developer Relations focuses on knowledge transfer because there is no way they could hope to handle all incoming Android development questions while serving in a front-line support role. StackOverflow collects over 10,000 questions per month, and there are countless thousands more in other support venues like the android-developers Google Group. Even if they add some staff, keeping up with questions would be a challenge and would hamper their ability to due pure knowledge transfer (e.g., sample code) due to lack of time.

That being said, we have a reasonable number of non-Google employees fielding questions on StackOverflow and the other venues. However, to some extent, we are the blind leading the blind. We can only answer questions based upon our experience and what we have learned from existing knowledge distribution channels. When those trying to help do not know the answer, or do not understand the question, at the moment, we are in trouble.

It would be awesome if there were some way to turn to Google for some questions in a structured, measured fashion. For example:

Use the StackOverflow bounty system as a means of indicating questions needing answers, with Google staff tackling the N highest- bounty questions per week

Have a means for designated community members to be able to “escalate” questions, with Google staff serving in a second-line support role

Offer a paid support service, where spending some modest sum can “escalate” a question on StackOverflow or an issue on the issue tracker or whatever

And, of course, there are any number of other ways that Developer Relations might be able to help more “at scale” beyond these ideas, not to mention other groups that have “at scale” issues (e.g., Play Store developer support).

It is entirely possible that some of this stuff is happening in an unofficial way (e.g., if you comment on a G+ post with a link to a StackOverflow question, you might get lucky and get Google input). Unofficial is nice, but tough to prove, tough to scale, and access-controlled (e.g., must be a Google+ member, must attend the right events to be able to ask questions). It is also possible that Developer Relations is doing various forms of support in ways that I do not recognize, for one reason or another, and for that I apologize.

Finally, Google can do whatever Google wants, because to a large extent, Google won. Android has certainly succeeded beyond any realistic hopes that I have had, so they clearly do not need to do anything more than what they have done to date.

My point in the previous blog post — the lesson for newcomer mobile OSes to consider — is in figuring out how they are going to scale their support. How will, say, Firefox Mobile OS or Windows Phone support 100 developers? 10,000? 1,000,000? Google’s approaches worked for Google, insofar as Android has been a raging success. However, it is risky to assume that a development community can be largely self-sufficient at scale for getting questions answered, without some structured means of getting expert advice where needed.

Android's Lessons for New Mobile Operating Systems: Community

While Android and iOS presently have the smartphone market largely sewn up, other mobile operating systems are in the works or will arise over time. For example, Mozilla is creating Firefox Mobile OS as their entrant into this space.

In this blog post series, I will explore some lessons that I think we can learn from Android’s successes and failures that can help new mobile OSes as they try to break into this space. Today, I’d like to focus on community.

There are several ways to go after an established market with large incumbents.

One involves a head-on assault, using marketing dollars and related forms of clout to try to get market attention. This is how Microsoft is going after the smartphone market with Windows Phone.

Another involves taking a flanking position first, to try go gain credibility in some slice of the market and expanding from there. Amazon’s second-generation Kindle Fire represents a head-on assault on tablets, but their $50/year 4G mobile data plan on the top-end Fire serves as a flanking position for the smartphone market, should they attempt to go after that in the future.

The third is a guerrilla approach, trying to win from the grassroots up. This is the most likely avenue of tactical success for new entrants, such as Firefox Mobile OS, as both expectations and costs are manageable.

With that in mind, what can we learn from Android that can apply to new entrants in the mobile OS arena?

Force Multipliers

We like to toss around terms like “ecosystem” and “community” to refer to the entire set of groups and individuals with a vested interest in the success of certain products. From the standpoint of the mobile OS vendor, though, you might want to think of the ecosystem as being force multipliers, to steal a term from the military. The developers, bloggers, and other early adopters can help you push your OS, but only to the extent that you help them to do so. What you get out is what you put in.

In some cases, “what you put in” can seem lightweight but carry significant impact. One of the most insightful moves that Google made with Android was to make the bugdroid mascot available under a Creative Commons license. It is unclear whether they truly envisioned the impact that the lil’ green guy would have, but bugdroid puts a face to the Android name, even if that face is merely artwork. Today, bugdroid is used in everything from television commercials to blog banners, helping to tie together an otherwise disparate ecosystem.

This does not mean that having a cute readily-licensed bit of mascot is some sort of magic bullet, one that will make a mobile OS succeed on its own. But it is one way of helping those who want to help you do just that, in a way that, over time, will help build brand momentum.

Apps: Numbers and Names

Hardware specs — like mono speakers versus stereo speakers on a tablet — are something that help buyers choose between substitutes within a market. All else being equal, they will go with the stereo speakers… except that all else is usually not equal.

However, such specs only matter when you are perceived as a viable substitute. Right now, smartphones are perceived as a substitute if they successfully answer the question: “can I get what I want?”. And, to a large extent, “what I want” comes in the form of apps, or content powered by apps.

Buyers will have questions about apps with your mobile OS:

“Can it run XYZ app?”, for apps they have used elsewhere, or apps that came strongly recommended from friends, etc.

“Can I do XZY on the device?”, for things they know they want in general but may not have particular apps in mind (“can I watch videos?” “can I connect to my office VPN?” and the like)

“How many apps are there?”, as a general guide for determining whether or not they are likely to find a solution for a need they do not presently know that they have

This is where trying to enter the mobile OS space will be troublesome. Having an OS is one thing; having an OS and apps is quite another. Amazon, for example, has to defend their AppStore for Android’s size, being a shadow of what the Play Store has… and Amazon has 50,000 apps at present. It will take a new entrant quite some time to get to 50,000.

Your Developers Are Key Early Adopters

That’s why courting developers early on and convincing them that there is a reason to pay attention to you is important. Back when Android hit the scene, developers and users took to Android in part because Apple limited iPhone’s availability, and markets, like nature, abhor a vacuum. But now that Androids (and iOS devices to a lesser degree) are available in most countries for most carriers, the vacuum is gone. Maintaining multiple ports of apps is a pain, and porting to an unproven platform will not make sense to many a developer.

Hence, you need to go out of your way to make sure that getting apps on your platform is as easy as humanly possible. That includes things like:

Hardware seeding programs, whether through device giveaways, loaner programs, or bulletproof ways to get your mobile OS onto other existing devices

A clear path to volume (e.g., Firefox Mobile OS playing up the Web aspects, showing developers how to create apps that work well on their OS and regular Web browsers, and perhaps even on other mobile platforms the developers have not yet targeted)

Copious support, from documentation to clear ways to get authoritative answers — if a new entrant tries Google’s “volunteer only” approach towards answering developer questions, the new entrant is unlikely to fare well

Reuse Makes the World Go ‘Round

Another key element for getting developers on board is a clear model for reuse. You need to make it dirt simple for developers to get apps onto your platform. Some of that may come from you directly, but you really need the force multiplier effect of other developers if you are “coming from behind” within a market. Having an easy way for developers to contribute components — from UI widgets to utility libraries to app “bootplates” — will be important as you try to woo the next generation of developers to contribute apps to your platform.

Once again, Android was able to skip this part, because it was able to fill a gap in the market offerings, though it is suffering today due to the lack of a reuse model and go-to component bazaar.

Have Humility

If you visit the Android Developer site, it would be easy to think that there is no Android developer community. Outside of links to some Google-established Google Groups, there is no sign whatsoever that third party developers exist, other than the fact that apps magically appear on the Play Store. There are no links to key third-party libraries, or a blogroll of useful developer blogs, or even a link to StackOverflow (while there used to be one that had existed for a year or so, it was removed in the site revamp in early 2012). While as individuals, Google engineers are generally awesome, as an organization, Google’s general behavior toward third-party developers as a group can be best described as “benign neglect”. You get your SDK and tools, you upload to the Play Store, and for anything outside of those aspects, you’re on your own.

You are not more important than your developers.

Yes, in a military analogy, you are the generals and the developers are the “grunts”. This means that you will be more visible and will be able to “call the shots” more often than not. But wars are only infrequently won based purely on the genius of the generals; more often, it is the grit and guile of the grunts that plays a major part. That is even more important for platforms “playing catch-up”, because “underneath each helmet is a head, and heads can think”. Developers have left Android in the past due to the benign neglect, and others will likely do so in the future. That is one thing when you have tens of thousands of developers; it is a somewhat larger issue when you have tens of dozens of developers.

Android's Lessons for New Mobile Operating Systems: App Distribution

While Android and iOS presently have the smartphone market largely sewn up, other mobile operating systems are in the works or will arise over time. For example, Mozilla is creating Firefox Mobile OS as their entrant into this space.

In this blog post series, I will explore some lessons that I think we can learn from Android’s successes and failures that can help new mobile OSes as they try to break into this space. Today, I’d like to focus on app distribution.

The Play Store is in many respects a crowning achievement of the Android initiative. From nothing four years ago, the former Android Market is now arguably the second-largest software distribution venue in history, behind only the iOS App Store. Yet, particularly in developer circles, the Play Store is riddled with issues.

Every developer has their take on the Play Store’s successes and failures — what follows is mine, and it is only the highlights, not a complete treatise on the subject.

What Is Right

Having the Play Store at all is the single biggest thing Google got right. We take it for granted now, but getting apps on mobile devices before iOS and Android was a pain, to put it simply. For example, Windows Mobile usually would require you to download the app installer on a Windows PC, then plug in the phone via a USB cable, then run the installer to push the app over to the phone. And this assumes that you could find and buy the right app in the first place. Having a relatively easy way for device owners to find and install apps was hugely important for Android’s growth (and, by extension, growth in Android development).

Yet, at the same time, Google did not require the Play Store. From the beginning (with the exception of some AT&T devices), anyone could distribute apps by any desired technical means — the only thing required to allow them to be installed was a single checkbox in Settings. Google could easily have gone the other way, forcing all all installs to occur through the Play Store.

Having low barriers to entry to get an app on the Play Store was another good move. The $25 fee is not exactly a big revenue stream, but it does help put a “speed bump” in the way of malware authors, who might prefer to work behind a battery of anonymous accounts. Yet, at the same time, $25 is not an unreasonable amount for most legitimate developers to gain access to hundreds of millions of devices.

Both the iOS App Store and the Play Store have their rules for what is and is not allowed, and those rules are sometimes problematic (discussed later in this post). However, the Play Store tends to have clearer rules for bigger-ticket issues. With the Play Store, the complaints about clarity of those rules tend to come on things like “what constitutes keyword spam”. The iOS App Store, by comparison, has been accused of banning apps for everything from competitive advantage to political pressure, issues to which the Play Store has tended to be immune.

Finally, using the Play Store as a club to help keep device manufacturers “on the straight and narrow” in terms of compatibility was a wise move. There are plenty of bugs in devices, wiggle room in specifications, and gaps in the Compatibility Test Suite (CTS) that cause “fragmentation” in Android. But if you think that’s bad, can you imagine what would have happened if the CTS had not been required from the outset? There would be no single “Android” from the standpoint of app developers, as device manufacturers would likely have run amok in making changes that prevented apps from running.

What Is Mixed

The existence of the Play Store has been a win. The implementation of the Play Store has had a more muddled history. At the outset, the Android Market was like a talking dog: you were amazed that it existed at all, and issues could be ignored. Over time, usability issues have waxed and waned in importance. Areas of common complaint, like searchability and feedback, have been addressed, at least in part, though there is plenty of room for continued improvement.

What Is Unfortunate

Bashing the Play Store is such a sport in some circles that it might qualify as an event at the Ree-oh 2106 Summer Oimplycs (event name obscured to prevent trademark infringement (unless somebody trademarked “Oimplycs”, in which case I’m just screwed)).

The issues I outline here are perhaps not representative of the concerns of your average Android developer. However, they are ones that I feel should be considered, strategically, by any future mobile operating system looking to offer similar “market” facilities.

Unfortunately, many seem to come down to the 30% take off of the sales of paid apps and in-app purchases. We no longer really know what that 30% goes for and why that figure is justifiable. The original story — that the 30% went to carriers — needs updating, as there are plenty of devices being sold that are not associated with any carrier.

While it could be argued that developers need no transparency into the role of that 30%, there are too many rules in place that attempt to lock developers into that 30%. The Play Store enjoys “most-favored-nation” status in ways that are difficult to stomach, such as the non-compete clause (“You may not use the Market to distribute or make available any Product whose primary purpose is to facilitate the distribution of software applications and games for use on Android devices outside of the Market”) and the similar clauses around in-app purchasing. If the 30% is so important as to cause Google to want to employ anti-competitive tactics, developers deserve to understand why.

Sometimes, the anti-competitive behavior is simply benign neglect. For example, the feed of application data from the Play Store — apps, descriptions, requirements, comments, etc. — is unlicensable, insofar as my attempts to license it have been rebuffed. Yet, as I have blogged about previously, the data is widely used, presumably sans license, meaning that Google is blocking legitimate competition while enabling illegitimate competition. This is particularly important as the community around Android could do lots to help improve the Play Store experience (e.g., improved search and other discovery mechanisms, third-party security “seals of approval”), if only we could have the data with which to do so.

If you are going to run a market, particularly one with fees and rules and such, it is incumbent upon you to staff that market with the people necessary to make it work for all parties. Getting answers on Play Store questions from developers is notoriously difficult for the rank-and-file, particularly when it comes to the “your app has been removed” messages. While it is human nature to provide varying levels of assistance — I doubt that Rovio has problems getting questions answered — the “haves vs. have-nots” image does not do the Play Store any favors. A market sans fees and with fewer rules can perhaps get away with “best efforts” sorts of support, but not the Play Store.

In tomorrow’s final installment in this series, I will take a look at the overall developer ecosystem around Android and what lessons newcomers to the mobile OS space can learn.

Android's Lessons for New Mobile Operating Systems: Security

This blog post series, which began with yesterday’s discussion of audience, is exploring what new mobile OSes, like Firefox Mobile OS, can learn from Android’s successes and failures. Today, I’d like to look at security — here are some things to consider based upon what we have seen in Android over the past ~4 years.

Think Surface Area

The surface area of an operating system (or a runtime environment, or a library, or whatever) consists of all ways somebody can tell that OS (or whatever) to do something. This includes everything from formally-supported APIs to the results of SQL injection attacks (see: Little Bobby Tables).

Android’s surface area is simply huge. It not only has hundreds of classes and tens of thousands of methods across the framework API, but there are countless more classes and methods “hidden”, yet accessible via Java reflection. Then there is the stuff accessible via the JNI/NDK combination, stuff exposed via the Linux substrate (e.g., /proc), stuff exposed via the adb debugging interface, stuff exposed via AOSP and other firmware-installed apps, and so on.

Trying to defend against such a large front is very difficult (see: Soviet Union v. Germany, WWII). And while you may try to get away with assuming that some portions do not need to be defended (see: the Ardennes forest, compared with the Maginot Line, WWII), somebody might find ways of exploiting that undefended region (see: Fall Gelb).

Security is easier with less surface area. Trying to strike a balance between “less surface area” and “enough surface area to write the apps that we want” may be difficult.

Usability vs. Security

Android’s permission-based system, on the whole, has its merits. While one can certainly debate how many Android users really pay attention to, or even understand, what the permissions mean, there are certainly worse possible solutions (see: Microsoft Vista, “the CPU would like to execute an instruction — allow? deny?”).

However, one of the oft-repeated complaints about the solution, from power users, is that permissions are an all-or-nothing deal. Either you agree to all of the permissions, or you do not install the app. There is no notion of an app declaring optional permissions, that the user could grant or deny as desired. This has been proposed — along with the more draconian “all permissions are optional” variant — and Google’s response is that they are concerned about usability.

Frankly, this rather surprises me. While I could see various arguments about this capability, usability would not be one of them.

There have long been approaches for having power user configurability in ways that ordinary users would never encounter (see: Firefox about:config). Even if you are concerned that ordinary users might be put off by having to decide up front which permissions to grant or deny, simply use the current behavior and grant them all, with a power-user option somewhere in Settings to tailor the permissions more.

While other mobile OSes might not have the Android permission system, the issue of security vs. usability will likely rear its head elsewhere. Again, trying to strike a balance will be important, and where that balance lies will depend upon the primary audience of the OS. The solution for children might be different than the solution for security-conscious users.

The Good-Intentions-Paved Road

App lockers and replacement lock screens are popular on Android, as they allow devices to be more widely shared with fewer possible repercussions. However, Android does not have support for app lockers or replacement lock screens. Instead, the authors of such apps exploit various loopholes (courtesy of Android’s enormous surface area) to have the effect of preventing users from accessing certain things. The problem is that if the author of an app locker or lock screen can block users, so can malware authors. And, in a world where “malware authors” may include major governments (see: Stuxnet), malware takes on a whole new scope.

New mobile OSes can learn from Android in terms of what sorts of apps are popular, then plan ahead to specifically address them, one way or another. Perhaps the desired functionality would simply be part of the OS, eliminating the need to expose APIs that might be exploited. Perhaps the desired functionality can be handled in some carefully managed way, to allow the legitimate uses while (hopefully) disallowing nefarious uses. Perhaps the functionality is deemed inappropriate for the base OS, but that the OS makes it very easy to create remixes (akin to Android ROM mods), where it would be possible for other “distros” to offer such functionality if they so chose. Or perhaps there are other proactive solutions.

The key is to learn what sorts of things are popular (based on Android’s results), determine which of those things are based on dicey implementations, then decide how to address them in a new mobile OS.

Spy on the Spies

There are many ::bleeps:: in this world. Some of these ::bleeps:: like to create covert surveillance software, to help governments spy on their citizens, and the like (see: FinSpy). Others like to create software that offer automated means to abscond with a device’s data, ostensibly for forensic purposes (see: Cellebrite).

If the creators of a mobile OS do not like such ::bleeps::, it is perhaps worth spending some time to determine how you can monitor what they do and how to detect (and, later, defend against) their methods. For example:

Offer a “bug bounty” not for software bugs, but for “bugs” in the spy sense, where you reward those who point out firms that are advertising that they create such “official malware”, or set up some sort of Wikileaks-style means for anonymous contributions of the same

Find some firms or organizations that can work with you to help get samples of the malware (e.g., as part of a theoretical sales process) that you can reverse-engineer and try to block

At the same time, be careful that your means of enabling detection of such software do not themselves introduce new security holes (e.g., software to scan for spyware that opens a door for “forensic” data mining).

Tomorrow’s post will take a look at an OS’s app distribution, and how Android’s approaches for that have had their pluses and minuses.