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
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
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
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
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
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
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.
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:
Amber clutches the phone like a lifesaver: It's a cheap disposable
cereal-packet item, and the cardboard is already softening in her
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 (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
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
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
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
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
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
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)
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.
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
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
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.
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
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
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
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:
After 4 phone calls, the last of which I spoke to a supervisor, the
understanding I have come to is, unless Mailpile provides PayPal with
a detailed budgetary breakdown of how we plan to use the donations
from our crowd funding campaign they will not release the block on my
account for 1 year until we have shipped a 1.0 version of our
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
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
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
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
Next page: Security>>