LWN.net Weekly Edition for December 24, 2015

The grumpy editor's 2015 retrospective

Welcome to the final LWN.net weekly edition for 2015. As is always the case, it has been a busy year for the free-software community. It has also been a busy year for LWN; among other things, we posted 476 feature articles (57 from outside authors) and reported from no less than 31 conferences. Most readers noticed — and many complained about — the site's new look; that work remains unfinished as we still intend to address some of the issues that have been raised. Happily, few of you noticed the retirement of our eight-year-old production server for something newer, faster, and cloudier. All told, it has been a successful year but we're ready for a brief rest.

First, though, there is an important ritual to work through: the review and mocking of your editor's predictions from last January. As usual, some of them came off better than others.

Yes, we heard a lot about the Internet of things, as expected, including many of the unpleasant behaviors that connected things might be expected to show. The (fortunately) short-lived decision by Philips to refuse to interoperate with competing "smart" light bulbs is a case in point; the ongoing revelations of emissions-test cheating in Volkswagen automobiles is a rather more sobering one. The prediction didn't talk about antifeatures, though; instead it focused on size and resource usage. The size constraints that come with connected devices did show themselves and had an influence on kernel development, but we have not, yet, seen the emergence of a credible competitor for Linux on extremely small systems.

Did the OpenStack hype fade as predicted? Hard to say; one still hears a lot about it. Cloud computing as a whole is clearly still on the rise, with many projects and companies trying to own pieces of it.

Your editor declares full accuracy for his prediction that the systemd wars would wind down. For the most part, that particular fight is done and most people are getting on with their lives. Projects like Devuan continue to host mailing lists that serve as hotbeds of snide commentary on systemd and the parentage of its creators, but they have failed, so far, to produce an interesting systemd-free alternative. Meanwhile, the prediction that there would continue to be disagreements about the design of the Linux system in general was so obvious that it better have come true.

Your editor predicted more Heartbleed-level security incidents. In truth, the year may not have been as bad as 2014 with regard to high-profile vulnerabilities, but, even so, names like GHOST, Moose, Logjam, and Stagefright became familiar over the course of the year. The flow of vulnerabilities continues and seems unlikely to slow anytime soon. The related prediction of a slow growth in investment in security seems to have been borne out; we are starting to see efforts like the Core Infrastructure Initiative funding work on some of our higher-profile problems, and some companies are beginning to contribute developers to the task of making our code more secure. But it is just a beginning and, according to some viewpoints anyway, a thoroughly inadequate one.

One might be forgiven for saying that, contrary to prediction, not much happened on the year-2038 front. But, behind the scenes, quite a bit of work is happening (1, 2) to fix year-2038-related problems in various parts of the system and define how the user-space transition is going to work. The other long-horizon projects mentioned did indeed gain some traction; Btrfs is coming into wider use, some distributions are starting to seriously consider a Wayland transition, etc. Some of these projects can take a long time to reach fruition, but they get there eventually.

Your editor predicted that we would see more distributions that are specialized for specific applications. The existing distributions of this type (think of OpenWrt, the network-attached storage distributions, and even distributions like Android or Ubuntu Touch) mostly seem to be going strong, but they do not have a lot of new competition.

Finally, as predicted, civility remains an issue in our community. There has even been some vocal disagreement over the standards of discussion here at LWN. On the wider stage, Linus Torvalds duly produced one of his famous tantrums, reinforcing the kernel community's exaggerated reputation for unfriendliness. On the other side, there has been some pushback from certain quarters against those campaigning for greater civility and inclusiveness in our community. We are far from a consensus on what standards should apply to our interactions with each other.

Then, there are the things your editor should have predicted, but didn't. It's harder to come up with a definitive list of those, of course, but a few things stand out.

2014 saw a new class of security vulnerability; they now come with catchy names, logos, and "security companies" in their trail trying to make money from them. In such an environment, it is natural that we will see a series of overhyped vulnerabilities pushed by people who want to own the next Shellshock. The GHOST vulnerability is an example, as are the headlines circulating as this article is written saying that "any Linux system can be compromised by hitting the backspace key." There are some severe vulnerabilities out there, but people calling a problem severe do not necessarily make it so.

Your editor didn't predict that kdbus would be merged — an outcome that seemed fairly clear given the developers who were behind it. It's just as well, since such a prediction would have been wrong. The decision to back off and rethink the design was a bit of a surprise to some, but it seems like the right one. There should be place for a proper messaging system in the kernel, but it needs to be the right one.

Another unpredicted event was the filing of the VMware GPL-infringement suit. That particular one might have been hard to foresee but, given the increasing level of frustration over GPL violations, it was inevitable that something would be filed one of these years.

A few years back, your editor predicted that the OpenOffice project, newly shifted over to the Apache Software Foundation, would fade away. That was accounted as an incorrect prediction at the end of the year, but it now seems that the real failure was just in the timing. In 2015 it became clear that OpenOffice has nearly lost the ability to move forward, or to even put out releases fixing security issues. The project did finally get a small release out late in the year; it's not at all clear when the next one might happen.

The decision to rebase the openSUSE distribution onto a SUSE Linux Enterprise came as a surprise to your editor. One can argue that something like that should have been evident, given the resources required to keep openSUSE going. But, in the end, openSUSE Leap is an interesting new idea for how a community-oriented distribution can evolve in symbiosis with a supported "enterprise" distribution.

The end of the Ada Initiative was also unforeseen though, again, one might argue that the signs had been there for a while. It seems that there should still be a place in our community for a group trying to increase inclusivity and the diversity of our developer base, but evidently it needs to be a different group.

To close: 2015 was, for the Linux and free software community, a fairly normal year. We have had our ups and downs, but, as a whole, progress toward world domination appears to be mostly on track. Here at LWN, we are proud to have been a small part of it. As we head into the year-end festivities, we wish the best for all of our readers. Thank you for supporting us through our 18th (!) year of operation.

Comments (13 posted)

Warsow 2.0: An arena-style first-person shooter game

Running around with lots of guns in cramped quarters has served as a sufficient backdrop for many video games. That's also the premise of "Warsow", an almost entirely open-source first-person shooter (FPS). Where Warsow differs from its competitors is its focus on constant mobility and jumping, leading to a frenetic game where fast reflexes and sharp instincts prevail. Warsow's recent 2.0 release, which comes with a number of improvements, including a tutorial, major graphical enhancements, and changes to weapon power for game balance purposes, makes for a good time to look at how the game has progressed to date.

Warsow's origins lie in "Chasseur de bots" (Hunter of bots), a story (written in French) about the battles of a video game player in a chaotic FPS. The original Chasseur de bots website is no longer available, and only an excerpt from the original story can be found online. Fabrice Demurger, who wrote the Chasseur story, began working on Warsow with the help of a few fellow developers in 2004, lifting the cyberpunk setting and frantic action from the story. Playable characters include punks with dyed hair and pigmen (humanoids with pig heads). Many of the game maps are futuristic, imagining a high-tech industrial world. That technology is embodied in the game's weapons, which include fanciful concepts like laser guns as well as creative takes on familiar armaments like shotguns and grenade launchers.

A public 0.1 alpha was released in 2006. In the years to come, Demurger's activity within the project waned, but some of the early developers have stayed on. The project achieved some remarkable successes, including recognition among major online video game leagues as a competitive electronic sport and reviews on television shows. It continues to have a small but dedicated base of players; its timeless gameplay (shoot people before they shoot you) hasn't dulled with age.

Those looking for a single-player story-driven campaign akin to the Half-Life series of FPSes will need to search elsewhere. Warsow is entirely about fast-paced arena fighting, largely in one-on-one duels or in team deathmatches. Players familiar with the famous, multiplayer-oriented Quake series will be right at home.

Success in Warsow doesn't boil down solely to one's aim, but also to how one moves. There are multiple jumping tricks a player needs to take advantage of to win. Some boost speed (such as through strafe-jumping, which is jumping while running sideways), while others allow quick repositioning in a fight (such as via wall-jumping). This need to constantly be mobile can be rather daunting to new players. Fortunately, the 2.0 version comes with an optional tutorial that teaches how best to hop around these arenas.

After downloading the game and running it, the player is prompted to register an account on warsow.gg. This is needed to save statistics (such as accuracy with weapons) and match results. While this is a nice feature, clicking on the prompt takes the player out of the game and into a web browser to fill in account details. Then they have to open their email to click on a confirmation link. It would be a smoother initial experience if a player could register for an account without having to leave the game environment at all.

The small number of players online at any given time harms the overall experience of what is otherwise an impressive, polished game. Most of the time, there's only a handful of active servers to join, some of them with less-than-forgiving latency (I encountered one with 140+ millisecond ping, which some hardcore players would consider to be unacceptable). There is also no guarantee that the players will stay for another round after one is finished, leaving the player searching for another server. The small population hurts the dueling modes the most, where players go head-to-head, one-versus-one. Joining one such server, I spent eight minutes spectating the match being played to wait for the next round. Then everyone left and I had no one to play with.

Waiting is only one pain point of a small server. An unavoidable problem when the number of players is small is imbalanced matchmaking, where experienced players find themselves matched against people new to the game. After I joined another server and waited another seven minutes (leaving me with an effective overall queue of 15 minutes), I got matched against someone who mopped the floor with me. Right after that, I completely stomped my next opponent. Both of these matches occurred on the same ranked server; successes and/or failures on such servers are added to the statistics on one's public-facing profile (see an example here) that detail how accomplished one is.

Nonetheless, the game is still lots of fun. It's intense: there are nine weapons to choose from, including a short-range Riotgun (i.e. shotgun), a medium-range Plasmagun for spreading fire over an area, and the overall reliable long-range Rocket Launcher (which can also boost one's jumps if correctly timed). In some modes, all of the weapons are available when one spawns (i.e. begins the game or is resurrected following death). In others, one begins with a weak Gunblade (which serves the purpose of both pistol and knife in one device) and must collect ammunition and weapons around the map. These weapons can be instantly switched at the press of a button. Success in combat against opponents of similar skill is gratifying; one gets a sense of accomplishment from hopping around nimbly to dodge enemy fire and instinctively swapping to the right weapon at the right time to secure a kill.

Until the 2.0 version, Warsow had an awkward licensing regime. While the game engine's codebase was (and is) available under GPLv2-or-later, a proprietary "Warsow Content License", effectively allowing only redistribution, applied to all the media assets. Furthermore, outside contributors had to accept a poorly-written "Contribution License Agreement". It specified that any submitted "game rules" (not adequately defined in the license) became the property of "Chasseur de bots" (a now-defunct association that held the assets). The copyright to any contributed media assets were also assigned, but the contributor retained the right to "display the work as part of a personal portfolio". Recently, the active development team contacted the old Chasseur de bots members as well as most of the past contributors (some were unable to be reached) to ask for a relicense. With their agreement, all the art assets, with the exception of some sound effects (mostly that of weapons firing and the grunts of the player's character) and some map textures, are now available under the copyleft Creative Commons Attribution-ShareAlike 4.0 International License. The development team is looking to replace any assets that are not licensed CC BY-SA to make the game fully open-source.

2.0 comes with much more than a licensing update. There have been major gameplay balance changes, including an increase in damage to a number of weapons as well as adding more consistency in recoil and "splash radius" (i.e. the area-of-effect in which a launched grenade or rocket will cause damage). Linux versions now use Simple DirectMedia Layer 2 for video. HTTPS has been mandated for matchmaking, which is a welcome change for security-conscious players. 2.0 also takes better advantage of multi-threading to address a number of previous issues, including latency in gameplay, some unpleasant race conditions, and slow load times. The renderer is much better, boasting a "30% to 50% overall performance improvement". Changes to the graphics, including weapon effects, bullet models, and textures for playable characters, make the game feel more modern. The game is also available in nine additional languages. The full list of changes can be found here.

There is lots of room for new contributors looking to help out. Both the client and the server (which share the same repository) are freely-licensed and written in C, C++, and AngelScript, which is a popular object-oriented scripting language for video game development. The Warsow developers provide an SDK [.tar.gz], which comes with the full source code of the game, documentation, and tools (including build scripts). The "sourcecode_quickstart" file sums up the fundamentals of the source code's structure, with a helpful opening section:

The developer team has stated that level designers, computer programmers (particularly those with a good grasp for game engines), 3D artists, translators, and a community manager would be great additions. Some of the goals going forward for Warsow 3.0 are a release of a version for the Steam video game marketplace as well as updating the game's visuals. There is no mailing list but discussions on the official forums are fairly active. One can also contribute by submitting pull requests at the project's GitHub repositories. It's unclear when 3.0 will arrive, but given that the previous major release arrived a year and a half ago, a mid-year 2017 release seems like a reasonable guess.

For those interested in playing, or contributing to, a modern first-person shooter, Warsow might just be the right choice.

Comments (3 posted)

Panopticlick 2

The Electronic Frontier Foundation (EFF) has rolled out a major update to its online browser-fingerprinting tool Panopticlick. The tool's site lets visitors perform a scan to assess how uniquely identifiable their web browser is among all web traffic—although, in the past, the EFF has also used the same code to research the fingerprinting of web browsers en masse. The new update, dubbed Panopticlick 2.0, adds new tests to gauge a browser's ad-blocking, tracker-blocking, and "Do Not Track" performance, and it has been designed to function better on mobile web browsers.

Uniqueness again

The first version of Panopticlick was unveiled in 2010. At that time, the EFF reported that approximately 84% of individual users' browsers could be uniquely identified without any use of login credentials, cookies, or other stateful mechanisms. Rather, Panopticlick assembled a "fingerprint" of each browser using only passive configuration information: the details revealed in the User-Agent string, the list of plugins and fonts installed, various localization settings, window and session properties accessible through CSS queries, and so forth.

Panopticlick's 2015 update adds some new fingerprinting tests, such as the HTML <canvas> fingerprinting technique first publicized in 2014 and a check for touchscreen support. In the HTML <canvas> test (and its WebGL cousin), the Panopticlick code renders a hidden image (using the HTML or WebGL <canvas> element), then hashes the result. The variations in the display, graphics stack, and text-rendering settings of the client machine combine to make each such image slightly different. The touch-support test captures whether touch events are supported, plus whether the onTouchStart JavaScript event is supported and the number of touch points reported by the hardware.

When combined, all of the fingerprinting tests amount to a profile of the user's browser. The Panopticlick test site lets users see how many of the other browsers that have visited the site reported the same information on each test, plus how many "bits" of uniqueness accumulate from each test. The later number is the binary logarithm of the former, so interpreting it meaningfully can take some thought. At the moment, there have been about 6.2 million visitors, so any test that gives a unique result is reported as equating to (rounded) 22.57 bits. As more site visitors run the test battery, those numbers will fluctuate.

For instance, my "Browser Plugin Details" list—which enumerates all of the codec- and version-compatibility information reported for each installed plugin—hit the maximum of 22.57 bits, even though all of my browser plugins come directly from my distribution repository. But I am inconsistent about updating them; if all were refreshed to the latest release, the uniqueness of the "Browser Plugin Details" would doubtless go down. In contrast, I work on font projects, so my list of installed fonts (which also hit the maximum of 22.57) includes fonts that I built locally. Thus, it is essentially guaranteed to be unique, a factor that is out of the browser developers' hands. On the other hand, the local font list can and does change from one day to the next, which limits its effectiveness in tracking the browser across sessions. Whether or not the browser ought to report either of these configurations to remote servers is an open question.

Privacy dipstick

The bigger change in Panopticlick 2.0 is the addition of tests that measure key privacy features of the user's browser. These tests do not factor into the unique browser-fingerprint computation at all, but they are clearly of value to users interested in privacy and anonymity. The tests employ HTTP requests that match the filters from first- and third-party ad-blocking and tracker-blocking tools. The EFF runs a set of test servers on domains to ensure that Panopticlick can test the full variety of ad and tracker options. One of these test domains is set up to advertise the EFF's privacy-friendly Do Not Track header policy, in order to test whether or not the browser un-blocks that domain in response to the policy.

The Panopticlick site notes that it takes steps to ensure that its phony tracker domains (e.g., eviltracker.net) are included in the blacklists used by popular URL-based blocking extensions like Disconnect, and that the phony trackers conform to patterns caught by the heuristic algorithm used by the EFF's own Privacy Badger extension. The results reported to the user are a brief table of "yes" and "no" results.

The fingerprinting score is likely to be of more interest to users well-versed in online privacy. Finally, the site provides a list of suggested countermeasures. Unfortunately, the list is rather brief—it amounts to "use Tor Browser, disable JavaScript, and don't use a 'rare' browser if you can avoid it." A more detailed examination of the issues—for example, look at how to disable JavaScript localStorage or set a nondescript User-Agent string—would be a worthwhile and welcome addition.

The future

If the 2010 release of the initial Panopticlick is any guide, the community should expect the EFF to conduct its own research into the state of browser fingerprinting and produce some hard numbers. A few months after the 2010 announcement of Panopticlick, EFF Senior Technologist Peter Eckersley published a paper [PDF] summarizing the data seen by Panopticlick and characterizing its privacy implications. Even if a new study is a long time in coming from the EFF, though, interested parties can take matters into their own hands. Unlike with the 2010 release, the Panopticlick source code is available on GitHub. It will be interesting to see what others do with the code.

Sadly, in the long run, Panopticlick may only be useful to end users as a canary in the coal mine—that is, to raise awareness that disabling ads and tracking beacons is not enough to guard against a party determined to identify and profile users online, and not as a weapon to find and disable privacy-leaking features in a browser. That is because most of the data points used to assemble a Panopticlick-style browser fingerprint cannot fully be suppressed. Every setting or preference that can be communicated between the client and a web server contributes incrementally to the formula.

One can always argue about where to draw the line, suggesting that too many new web APIs are being implemented, each of which increases the chance of a browser being fingerprinted. But the public wants functionality from its mobile and desktop browsers, and that trend is not likely to stop. Google's Chrome/Chromium team has evidently made up its mind that combating browser fingerprinting is a lost cause; the project's FAQ notes that "defeating such fingerprinting is likely not practical without fundamental changes to how the Web works." Roughly 33 bits are required to uniquely identify a browser from the global population, the FAQ states, and disabling APIs is not be enough to reduce each browser's fingerprint to below that threshold.

Interest in the topic appears to be somewhat higher at Mozilla; a tracking bug was filed after the 2010 Panopticlick release and a wiki page created to discuss reducing the "fingerprintability" of Firefox (although the information there is no longer up to date). More recently, issues have been raised to deal with specific information leaks, including the <canvas> attack, the WebSpeech API, the installed-font list, and the plugin list. A number of the proposed solutions come from the Tor Browser.

Certainly any egregious information leaks from the browser should be patched, but there is a lot less consensus on how much fingerprint resistance users have a right to expect from a browser running in its default mode. After all, when privacy and anonymity are paramount, the tools do exist for users to enable private browsing, disable JavaScript, or switch over to Tor. Perhaps that is enough, and it needs to be left up to the user to know in which situations access to the latest and greatest web features stops being important and privacy concerns take center stage.

For the time being, the updated Panopticlick can at least enable users to get a clearer picture of the uniqueness of their browser and the impact of various privacy settings on its fingerprint. And educating the user is ultimately the best course of action.

Comments (9 posted)