GUADEC is the largest regular meeting of GNOME developers, so it
always marks the roll out of a variety of new additions to the
platform. At the 2013 event in Brno, Czech Republic, the new work
includes a significantly revamped geolocation framework, a
library-based approach to email, and predictive text input.
Zeeshan Ali spoke about GNOME's geo-awareness, which is undergoing
a rewrite. Geo-awareness consists of four major pieces, he said. The
first is geolocation, or the "where am I?" question. The second is
the opposite; the user wants to find a different location: a
particular address, a nearby restaurant or gas station, or other
points of interest. The third issue is routing, finding the best way
to get between locations. Finally, there is the user interface topic:
locations, points of interest, and routes all need to be presented to
the user on a map.
GNOME has had the GeoClue library for several years, Ali continued,
but it has always been difficult to use. The APIs it offered were complicated to
use and it exposed too many details to applications and users. For
example, it provided separate APIs for acquiring location information
from the different data sources (GPS, IP address mapping, etc.).
Consequently, Ali and Bastien Nocera have rewritten the library as
GeoClue2 with the goal of being simple.
GeoClue2 can determine location from four different sources:
coordinates from GPS devices (the most accurate), the location of
nearby WiFi access points (which is accurate to just a few hundred
meters), the location of 3G cellular towers (which are accurate only
to a few kilometers), and IP addresses (which are accurate only down
to the city level).
GeoClue2 also offers better privacy controls; the previous version
of the library would provide the current location to any application;
with GeoClue2, GNOME will require the user to confirm location
requests from each application. There are, of course, other privacy
issues involved in geo-awareness. For example, Ali mentioned that
Google had stirred up controversy when it mapped the SSIDs of WiFi
access points. GeoClue2 will not use the Google WiFi database because
doing so requires Google's permission. Instead, it plans to use an
open WiFi database, but the privacy concerns are not entirely clear-cut
with other services either.
GNOME's place-finding functionality is implemented in a library
called geocode-glib, written by Nocera. It provides both geocoding
(that is, taking a feature like a city name or street address and
transforming it into latitude/longitude coordinates) and
reverse-geocoding (which does the opposite, taking coordinates and
identifying the closest street address). This library used Yahoo's
Places API in the
past, but has since been migrated to the open data
which is based on Open Street Map (OSM) maps, and
is also more complete than Places.
GNOME already has a solid mapping UI component called libchamplain,
which renders OSM maps by default. There is also a new mapping
application slated for release with GNOME 3.10, called GNOME Maps.
The routing question is not solved; there is currently a Google
Summer of Code student working on developing a routing system. It is
a tricky problem because routing can involve several distinct modes of
transportation: walking, cycling, driving, and public transport. The
initial plan was to use Open Source Routing Machine
(OSRM), but the public web service OSRM provides is car-only. In
addition, running a separate OSRM instance (an option which would
allow GNOME to find routes using OSM's bike path data, for example) is very demanding: the
project recommends 128GB of RAM for the server.
Other options were discussed at a BoF session on August 7,
including the GraphHopper
service, which is less demanding on the server side. GraphHopper may
also provide an easier solution to the public transport problem, which
is tricky in its own right. The de-facto solution for publishing
public transportation schedules is the Google Transit Feed
Specification (GTFS), which is widely used, but there are still a
variety of countries and cities that offer their own transit
information APIs. Ultimately, a plugin-based approach may make the
most sense (although such "plugins" would not be user-installed components).
The BoF also touched on where users would want to integrate
geo-awareness in the GNOME desktop. There are certainly a lot of
possibilities, from linking addresses in contact entries to the Maps
application, to automatically recognizing and linking address-like
text in emails or chats, to allowing the user to see the location of
geotagged photos. Here again, there are privacy concerns to be worked
out, as well as how best to present the potentially bewildering array
of matches to a geocoding search.
Email as a desktop service
Srinivasa Ragavan spoke about his ongoing work splitting the
Evolution email client up into a shared library and a separate
front-end. His goal is to create a desktop "mail service" that
operates over D-Bus; this would allow for multiple front-end client
options as well as better integration with other GNOME desktop
Stand-alone email clients like Evolution are a bit of a dated
concept, Ragavan said. Mobile device platforms have made users
accustomed to simple "send via email" actions that can be performed
from other applications, but Evolution is not capable of offering such
functionality. Instead, the Evolution application must be fully
started up, complete with checking for new mail from the IMAP server.
In addition, the popularity of GMail as that IMAP provider behind the
scenes causes other problems. GMail essentially offers one giant
INBOX folder, which requires considerable time and memory to load.
Ragavan's plan is to split Evolution's account-authentication,
message-retrieval, and mail-sending functionality into a separate
library called Evolution Mail
Factory (e-mail-factory). GNOME would store a user's IMAP
credentials and start a session daemon to log in to configured email
accounts automatically when the users logs into the desktop.
E-mail-factory would download INBOX messages locally, using the
notification system to alert the user without requiring the Evolution
front-end to start up.
Splitting out e-mail-factory would have other benefits as well, he
said, such as downloading messages during idle periods, and enabling
search of message contents and attachments from other applications.
Desktop integration would allow the lock screen to display new-email
notifications (which is not currently possible), or allow the
new-message-notification pop-up to include an inline reply function.
It would also allow other applications to send email without starting
up the Evolution GUI client. He mentioned LibreOffice and the
Nautilus file manager in particular as applications whose current
"send via email" functionality is painfully awkward.
Progress toward this goal is slow, but moving forward. Ragavan has
split e-mail-factory out in his own Evolution builds, dating back to
the 3.6 series. He is currently working on the D-Bus email API, which
he described as "bare-bones" at present, and he has developed a test
suite. Still to come is porting the Evolution front-end to
e-mail-factory, and the final API for client applications to search
and fetch messages.
Predictive text input
Anish Patil and Mike Fabian spoke about their work adding
predictive input for the Intelligent Input Bus (IBus). IBus is the Input
Method (IM) framework used by GNOME; it is used to speed up text entry
for writing systems that do not match up with the physical keyboard.
Logographic languages with more symbols than fit onto a keyboard and
languages that employ frequent accents can both require considerably
more keystrokes than users find convenient; Patil observed that it is
not uncommon in some languages to require nine keystrokes to type five
characters. Enabling the IM to accurately predict text input can cut
down considerably on the keystrokes required, which in turn makes
Patil then provided a bit of background on how predictive text
input works. Predictions can be based on simple statistics, or on
more complex probabilistic models. The simple statistics approach
would include counting the relative occurrences of letters in a
particular language, or the odds that one word could follow
another according to the rules of the language. More complex
approaches include Markov models, where the probability of a word
occurring next is determined by studying the previous history of the
actual text typed. Markov models can be trained on a set of
training texts, and offer probabilities based on unigrams (single
words), bigrams (pairs of words), or even longer sequences.
The first implementation the two demonstrated was IBus Typing
Booster, which uses a Markov model to predict words, and can be
used with any IM supported by IBus. As the user types words, the
booster pops up autocompletion suggestions which the user can choose
from. They showed it using an onscreen software keyboard, which would
be helpful for mobile and touch-screen interfaces, but of course it
works with hardware keyboards as well. IBus Typing Booster is
limited, however, in that it can only be used by IBus, which
is far from the only IM framework available to GNOME users. It also
relies on the hunspell dictionaries for its word lists, which vary in
quality depending on the language.
Fabian then described the replacement tool in the works; the two
are porting IBus Typing Booster over to a new library called libyokan, which will
support other IM frameworks. It will handle all of the key events;
applications will only have to subscribe to the prediction events and
can present them to the user however they choose. Although the team
is making progress, the speakers did say they are in need of help
testing the new framework, improving the hunspell dictionaries, and
assembling a quality corpus of free training texts.
GUADEC is always a showcase for new GNOME work and experimentation;
one can never know for sure which bits will see the light of day in an
upcoming stable release and which will be radically reworked while still in
development. The new geo-awareness features are on track to become a
major new feature, while the near-term future of the Evolution
re-factoring effort and predictive text input are not as clear.
[The author wishes to thank the GNOME Foundation for assistance
with travel to GUADEC 2013.]
Comments (28 posted)
Packaging applications for Linux is a topic that can expand to fill the
available discussion time—there are security issues, shared
library concerns, privacy implications, and worries about upgrades,
among other subjects. At GUADEC 2013 in Brno, Czech
Republic, the GNOME project discussed the possibility of supporting
the installation of fully sandboxed "apps" like those found on mobile
phone platforms. Such apps would never replace normal application
packages provided in RPM or Debian files, but supporting them would impact
the GNOME platform in quite a few places.
Lennart Poettering introduced the concept in a session on the first
day of the event, and it was revisited later in the week at a
birds-of-a-feather (BoF) session. The goal, Poettering explained, was
to ensure that GNOME (or any other desktop Linux system) could support
apps downloaded from untrusted sources on the Internet without
compromising security. Such apps would be end-user programs, not
system services like Apache, and they would by definition not include
programs already provided by the distributions, like GIMP or Firefox.
User apps downloaded from the Internet differ from distribution-provided applications in several important ways, he said. Obviously,
the fact that the source is untrusted means that they should be
isolated from the system, from private user data, and from other
applications as much as possible. But they may still need a stable
API or ABI in order to provide useful functionality—such as that of
GNOME Shell extensions. The same user-level app may also be
installed separately by multiple users, which is not what most
distribution packages are designed for, and if they follow the "app
store model" they will likely be distributed as single-file bundles.
The trust issues can largely be dealt with by technical means,
Poettering said, while there are policy decisions to be discussed for
other issues, such as what APIs the system should provide. But
regardless of the specifics, he said, GNOME should offer support for
apps, since it is in a position to do so in a free, community-driven,
and vendor-agnostic manner.
Getting to that point breaks down into nine simple steps, he said
(although, thanks to the presence of a "step 2.5," the total list
ran a bit longer than most people would probably consider to be
"nine"). Poettering argued in favor of implementing much of the
security sandboxing at the lowest level possible, using kernel tools,
on the grounds that the lower the level, the greater the security, and
the less developers and users
would have to think about it. User-space application isolation cannot
be done in a simple way, he said.
The first step is to get kdbus, the in-kernel implementation of
D-Bus, completed, he said. This will serve as a secure conduit for
passing messages in and out of each app sandbox, allowing kernel-level
enforcement of message isolation. The systemd side of kdbus is "very
near working," he said, although it needs porting to the latest D-Bus API.
But it should be in a presentable form by the end of the year.
The second step is to implement app sandboxes, built on top of
namespaces, seccomp, control groups, and capabilities. These are all
very generic kernel tools, he observed, which makes them flexible.
Each app should get its own control group, he suggested, which will
enable several other useful features, such as the ability to freeze
background apps or boost the foreground app. Several mobile Linux
platforms have implemented this freeze/boost feature, including Android and Maemo.
Step 2.5 flows from this sandbox definition; sandboxed apps will
need to be well-contained, including where they can store bundled
libraries and where they can place temporary data. This will dictate
the specification of an app-centric analogue to the Filesystem
Hierarchy Standard (FHS) to define where apps can store what, he
said. It may not need to be done within the FHS itself, he added, but
it is not a GNOME-specific subject, either—getting it right is a
matter of getting the right people together to hash it out.
Step three is a feature that Poettering called "portals;" an
inter-process communication (IPC) infrastructure defining what apps
can request and respond in and out of the sandbox. Portals are akin
to Android's Intents,
he said: they would be an interactive security scheme that doubles as an integration
technology. Portals would be run over kdbus. In an example scenario, one app could request a photo from the
system's webcam; the system could respond by telling the app what
other apps had registered to provide the webcam photo-access feature
(if there is more than one), and when the photo is snapped, kdbus
would return the image to the app that made the original request.
This means the app can be isolated from the photo-taking function (and
the hardware access it requires), which is better for security and
means there is less for the app author to implement.
Step four involves working out the best way to package apps as compressed
filesystems. A requirement of the "app" model, he said, is that apps
need to be deliverable to users as a single file, for ease of use and
portability. A similar approach is used by Mac OS X, he said,
where .app bundles appear to be a single file. On Linux, he said,
they would probably involve compressing multiple
filesystem partitions—which would then be mounted to the system with a
loopback filesystem. There would need to be separate partitions for
each architecture supported (32-bit and 64 bit x86, plus ARM), as well
as one for common files.
Step five would involve extending GLib and related GNOME libraries
to support the sandboxed apps. In particular, the desktop needs to be
able to recognize when a new app is uncompressed and mounted to the system, and treat
its executables like a system-wide program, making it available in the
application launcher, search framework, and so on. Step six would involve deploying a
sandbox-aware display manager, presumably Wayland. Among other
things, the display manager would need to support cut-and-paste and
drag-and-drop, between sandboxed apps and the system. Step seven would
involve defining a configuration scheme in dconf for sandboxed apps.
Step eight is defining a set of "profiles" for apps: target sets of
libraries and APIs that app developers can test against in order to
release their code. Poettering described several possible profiles,
such as a generic Linux Standard Base (LSB) profile, a profile for
games (which tend not to receive many updates and thus need long-term
API stability), and a GNOME profile, which would offer better
integration with desktop services than a generic profile like the LSB
option. The final step is defining an app store model, and supporting what are
hopefully multiple, independent app stores from various vendors.
Time ran short in the session, in part because Poettering took
several questions during the early steps of the nine-point plan (in
fact, the final few steps in the plan had to be explained in rapid
succession and in less detail). But there was one pointed question
raised at the very end of the talk: how would an "app" model for GNOME
or other Linux desktop environments handle the desire of app
developers to bundle shared libraries into their downloads.
Poettering admitted that this is a problem that needs solving, but he
contended that the approach should be "support bundled libraries, but
deal with the fact that they suck." And, he added, they suck
primarily because of the security problems that they cause. Thus, they must be
addressed with security tools, and providing a solid sandbox is the
There are plenty of other challenges ahead for GNOME (or any other
Linux platform) interested in offering an "app store"-like experience
on par with those touted by Android and iOS. Due to the time
constraint, the later steps in Poettering's nine-step plan barely got
any attention at all, and some of them are quite complex—such as
defining the "profiles" to be offered for app authors, and then
maintaining the profiles' advertised APIs in a stable fashion over
multiple release cycles. The "portals" concept (which has been under
discussion for some time already)
and the packaging of compressed app images (an idea that is being
investigated by several independent free software projects already)
spawned quite a few questions during the talk, questions to which the
answer often involved some variation of "we still need to discuss
The discussion of exactly what interfaces would be covered by
the "portals" began at the August 7 App Sandboxing BoF session, but
there are plenty of questions remaining. The big one is the simplicity and
scope of the portal definitions themselves (e.g., how many options
should be accessible in the "print this document" portal), but there
are other as well, such as how the permissions system would allow
users to choose or restrict an app's access to a portal, and whether
system limitations like the maximum message size of D-Bus will prove
to be a roadblock for certain portals.
Attendees pointed out several times in the "hallway track" at
GUADEC that currently the project is only at step two of Poettering's
nine ten. It will, no doubt, be quite a long time
before any "app store" for GNOME reaches users. But it is also clear
from the chatter at the conference that most people recognize the need
to pursue such a goal. For some, the target is much simpler (such as
providing a way to run Android apps on the Linux desktop, or
supporting packaged HTML5 web-apps), but sitting still and not
exploring the next generation of application delivery systems is
simply not a viable option for GNOME—nor for any other Linux
environment that sets out to attract end users.
[The author wishes to thank the GNOME Foundation for assistance
with travel to GUADEC 2013.]
Comments (21 posted)
is a project intended to make
anonymous network browsing globally available. By encrypting connections
and routing them through a random set of intermediary machines, Tor hopes
to hide the identity and location of users from anybody who might be
attempting to spy on their activities. One can only imagine that recent
revelations about the scope of governmental data collection will have
increased the level of interest in tools like Tor. So the recent news of a
compromise of the Tor system with the potential to identify users is
certain to have worried a number of people; it also raises some interesting
questions about how projects like Tor should deal with security issues.
The Tor hidden
service protocol allows services to be offered anonymously through the
Tor network. Many of these services, it seems, are concentrated on servers
a company called Freedom Hosting. They vary from well-known services like
Tor Mail to, evidently, a wide range of
services that most of us would rather not know about at all. The alleged
some of those services was recently emphasized when Eric Eoin Marques, the
alleged owner of Freedom Hosting, was arrested
on child pornography charges.
About the same time, users of various hidden services started reporting
browsers. This program exploited a vulnerability in the Firefox browser to
gather information about the identity of the user and send it off to an IP
address that, it has been claimed,
is currently assigned to the US National Security Agency (though some backpedaling
is happening with regard to that claim). The exploit does
not appear to have been used for any other purpose, but what was done is
enough: Tor users hit by this code may have lost the anonymity that they
were using Tor to obtain in the first place.
Who are those users? The hostile code was designed specifically for users
running the Tor Browser
Bundle (TBB) on Windows systems. TBB is based on the Firefox Extended
Support Release with a number of security and
anonymity features added on
top. Anybody using Tor in a different configuration — or who was using a
current version of TBB — will not be vulnerable to this particular
attack. Linux users, perhaps on a system like Tails, were not targeted, but there is
probably no inherent reason why an exploit for Linux systems would not have
The specific vulnerability exploited by this attack is MFSA-2013-53,
otherwise known as CVE-2013-1690.
This vulnerability was patched in Firefox ESR 17.0.7, released on
June 25, 2013. The Tor project incorporated this update and released
new TBB versions one day later. So anybody who updated their TBB
installation in the time between June 26 and when the exploit was
launched will never have been vulnerable. Those who didn't get around to
updating found themselves in a rather less comfortable position.
What should Tor change?
Needless to say, Tor users have been shaken by this series of events and
would very much like to avoid seeing a repeat in the future. So there has
been a fair amount of discussion regarding TBB and how the Tor project
responds to vulnerabilities. But it is not at all clear that massive
improvements are possible.
One possibility is to reduce the attack surface of the browser by disabling
address space would make a lot of attacks impractical. TBB does ship with
the invaluable NoScript extension, but,
of web sites. One does not know anger until one discovers, at the end of
snippet (usually for some relatively useless purpose) and the form cannot
be submitted. So, in the interest of having TBB actually be usable, recent
There is a
project in the works to equip TBB with a "security slider" that would
allow users to select the balance between security and usability. But
that feature is not yet ready for release; in the meantime, TBB users may
want to consider enabling NoScript on their own. But, as the Tor project
pointed out in its
And finally, be aware that many other vectors remain for
attack, but many other big vectors exist, like css, svg, xml, the
There has been a certain amount of complaining that the Tor project
silently fixed the vulnerability in June when it should have been making
sure that users knew about the scale of the problem. Some users have gone
so far as to state that TBB is a forked
version of Firefox and, as such, it should be issuing its own security
The problem with this idea, of course, is that the Tor project is not
really in a position to understand all of the many fixes applied by the Firefox
developers. Even then, it is not always clear at the outset — even to
Firefox developers — that a
specific bug is exploitable. As Tor developer Jacob Appelbaum put it, the project just does not have the
resources to duplicate the advisories that Mozilla is already issuing when
it releases a browser update:
We're understaffed, so we tend to pick the few things we might
accomplish and writing such advisory emails is weird unless there
is an exceptional event. Firefox bugs and corresponding updates are
not exceptional events.
Experience quickly shows that security advisories are also far from being
exceptional events; more advisories would not necessarily convince that
many more users to upgrade their TBB installations. TBB already checks to
see if it is out of date and informs the user if an upgrade is available;
there is talk of making that notification stronger, especially as the time
since the update was released increases. Automatic updates were also
discussed, but there seems to be little interest in taking that path; there
seems to be some fear that the update mechanism itself could be targeted by
In the end, there are a couple of straightforward conclusions that can be
drawn, starting with the fact that there may not be a whole lot the Tor
project can do to avoid a repeat of this type of attack. The simple truth
seems to be that we, as a community, have neither the resources nor the
skills to properly defend ourselves against attackers who have the
resources of national governments behind them. Software as complex as a
browser is always going to have vulnerabilities in it, even if its
developers are not constantly adding new features. Providing software of
that complexity that is sufficiently secure that people can depend on it
even when their lives are at stake is one of the great challenges of our
time; so far, we have not found the answer.
Comments (12 posted)
Page editor: Jonathan Corbet
Next page: Security>>