LWN.net Weekly Edition for December 8, 2016

The apparent end of CyanogenMod

The world is full of successful corporations built with free software and, as a general rule, the free-software community has benefited from the existence of those companies. But the intersection of corporate interest and free software can be a risky place where economic interests may be pursued to the detriment of the underlying software and its community. Arguably, that is what has happened with the CyanogenMod project, which is now faced with finding a new home and, probably, a new name.

CyanogenMod is an alternative build of the Android operating system; it got its start in 2009. It quickly grew to become the most popular of the Android "mods", with a substantial community of contributors and support for a wide range of devices. Early users appreciated its extensive configurability, user-interface improvements, lack of dubious vendor add-on software, and occasionally, privacy improvements. For many users, CyanogenMod was a clear upgrade from whatever version of Android originally shipped on their devices.

In 2013, CyanogenMod founder Steve Kondik obtained some venture capital and started Cyanogen Inc. as a vehicle to further develop the CyanogenMod distribution. The initial focus was on providing a better Android to handset manufacturers, who would choose to ship it instead of stock Android from Google. There was a scattering of initial successes, including the OnePlus One handset, but the list of devices shipping with CyanogenMod never did get that long.

Recently there have been signs of trouble at Cyanogen; these include layoffs in July and, most recently, the news that Steve Kondik has left the company. Cyanogen Inc. will now proceed without its founder and, seemingly, with relatively little interest in the CyanogenMod distribution, which, arguably, has lost much of the prominence it once had. Devices running CyanogenMod were once easily found at free-software gatherings; now they are somewhat scarce. Anecdotally, it would seem that far fewer people care about the continued existence of CyanogenMod than did a few years ago.

There are certainly numerous reasons for interest in CyanogenMod to have declined. Perhaps at the top of the list is actions on Google's part. The Android experience has improved, sometimes by borrowing ideas that appeared in CyanogenMod first. We no longer have to install CyanogenMod to gain (some) control over application permissions, block unwanted notifications, or get quick access to flashlight functionality. Meanwhile, Google's licensing rules for Android and, in particular, for the proprietary layers at the top of the stack constitute a strong disincentive for vendors thinking about experimenting with alternatives like CyanogenMod.

But actions at Cyanogen Inc. are also certainly a part of this picture. The pace of development for CyanogenMod appears to have slowed; there is still no release based on Android 7 ("Nougat") available outside of the nightly builds. In general, CyanogenMod releases have been de-emphasized in favor of those nightly builds — a discouraging development for users who are unwilling to risk bricking their devices with a random snapshot. When releases do happen, the headline features show a different set of priorities. The current release, Cyanogen OS 13.1, adds the ability to "view trending Tweets right on your lock screen". This feature is likely to be useful for the US President-elect when his staff changes his lock code again, but it's not likely to be the sort of thing traditional CyanogenMod users were looking for; neither are the new Skype and Cortana integration features.

In other words, Cyanogen Inc. would appear to have left its user base behind in its pursuit of revenue. That change has resulted in tension within the company, no doubt exacerbated by the failure of that revenue to arrive. Now, this process has culminated in a change of control at the company, a new focus on its "MOD" initiative, and Kondik's departure.

Kondik expressed a fair amount of bitterness over the end of Cyanogen Inc. as he had envisioned it. But he is also worried about the future of CyanogenMod as a community. He did not say outright that Cyanogen Inc. would no longer support the project, but he does say that the project has "about two months" to find new servers. So it is not unreasonable to believe that, if CyanogenMod is to continue as an even remotely community-oriented project, it needs to arrange for a new home.

It also most likely needs a new name, since Kondik signed the existing name over to the company he is now estranged from. Name changes for prominent projects are possible, but they are not easy; witness how long LibreOffice has struggled against the OpenOffice name, for example. A rebooted CyanogenMod will have to fight a similar battle while trying to win back the community mindshare it once had.

One can only hope that the project succeeds. Android has been massively beneficial to the free-software community, but we absolutely need a more open, community-oriented alternative. We need a place where new features and new approaches to privacy can be tried out. We need an alternative for users whose devices are no longer supported by their vendors. We need a mobile distribution that is managed with its users' interest in mind. We need, in other words, a mobile distribution that brings us all of the benefits that we expect from free software.

CyanogenMod was never a perfect community-oriented distribution, but it is still the best we have in this area. Without it, mobile systems, even Android, would be that much more proprietary and that much harder to control. CyanogenMod is an expression of just the sort of freedom we have been working for all these years; let us hope that its next phase of existence will be successful.

Comments (19 posted)

OpenID for authentication

I've just registered on "yet another web site", which meant another scramble for a username that's not already in use, another randomly-generated and highly-unmemorable password, and another email address provided for account recovery in the event that it all goes wrong. Along with my flying car and jetpack, I'd rather hoped the 21st century would bring a better way of managing my identity on the internet; in 2005 it did just that with the release of the OpenID standard for distributed authentication. Sadly, OpenID has remained a fringe player in this field.

How it doesn't work now

We've all experienced this registration pain: the multiple permutations of our preferred username, trying to find a variant that we can remember which no-one has already taken, and the generation of yet another nonce password, which our browser will have to remember for us. Need I mention the issues of either re-entering that password for storage on other browsers we use, or the use of some centralized storage system that's either local to a trusted device whose loss will be a near-disaster, or is stored in someone else's cloud, with all the trust issues that involves? They also want an email address for recovery. Do I use my regular one, and risk them losing control of it, or even simply selling it to spammers? Or do I generate a one-time one, which my mail server then has to be configured to know about?

In any case, isn't username/password authentication a bit stale? Most banking web sites now require some variant of two-factor authentication (2FA); it's time this became standard practice. But if every site rolls its own 2FA, then my storage-of-random-credentials problem just got even bigger. The right way forward for most web sites is federated authentication: the site delegates the business of ensuring that I'm really me to some generally available third-party. This is now starting to happen, but unfortunately the two big players are Google and Facebook, and you don't have to wear a tinfoil hat not to want to give them information about every single web site you ever use.

Things can be better

Fortunately, in 2005, OpenID was created. This is a distributed authentication system that, in its simplest form, ties my identity to a URL of my choice. That URL uses some link tags in the header to nominate my OpenID authentication provider of choice. You can see this in the top of my OpenID identity URL, https://www.teaparty.net/:

    <html>
     <head>
      <link rel="openid.server" href="https://openid.yubico.com/server.php" />
      <link rel="openid.delegate" href="https://openid.yubico.com/server.php/idpage?user=vvgdbhcgutti" />
     </head>

     <body>
      Regular web page stuff...
     </body>
    </html>

The links specify to whom I delegate the business of authenticating me (openid.server), and how I identify myself to them (openid.delegate). Note that these are not set in stone; indeed, they're downright disposable. If my current delegate goes out of business, I lose trust in their ability to handle this securely and reliably, or I just forget how I authenticate to them and I can't raise their customer service department, thirty seconds with vi (or three minutes with emacs) can put a new delegate in place.

In fact, when one provider did fail, that's exactly what happened: I used Google to find OpenID providers, picked one I liked, registered with it, and changed my delegation links. If I were feeling particularly paranoid and wanted to run my own authentication provider, I could, but even if I choose not to, authentication stays very much in my control because of my ability to re-delegate with the touch of a text editor.

So when I approach an OpenID-capable web site to log in, things unfold as the diagram shows.

1. I go to the web site, and tell it I want to log in as my identity URL, https://www.teaparty.net/.
2. The web site retrieves https://www.teaparty.net/ from my webserver and parses those tags.
3. The web site contacts openid.yubico.com and POSTs a request to establish a shared secret using Diffie-Hellman key exchange (the protocol calls this "associating").
4. The web site sends my web browser off to openid.yubico.com to authenticate, as I specified in the delegate tag, using our pre-agreed method. The web site provides a nonce as part of this exchange.
5. Provided that I authenticate to its satisfaction, openid.yubico.com sends my browser back to the web site with a token that is provably from that provider, and which is intended for the web site as part of this particular authentication exchange. This is possible because of the shared secret set up in step three, and the nonce provided in step four.

Note that the OpenID protocol is silent on the question of how the authentication in step four is to be accomplished. I am expected to have set that up with openid.yubico.com as part of the process of registering with it as my delegated provider. Authentication could be via username and password. It could be via a complex 2FA routine, which is not a problem because I only need one such arrangement to access all of my OpenID-enabled web sites. It could even be by some baroque arrangement where I call them up, pass a Turing test, and submit a blood sample for DNA matching; timeouts might be an issue, but the protocol has no problem with a scheme like that.

Doing OpenID well requires a little diligence:

• Ensure that your identity URL is served under HTTPS, with a properly-signed certificate, from a domain secured with DNSSEC. You can't force any given web site to check certificates and DNS signatures, but providing them makes life harder for attackers. It used to be expensive and painful to do these things, but between Let's Encrypt and the fairly widespread availability of DNSSEC, it's no longer either of those.
• Your delegated authentication provider knows which web site is asking you to authenticate through it, and it should provide this information to you in step four. Make sure you check that it matches the web site you think you're authenticating to.
• As you may have guessed from the URLs above, I use one of the slots on my YubiKey for one-time password authentication. Whatever you plump for, use something more robust than simple username/password authentication with your delegated authentication provider.

The OpenID protocol has also had some security issues. These have generally turned out to be implementation-dependent (and fixed by the implementation's authors) or can be sidestepped by the use of SSL/TLS throughout the authentication chain.

How's that working out?

Wikipedia claims that "there are over 1 billion OpenID enabled accounts on the Internet [...] and approximately 1,100,934 sites have integrated OpenID consumer support". Unfortunately, with the honorable exception of ServerFault, few of the sites I find myself logging into are in that 1,100,934. One reason for this does not reflect well on big web sites: when you go through the business of registering with a big site, they can ask you for all sorts of biographical information. You don't have to give it to them, but many people will without thinking about it, and this allows the big sites to target advertising more effectively, and thus make more money. If all they get is a naked URL, they know nothing about you; there is thus a considerable incentive to make you go through the pain of registration. It is true that Google and Facebook logins are becoming more commonly available, but as Facebook makes clear, it will provide data to any web site that uses Facebook as a federated authentication provider:

OpenID has been extended, with a newer version of the protocol, to OpenID Connect. This new version allows a web site not merely to authenticate the user but also "to obtain basic profile information about the end-user in an interoperable and REST-like manner". One might be forgiven for suspecting this was to help OpenID gain support with the big web site brigade by addressing the concerns above, but it need not affect us. The authentication provider cannot provide information it does not have; if you suspect that it's trying to acquire it, you can, again, always run your own authentication provider.

Some web sites shouldn't support OpenID, or indeed any distributed authentication scheme at all, because the actions that an authenticated user can perform are too significant to risk any unnecessary failures in the authentication chain. Bank web sites obviously come into this category, but, arguably, interactions with government (e.g. online tax return filing) do as well. However, excepting those, I would like every web site that uses accounts to support OpenID, and I'd settle for a few more every day. If you're putting up a project site, please consider looking around for an OpenID plugin for your site code, and enabling it.

Recently, Joseph Graham posted to the FSFE Fellowship mailing list, saying he'd created a small FluxBB site, https://www.freesoftwareuk.org.uk/, for free-software enthusiasts to chew the fat, arrange pub meets, and so on. I immediately asked him to add OpenID support, which he did. By his own account, he found a plugin with a little searching; installing it was a matter of downloading a ZIP file, putting it where the forum's software could find it, and enabling it via the forum administrative interface. It is true that the plugin has some shortcomings, and he intends to find a better alternative, or write his own, shortly, but getting off on the right foot was not particularly painful.

If you're of a mind to add it to your WordPress site, there is a plugin that permits authentication via OpenID both for commenters, and for login to the main site; installation instructions are linked from the above page, and do not look onerous. Drupal really seems to have gotten the idea; the project notes that "users can create Drupal accounts using their OpenID. This lowers the barrier to registration, which is good for the site, and offers convenience and security to the users". Drupal decided to burn the candle at both ends, by supporting OpenID not only as a client, to allow authentication to a Drupal instance via OpenID but also as a provider, in order to use a Drupal installation as a delegated authentication provider.

The OpenID project maintains a collection of libraries and developer tools, including Apache and PHP modules to allow sites to permit users to authenticate via OpenID, and implementations of authentication servers to run a delegated authentication provider. With this many options, it's surprisingly simple to use OpenID for authentication, and not much harder to support it. While 2017 is unlikely to bring me a flying car or a jetpack, with a little help from the internet it might yet bring me distributed, decentralized identity management.

Comments (10 posted)