LWN.net Weekly Edition for August 8, 2013

New GNOME components for geolocation, predictive text, and more

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.

Geolocation

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 service Nominatim, 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 components.

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 users happier.

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)

Apps for GNOME desktops

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.

9½ feats

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.

Open questions

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 correct approach.

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 this."

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)

Tor and browser vulnerabilities

Tor 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.

What happened

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 hosted by 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 nature of 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 that those services were sending a malicious JavaScript program to their 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 worked.

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 JavaScript; taking away the ability to execute code in the browser's address space would make a lot of attacks impractical. TBB does ship with the invaluable NoScript extension, but, as any NoScript user quickly discovers, turning off JavaScript breaks a lot of web sites. One does not know anger until one discovers, at the end of filling in a long web form, that the "submit" button runs a JavaScript snippet (usually for some relatively useless purpose) and the form cannot be submitted. So, in the interest of having TBB actually be usable, recent versions of TBB ship with NoScript configured to allow JavaScript on all sites.

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 August 5 advisory, disabling JavaScript is far from a complete solution:

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 advisories.

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:

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 attackers.

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

Inside this week's LWN.net Weekly Edition

• Security: Subverting HTTPS with BREACH; New vulnerabilities in chromium, gksu-polkit, mozilla, samba, ...
• Kernel: A survey of memory management patches; Unreviewed code in 3.11.
• Distributions: Changes brewing for openSUSE?; Jean-Baptiste Quéru quits AOSP, ...
• Development: High-resolution displays in GNOME; Calligra 2.7; Bison 3.0; Firefox 23; ...
• Announcements: News from FSF and FSFE; events.

Next page: Security>>