LWN.net Weekly Edition for September 6, 2013

Firefox OS on the ZTE Open

There was a period where it appeared that the smartphone industry would be dominated by closed products and non-free software. Android has done a lot to change that situation; it is now possible to own a hackable device that runs mostly free software. But it would be nice to have some viable alternatives, preferably even more free and more Linux-like. Among the many would-be contenders for the title of leading alternative, Firefox OS offers a special appeal. It is, after all, a Linux-based system built by an organization that has a history of looking out for the interests of its users. So when the opportunity came along to try out Firefox OS on real hardware, your editor did not hesitate for long.

The ZTE Open

The device in question is the ZTE Open, a Firefox OS handset that can be had for a mere $80. That is a low price for a smartphone, but it is consistent with Mozilla's apparent strategy of targeting the cheaper end of the market. Cheap is nice, but, as one might expect, some severe compromises had to be made to arrive at that price. The phone uses an oldish Qualcomm MSM7225A processor with only 256MB of memory. The camera offers a two-megapixel sensor, which is low by contemporary standards. Internal storage is minimal, but the phone comes with a 4GB MicroSD card.

Visually, the device is smaller than many current devices. It is also bright orange; it looks a lot like a Nexus One that has been outfitted for hunting season. The 480x320 HVGA screen is decidedly low-resolution by current standards. As one might expect, the device is often slow to respond, especially when switching between applications. Perhaps most annoying, though, is that the touchscreen itself is often unresponsive. Using the Firefox OS on-screen keyboard can be a slow and painful experience.

The Firefox OS interface has not changed a great deal since this review was written at the end of last year. The annoying three-step process (hit the power button, swipe upward, tap the "unlock" icon) to unlock the screen is still necessary. Swiping toward the left on the home screen yields a list of installed applications, while swiping to the right yields a list of installable application categories. Strangely, many of the categories are not initially visible on that screen. Instead, one must hit the "more" button to see the full list of categories; only thereafter is it possible to see which applications can be found therein. There is a reasonably long list of available applications, but relatively few that would be familiar to iOS or Android users.

Application installation is a matter of holding a finger down on the relevant icon. Since applications are all web-based, though, there is no real need to install them unless one wants to run one offline or have the icon in a handy place. There is a permissions model for applications, but that is all hidden from the user; for the most part, users are supposed to rely on the maintainers of the application "marketplace" to ensure that malicious applications are not made available. The one exception is for location data; the system will ask the user before allowing an application to access the user's current location.

There is a basic email client that, unfortunately, could not be tested, since it refuses to deal with mail servers that have self-signed certificates. The web browser is Firefox, of course; it works as expected. There is a basic mapping tool (using "HERE") that can generate driving directions; there is no turn-by-turn navigation available, though. As an added "benefit," the maps include location-based advertisements. Weather information is available through an Accuweather app; there is also a basic calendaring tool. The contact manager can import data from Facebook, but not from other sources (Google, for example).

At the interface level, one of the most striking decisions is the complete absence of a "back" button. The result is that one often seems to end up in some application-specific dead end, with no recourse other than to hit the "home" button and drop out entirely. Getting rid of "back" may make application development easier, but the result seems to be less friendly for the user.

The home button will, if held down, produce a scrollable screen showing the currently running applications. The user can then switch to one of those applications; there is an option to close running applications as well. This screen is supposed to show a thumbnail with the current screen contents of each app, but those thumbnails are often blank for some reason.

All told, the ZTE Open is reminiscent in many ways of the first Android phones. It is slow, somewhat buggy, and the functionality is not up to what the market leaders provide. Whether Firefox OS will yet turn out to be a disruptive technology like Android was remains to be seen.

Under the hood

One does not need to look too hard at Firefox OS to realize that its developers have taken advantage of a lot of free infrastructure from Android. The kernel on the ZTE Open is an Android-derived, bleeding-edge 3.0.8 model, with wakelocks and all. Services like binder are running. The Android USB debugging protocol is supported, so tools like adb and fastboot can be used in the usual manner (though there is an update that should be applied for fastboot use). Much of the graphics subsystem is built on the Android "gralloc" API as well. All told, Firefox OS has benefited strongly from the availability of the Android code as a base to build on.

There appears to be no available terminal emulator application for Firefox OS. But one can, naturally, get a shell on the device by plugging it into a USB port and running adb shell. The shell environment is based on BusyBox and is rudimentary — but not worse than what one encounters on an Android device. It is also an unprivileged shell; there does not appear to be any way to gain root access short of exploiting a vulnerability — or installing a new version of the operating system.

In the limited time available your editor was unable to succeed in the latter task — replacing the operating system. There is extensive documentation on how this should be done on the Mozilla web site, and it is a simple matter of patience to download the 12GB "source" tree ("source" being in quotes because it includes things like a binary cross compiler, video files, and more). The actual build process requires that the phone be connected so that a number of binary files can be copied off of it; these (proprietary) files are needed to build a replacement image. Thereafter the build fails (in an equal manner on Ubuntu, Debian, and Fedora boxes) after a long list of warnings. Somewhat discouraging.

Perhaps this particular problem is a temporary setback resulting from the state of the source tree when this build was attempted. But it's clear that, like building Android, making a new Firefox OS image is not a task for the faint of heart. Should this system take off, future users are far more likely to exercise their freedoms once a CyanogenMod-like project comes along to take care of a lot of the details.

Conclusion

But will Firefox OS take off? It is hard to see the system, as demonstrated by the ZTE Open, displacing Android anytime soon. It is too slow, too rough-edged, and lacking too many third-party applications. Most people with access to a recent Android-based handset are likely to stick with that rather than shift over to Firefox OS.

But the world is full of people without access to such a handset. Mozilla seems to be making a play for the attention of many of those people by going after the low end of the market. After all, $80 will not buy a particularly satisfying Android device either; it is hard to imagine Android running on hardware like the ZTE Open in any kind of pleasing way. Perhaps Firefox OS will find a place running on low-end devices; by the time the system matures (and it does appear to be developing quickly), there might just be an established user base for it.

Working with this device reminded your editor of a scene from Charlie Stross's classic Accelerando:

If we can envision an era where cardboard telephones can be obtained from a box of cereal, it is not much of a stretch to think about those phones running a relatively undemanding system like Firefox OS.

Meanwhile, though, Firefox OS hopes for a place on the plastic devices that we use now. Anybody wanting to experiment with the system can build it for a number of current devices, including most recent "Nexus" phones. If enough developers do that and start taking the system in interesting directions, if more applications appear, and if people actually buy Firefox OS devices, it may well develop to a point where it is a realistic competitor to the more established mobile operating systems. Another free Linux-based mobile system would be a good thing, so one can only wish Mozilla luck as it pursues that goal.

Comments (87 posted)

The Linux Foundation ventures in a new direction

The Linux Foundation (LF) is well-known for its support of Linux (obviously), but over the last few years it has also taken on the role of a shepherd for other open source efforts. One of the earliest examples was the now moribund Nokia-Intel collaboration on the MeeGo mobile operating system. Others, such as Yocto, OpenMAMA, OpenDaylight, Tizen, and Xen all seem to be chugging along at some level, while CodeAurora Forum and FOSSBazaar seem rather quiet. All of those projects, though, have a fairly strong connection to Linux and open source software, but the same cannot be said for the most recent LF collaborative project: OpenBEL.

The "BEL" in the project's name is for Biological Expression Language, which gives an idea how far from open source software the LF has ventured. BEL is a data format used by life sciences researchers to encapsulate their research findings in a form that can be used by programs. It can represent the relationships between various biological entities as discovered in experiments. Importantly, BEL can store these relationships in context, where that might include the experimental regimen, research cited, and other important characteristics of those experiments.

In some ways, BEL is similar to the ideas behind the semantic web and other structured knowledge efforts. It is meant to structure information in a way that allows computers to "reason" about it, potentially finding correlations or other kinds of relationships that are present in the data, but difficult for a human to uncover. The OpenBEL web site notes a number of areas where BEL-encoded information could be useful: "network visualization of neural brain function; understanding of complex inter-related disease biology; comparison of human diseases with various animal models; deep investigation of drug efficacy and toxicity; as well as development of innovative therapeutics and diagnostics for personalized healthcare".

The OpenBEL project came about in April 2012, but BEL itself was opened up by Selventa (formerly known as Genstruct) in 2011. Beyond the BEL language, Selventa also open sourced several tools to visualize and curate BEL "knowledge graphs". At the end of August, the LF announced that OpenBEL had become one of its collaborative projects.

Essentially, the LF is using its knowledge of open source to assist the project in "converting" to an open source mindset. That mindset includes governance and infrastructure for projects that are targeted at collaboration between competitors, which are things that the LF has a fair amount of experience in. But biological research (and "knowledge engineering") are far afield from open source operating systems and other fairly closely related projects. Branching out to a project like OpenBEL is an effort to take the ideas of open source and apply them more widely. It evinces a similar goal to that of Red Hat's opensource.com.

The OpenBEL members page only lists Selventa and Foundation Medicine currently, but that may well be part of why the project is now with the LF. By providing a neutral ground for collaboration, the LF may seem less threatening for Selventa competitors that might be interested in the project. In addition, the LF has a fair amount of credibility in bringing competitors together to work on something in all of their interests—successfully—while they still compete in lots of other areas. One look at the LF members page will show rival silicon and hardware vendors, distributions, car companies, software vendors, and so on.

There are some clear advantages for the OpenBEL project, but it's also worth asking what the LF gets from taking on the project. Certainly the ability to further push the "open source paradigm" in new directions has some attraction. One would guess there is some money involved as well. Beyond that, though, the LF has set itself up to be able to quickly and easily serve these new communities. Knowledge about open source, its governance and management, along with the infrastructure to support this kind of collaboration are all present in the organization. Cranking out another collaborative project may almost be "old hat" at this point.

That's probably overstating things a bit, but it is clear that the LF is presenting itself as the "collaboration organization". There is, perhaps, a risk that it will spread itself too thinly, but there don't seem to be any real indications of that, at least yet. Some of the crop of collaborative projects have either withered away or may be on their way to doing so, which might pose a kind of credibility issue at some point. It may behoove the organization to be a little pickier in the future. But, overall, OpenBEL is an interesting foray for an organization that has previously stuck pretty close to home. It will be worth watching to see where things go from here.

Comments (none posted)

Mailpile targets webmail and attempts to raise funds

Email is not only one of the killer Internet applications, but it is also central to the way the free software community functions. Thus, the shift in recent years toward proprietary webmail clients poses a serious obstacle to people who value software freedom—not to mention people with all-too-real concerns about the privacy of their communications. A small team of developers in Iceland is working to improve the situation with the Mailpile project. In a short amount of time Mailpile has attracted a considerable following and a successful crowfunding campaign, although trouble is looming that could delay the project's ability to collect those donated funds.

The concept

Mailpile is the brainchild of Bjarni Einarsson, Smári McCarthy, and Brennan Novak. The trio launched the project on August 3 at the Observe, Make, Hack (OHM) conference held near Amsterdam. As Einarsson's slides [PDF] put it, the chief technical goals of the project are to make decentralization easy, make migration painless, make email encryption understandable, and to make a mail client that offers better spam filtering than that offered by the big email providers . Mailpile is designed to be "personal web-mail," meaning that it can be run anywhere from a remote server to a local machine. The interface will be an HTML, CSS, and JavaScript application that runs in the browser, while the back-end code will be written in Python. Despite the browser-based interface, Mailpile will be a mail user agent only, and users must rely on other software for mail transfer and mail delivery. The license chosen is the Affero GPLv3.

Collectively, the ability to host one's email anywhere and the ability to migrate it from one location to another protect the user from vendor lock-in. Self-hosting also preserves the user's privacy by eliminating data-mining by the email provider and ads in the client application. Naturally, hosting one's email on a remote server introduces security risks, which is why the team is also intent on building OpenGPG encryption support into the client.

Making email encryption easy-to-use is a tall order. McCarthy, the security lead on the team, described Mailpile's encryption workflow as a "core part of its construction" as opposed to "tacked on with a plugin," but there are precious few details about how this will be accomplished. The project's GitHub repository has a discussion thread on the topic that includes some interface mock-ups, although they deal primarily with how options are presented to the user. While there is definitely room for improvement on that front, the core concepts of public-key encryption may prove harder to explain than they are to show in a UI.

There is more detail on the project's blog about the other architectural decisions. One interesting facet of the design is that the message storage system is built around searching, not IMAP's traditional notion of folders. Instead, the user will be able to set up "filters" that constitute stored searches, so that a filter like from:example.com will take the place of an Example Co. folder. There will also be tags that can be applied to filter output, making it possible to construct other message-sorting schemes. The application will come with a set of "sensible" default tags and filters (like "Inbox" and "New"), and perhaps will include filters for well-known senders like Facebook and Twitter, too.

Einarsson justifies this search-driven approach by noting that "email used to be big" but now it is small—small enough in fact that an account's email metadata can fit entirely into RAM. The current estimate is that Mailpile's index consumes 250 bytes per message, including the overhead added by Python, which he calculates is sufficient on a modern system with several gigabytes of RAM. Mailpile will support several storage backends, including mbox, maildir, gmvault, and IMAP. Regardless of the source of the email, Mailpile will build a single, unified search index that is stored in a special subfolder of the user's home directory. For security purposes, the index keys can be one-way hashed, and all user settings can be GPG encrypted.

Despite the (some would say) lofty goals of Mailpile, at this stage the project is intent on writing a considerable proportion of the code from scratch—including the search engine—in standard Python. The reason is that not relying on external dependencies will make the product easier to package. The goal is to produce a tool that can be run on Linux, Mac OS X, and Windows.

The code is available on GitHub, and as of press time the web interface is only beginning to take shape, with a terminal-mode user interface offering access to more features (such as tagging and filtering) through a command-line interface. IMAP and POP3 support has not yet been implemented, nor has spam-detection or decrypting GPG-encrypted messages, but the Mailpile CLI can encrypt the local mail storage and settings with gpg-agent.

Capital ideas

Shortly after announcing the project at OHM, the Mailpile team launched a crowdsourced fundraising campaign at Indiegogo. The target amount is US $100,000, which Mailpile reached well ahead of the scheduled September 10 deadline. The launch of the campaign attracted considerable attention in the popular press, which surely contributed to the rapid meeting of the fundraising target.

As of today, the pledged total stands at $139,798 dollars and counting, but the project encountered a surprise obstacle on August 31. Novak posted a blog entry on September 5 explaining that PayPal (one of several payment methods accepted by Indiegogo) had canceled the debit card associated with the project's account, and informed him that a block had been placed on the account to prevent transferring funds out. After an inquiry to PayPal, a clearer picture emerged:

The Mailpile team felt that this request was out of PayPal's jurisdiction, and, moreover, out of line with Indiegogo's policies on the same subject. Indiegogo's policy, he said, is to transfer "all funds to successful campaigns within 15 days of their conclusion. If IndieGoGo can do it, so can PayPal."

Indiegogo is an official Paypal "partner," which does make it surprising that the two companies would be significantly out of sync. However, Mailpile's Indiegogo campaign is of the "flexible funding" variety, meaning primarily that the funds would be released to Mailpile even if the target amount was not met. But Indiegogo's disbursement policy indicates that flexible funding projects have donations from PayPal users transferred immediately to the project's PayPal account, so the "within 15 days of conclusion" rule does not apply to any donations made through PayPal itself. In a separate post on the subject, Einarsson estimated that these funds added up to $45,000.

Einarsson also said that the project has asked its legal representative, the Software Freedom Law Center (SFLC), to help resolve the situation, but that in the meantime it has disabled PayPal as a funding option. Intriguingly, his post also said that PayPal's rationale for cutting off access to the funds was to guard against "chargebacks," which is when a buyer attempts to retroactively reverse a transaction through his or her credit card company.

PayPal allows chargebacks when a purchased item is never delivered or is significantly different than it should be. It is not entirely clear that the chargeback issue is identical to concern over a budgetary breakdown, but that would explain quite a bit. After all, so far Mailpile has not delivered the software that it describes in its campaign material—it is a brand-new project that has set some lofty goals by anyone's standards.

In addition, the campaign site is quite vague on how the funds will be spent, especially those funds that exceed the target amount. In a post about "stretch goals," the team lists options like "raise our salaries" and "set money aside for a 'rainy day' or unexpected events"—which may not sound reassuring to those in the banking industry.

Late on September 5, Einarsson posted a brief update to his post about the PayPal trouble, stating just that the account had been unfrozen. No word yet on whether this means that the payment processor is backing down on its demand to see specifics about how the donated funds will be spent—nor is there any guarantee that another freeze will not be placed on the account without advance warning.

Nevertheless, the project has met its fundraising goal and is close to meeting it even without the PayPal donations, so users will get to see what the Mailpile project can produce. The campaign promises the first milestone in January 2014. Finding trouble-free fundraising for free software development may take noticeably longer, though.

Comments (8 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Blocking DPI with Dust; New vulnerabilities in asterisk, foreman, imagemagick, mysql, ...
• Kernel: 3.12 merge window; Lockrefs; Integrating the ION memory allocator.
• Distributions: Fedora mining for COPR; GNU Linux-libre 3.11, RebeccaBlackOS, ...
• Development: Ubuntu's Click app format; Cassandra 2.0; MediaGoblin 0.5; the ALERT Project concludes; ...
• Announcements: SUSE's LibreOffice team moves to Collabora, Microsoft plus Nokia, Thoughts on the CC Summit, ...

Next page: Security>>