LWN.net Weekly Edition for November 20, 2014

The Debian project votes on init system coupling

After a long and contentious discussion, the voting on the Debian project's general resolution about init system coupling has come to a close. The results say some interesting things about what the Debian developers are thinking as a whole. This decision should bring the discussion on init systems in Debian to a close for a while — or so one would hope.

As readers will recall, the initial resolution proposed by Ian Jackson was intended to prohibit Debian from shipping any package that only worked with a single init system. It was proposed out of a fear that running a fully functional Debian system without systemd would eventually become impossible, even though there are currently no packages in the repository that have such dependencies. Three alternatives were added to the vote via amendments; none of those included the ban on coupling found in the original proposal. With the mandatory "further discussion" option, that meant that Debian developers had five alternatives to rank in their ballot; see this article for details on each of them.

In the end, 483 developers took the time to vote on this issue; that is, as it turns out, the largest turnout for any Debian general resolution in the project's history. In the end, they opted strongly for Option 4, proposed by Charles Plessy, which read in its entirety:

The majority opinion of the project, thus, was that the general resolution should not have been proposed in the first place. That could be seen as a fairly strong rebuke to Ian for having caused the vote to happen. Arguably Ian took it that way; his resignation from the project's technical committee, which has been at the center of much of the systemd debate, came immediately after the vote. He did not, however, fully accept the opinion expressed by the project:

So that is where things stand; there will be no immediate change of course in the Debian project. By all indications, the upcoming "jessie" release will work fine without systemd. What happens after that depends on the actions of a lot of developers, many of whom are not part of the Debian project. But it would be somewhat surprising if the project were to abandon init system diversity altogether.

Meanwhile, the project needs to pick up the pieces and get back to the business of developing one of our community's preeminent distributions. It is interesting to note that, in this vote, the "further discussion" option was by far the least popular of all; it should not be surprising that few people have an appetite for more talk on this topic at this point. If the Debian project is to recover quickly from this year's stresses, it will be necessary for those who demonstrably do have an appetite for further discussion to suppress their desires somewhat.

Some recovery will certainly be required; among other things, the project has now lost three members from its technical committee. There is currently a call for nominations for replacement committee members outstanding; the remaining committee members hope to get the replacement process going in December. The resignations represent a significant loss of experience and expertise on the committee; one hopes that equally qualified replacements can be found.

Tollef Fog Heen's departure from the Debian systemd team is also a costly loss for the project. But it represents an even bigger potential loss: if Debian developers cannot work on the projects that interest them without dealing with a constant stream of attacks, developers will quickly become harder to find. The environment around the systemd debate has become toxic indeed. It would behoove everybody, regardless of where they stand on the issue, to think about how they are pursuing their aims. Somehow, we urgently have to find a way to separate the legitimate technical debate from the trolls and griefers, and from those who want to portray it as the final holy war.

If we think about the people who are widely admired in our community, they mostly share one common characteristic: when they didn't like a particular situation, they sat down at their keyboards and did the work to create the world they wanted to see. That must be the best solution to the current controversy as well. Flame wars don't change the world, but working code can. With luck, Debian's developers will now be able to get back to the business of creating that code with a minimum of "further discussion."

Comments (87 posted)

The EFF announces "Let's Encrypt"

The Electronic Frontier Foundation (EFF) has long been a proponent of encryption for web traffic. Its most recent move is another big stride in making HTTPS encryption universal—or nearly so. On November 18, the EFF announced Let's Encrypt, which is a combination of a new, free certificate authority (CA) along with software to make it easier for web site owners to manage the SSL/TLS certificates that make HTTPS work.

HTTP is a widespread protocol, but its design causes it to be insecure. Data is transferred in plaintext, which leaves it vulnerable to interception and manipulation by intermediaries in the network (e.g. ISPs, wireless routers). HTTPS, on the other hand, is designed with security in mind. It was originally targeted at internet commerce, but as time went on, various kinds of attacks, tracking schemes, and government surveillance have made it clear that, for privacy and security, it makes sense to use HTTPS everywhere.

There are a few barriers to ubiquitous HTTPS, however, including the cost of SSL/TLS certificates that are used to authenticate web sites to browsers and the complexity of managing those certificates. Let's Encrypt tries to address those two barriers. In particular, one of the bigger hurdles for many administrators is simply dealing with the process of submitting keys and signing requests to CAs. That is a complicated, error-prone process that Let's Encrypt is trying to greatly simplify.

Let's Encrypt is a joint effort with Mozilla, Cisco, Akamai, IdenTrust, researchers at the University of Michigan, and the EFF, according to the press release. It is overseen by the Internet Security Research Group (ISRG), which is a US 501(c)(3) non-profit corporation.

Given the plan to run a CA, IdenTrust and Mozilla seem likely to play key roles. In order for certificates from a CA to be accepted in browsers, the root certificate for the CA must be accepted. IdenTrust already has a root certificate in most browsers' root stores, while Mozilla determines which certificates get into Firefox's root store. If it didn't have a root certificate that is accepted by browsers, Let's Encrypt could have run into the same lack of adoption that another gratis CA, CAcert, encountered. With IdenTrust and Mozilla on board, that would not seem to be a problem. Sites using Let's Encrypt will avoid the scary browser warnings that come from unverified certificates.

The principles outlined on the initial Let's Encrypt blog post read much like those of a free-software project—that's because it is. In particular, the protocols used to simplify the issuing and renewal of certificates, as well as the code used to implement them will all be available. There is also an explicit call for cooperation and collaboration. In addition, the CA will be run transparently: "All records of certificate issuance and revocation will be available to anyone who wishes to inspect them."

A video [YouTube] shows a preview of the Let's Encrypt software in action. It is a Python program that a user will run on their web server. It examines the Apache 2 configuration (presumably other web servers will be supported down the road) to look for web sites on the system that need SSL/TLS certificates. Users will need to demonstrate that they control the domain(s) in question, then the program can request, download, and install certificates to turn an HTTP site into an HTTPS site with just a few clicks. There are plans for setting up automatic renewal of certificates as well.

The letsencrypt.py program logs each step that it takes and allows any and all of the process to be reverted if administrators object. It is also said to make certificate revocation easy. All of the automation is being handled by the new Automated Certificate Management Environment (ACME) protocol.

There may be an additional hurdle for some sites: the processing overhead for encrypting all the traffic. While newer processors may have largely mitigated the encryption performance penalty, that penalty has not been eliminated for everyone. There is not really anything that Let's Encrypt can do about that, however, but it should be a fairly small minority of sites that are affected.

Overall, Let's Encrypt looks like an ambitious project, but seems like it also has some significant backing. Because of that, it will hopefully fare better than the EFF's Open Wireless Router project, which appears to have gone silent of late. Getting most of the web to use encryption is a noble goal; with luck, other internet communication mechanisms (e.g. email) will spawn similar efforts someday.

Comments (37 posted)

A Firefox OS 2.0 preview on the Flame

Mozilla has rolled out a preview of the next major milestone in Firefox OS, its HTML-driven mobile operating system. The upcoming release is branded Firefox OS 2.0 and incorporates a number of significant changes. The preview was released first as an over-the-air update available for the Flame developer phone; since I had recently acquired such a device, I decided to take a look.

Out of the box, the Flame runs Firefox OS 1.3, the early-2014 release that is still the stable branch found on most production phones in the wild. Firefox OS releases are—not surprisingly—tagged to specific Firefox and/or Gecko releases, since the web runtime constitutes the virtual entirety of the software platform.

At the lowest levels, of course, Firefox OS uses the Android kernel and accompanying hardware adaptation layer, but releases rarely seem to note this fact. It would seem that few kernel improvements directly translate into user- or developer-visible features, although some improvements certainly make their way up the stack (improvements to video hardware support being the most obvious example).

Firefox OS 1.3 was based on the March 18 release of Firefox 28. The Firefox OS 2.0 release is based primarily on Firefox 31, with a number of changes incorporated from Firefox 32 as well. Some of the more relevant changes in these releases are support for CSS variables, support for timed text tracks (that is, subtitles) in <video> elements, and updates to the Vibration API and the MathML layout algorithm. In addition, of course, numerous small additions were made to the set of supported CSS and HTML features, along with security fixes (such as updating certificate authorities and certificates).

But there are also plenty of updates that are specific to Firefox OS itself. The release notes split the changes into "product features" and "platform features"—with the latter consisting of most of the API and HTML/CSS enhancements.

The product features do include some interesting additions, such as support for device-to-device sharing over NFC, the ability to cycle between running apps by swiping across the screen, and an integrated "Find My Device" feature. The device-to-device NFC support not only makes it possible to exchange files over NFC between two phones, but it can be used to read and write RFID tags as well. This makes Firefox OS useful as a tool for working with the inexpensive RFID-laden stickers and key fobs used in many do-it-yourself NFC projects.

Find My Device requires setting up a Firefox Account (which is the same account used to leave comments and ratings on apps in Mozilla's App Marketplace). Subsequently, if any device associated with one's account goes missing, an array of options are available to help locate it through the find.firefox.com site. If theft is the issue, the missing device can be remotely locked, its personal info wiped clean, or it can simply be located on a map. If it is merely hiding itself underneath the sofa, though, other options (like playing an alert sound) can be triggered as well.

Various other facets of Firefox OS have been improved in this new release as well. The default apps have been updated, with some useful enhancements—the camera app supports several auto-focus modes (including touch-to-focus, continuous, and face-tracking mode), local audio files can now be selected as ringtones, and so on. The home screen underwent a more significant revision; the 1.3-era home screen features a hard-to-grasp, task-oriented interface that prompts the user for a subject matter with the words "I'm thinking of..." followed by a smattering of possible answers: Social, Games, Music, and Showbiz. Whatever the phrase "I'm thinking of Social" might be interpreted to mean is now (thankfully) a moot point, since the new home screen provides, instead, a simple scrollable array of app launchers.

A development product

The user-facing updates to Firefox OS are welcome news, but the Flame is targeted primarily at OS and HTML-app developers. Several of the more interesting changes in the 2.0 preview are, thus, to be found under the hood. For example, hardware-accelerated playback of H.264 video is enabled by default. That will probably remain a controversial feature, but it is one that app developers will want to take advantage of. Several other changes should prove useful in conjunction with that feature, such as the addition of Real Time Streaming Protocol (RTSP) support. Several new interfaces in the WebRTC implementation have also been enabled, including the all-important getuserMedia() interface, which provides access to a device's video and audio capture hardware, and Data Channels, which enable direct, bidirectional data exchange between two WebRTC clients.

Given the cornucopia of HTML5-related JavaScript APIs currently under development, it probably comes as no surprise that Firefox OS 2.0 adds support for several new ones. The notable additions include the Network Information API, the fastSeek API, and the feature detection API. The Network Information API allows an app to query information about the device's network connection, such as its type (e.g., WiFi, Bluetooth, or cellular) and downlink speed, and to receive events with the attributes in question change.

FastSeek is an API used to jump to a particular time code in a multimedia file or stream, but to do so in a simplified manner—the results are not frame-accurate, but are much faster. In addition to seeking in situations where to-the-exact-frame accuracy is not required, the API enables the system to show preview frames while fast-forwarding and rewinding, when only a general accuracy is needed.

The feature-detection API allows an app or site to query various physical attributes of the actual device. At the moment, the API is a privileged one (since there are potential security risks) and only the Marketplace app has access to the necessary privilege. The goal is for the Marketplace app to relay whether a device has, for example, a camera or a keyboard, so that the Marketplace back-end server can only display apps for which the device has the necessary features.

Some of the other changes of note include the ability for privileged apps to mount and unmount storage, and the ability for an app to authenticate the device with a remote server using the SIM card as the authentication token. This could be useful to, for example, apps that need to be limited to a particular cellular provider.

The 2.0 preview also includes a suite of built-in functions designed to enable app development. Most will be familiar to Android developers: developer-mode settings for debugging and so forth. But one of the most interesting is the Developer HUD (for "heads up display"), which lets the user turn on overlays showing live performance numbers, various warnings and errors, and a memory usage meter.

Fanning the flames

As a phone, Firefox OS 2.0 on the Flame does an admirable job. App speed and responsiveness is fine—although the user interface seems to take pride in avoiding things like animations and fade-out transitions that one sees everywhere in Android. On the other hand, it is fun to see how tiny (often only a few kilobytes) the average Firefox OS app is. Perhaps both of these features are merely side-effects of Mozilla's emphasis on developing an OS for mid-range, rather than high-end, hardware, but it is hard to complain about either one.

There are few if any hiccups to be found that are more than nitpicks. For example, the screen brightness can be set to auto-adjust to ambient light conditions. In my experience, the auto-adjustments happen a little too frequently to be comfortable: walking down the street, the screen adjusts itself about once every second, in response to all passing shadows and changes in orientation. Is that deal-breaker? No. But it is a "polish" issue, one of those sometimes hard-to-define details that often go into whether or not reviewers conclude that a device "feels like a phone." Similarly, the various icons and user interfaces (even for the built-in apps), while generally pleasant to look at, vary considerably in style (compare the Firefox and Marketplace icons, for instance, to those of Music and Video).

As the updated home screen demonstrates, though, Mozilla is happy to respond to consumer feedback and make adjustments, so most of these issues should not be taken as major problems. In practice, Firefox OS 2.0 should be a stable update worth installing once it is deployed to non-developer devices. Whether it fully makes use of all the new APIs and features available, though, depends on those developers.

In fact, the big obstacle to using Firefox OS as a daily-use device is the quantity of available apps—a factor that Mozilla does not directly have an impact on. There are apps for most general-purpose categories, but in many cases there are only two or three options, and they are often light on features. There are a few apps from well-known commercial services (Google, Twitter, Facebook, etc.), though hardly as many as one will find on the largest mobile OSes. But anyone who has sampled a new platform has encountered a similar situation; it is rarely easy to predict at the outset how large or how quickly a third-party app-development community will grow.

That said, two things about the Firefox OS community do stand out already. The first is how many of the third-party apps are advertised (in the App Marketplace) and reviewed in languages other than English. Programming can be a remarkably English-centric world, as can free software itself, so this can come as something of a surprise to those of us accustomed to English-driven platforms. But Firefox OS's non-English acceptance—especially among developers—is a sign that the platform is gathering adherents in those markets where the consumer devices are being sold. That is a plus for those markets and, by extension, for everyone else as well.

The second interesting facet of Firefox OS 2.0 worth paying attention to is that there are developers outside Mozilla making contributions to the codebase and to the core apps. The 2.0 release announcement claimed that 157 of the 400 developers with patches accepted for 2.0 were new contributors. To look at a different metric, the new home screen in Firefox OS is a replaceable app, and there are several alternative home screens currently in development, such as Matchscreen and riverscreen. It is still early days, of course, but there is reason to be hopeful that this is a free-software mobile OS that is here to stay.

Comments (32 posted)

No Weekly Edition next week

November 27 is the Thanksgiving holiday in the United States. LWN does not traditionally take that week off, but, this time around, we find ourselves more in need of a break than usual. So we are going to enjoy the holiday with our families and not publish an edition on Thanksgiving day. We will be producing some feature content next week, though, so the site will not be entirely devoid of new stuff to read.

This holiday is the traditional opportunity to be thankful for one's blessings. Here at LWN, we are incredibly thankful for the incredible base of readers that we have. We wish for a great holiday for all of you, whether you celebrate this one in particular or not. We'll be back, hopefully rested, for the December 4 edition.

Comments (9 posted)