Mozilla has announced that it will close down its Persona.org identity service in November 2016. The browser maker stopped developing the Persona software in 2014, citing low adoption, but has maintained Persona.org as a public service. With the announcement that the service will be discontinued, the question arose as to whether or not the software could survive as an independent, community-driven project. Questions also arose as to why Persona failed to take off, and whether Mozilla should have managed the project differently.

Persona is a sign-in system for web sites in which the responsibility for authenticating a user login attempt is handed to an email provider. In theory, the user enters only their email address (e.g., user@example.com) on the web site; that site then performs a handshake with a process running on the domain portion of the email address (example.com). The user proves to the mail server that the address is theirs by logging into their email account, at which point the email server returns a token to the web site that concludes the authentication process.

The scheme offers potential benefits to a number of parties. The site owner does not have to implement a login system from scratch and is able get by with storing only the user's email address (which, in addition to being simple, prevents lock-in). The user can re-use their email address on any number of sites without having to create new accounts (and passwords) for every site. The whole process could be decentralized; users and site maintainers could therefore stop handing authentication over to the big proprietary social-media networks.

But theory rarely lives up to reality, and Mozilla found it difficult to persuade email providers to run the mail-server side of the authentication service. The Persona.org site was created as a stop-gap; if a user's email provider did not natively support the Persona authentication scheme, the user could verify that they had access to the email address through Persona.org. The Persona.org authentication flow, though, was not part of the Persona scheme itself. Instead, the Persona.org server worked by sending an email containing a challenge to the user's address. Clicking on the link inside the email verified that the user had access, at which point Persona.org completed the login transaction with the originating web site.

Disconnect

Sadly, because Mozilla never succeeded in convincing major email services to implement their own Persona authentication service, Persona itself became a scheme that relied almost entirely on the Persona.org site—which undercut the goal of making Persona a decentralized protocol. As a result, Persona.org was just one of many third-party authentication options—and a much smaller one than Facebook, Google, Twitter, and the like.

By March 2014, Mozilla decided that the writing was on the wall: without email-provider support, there was not sufficient interest in adding Persona support among web-site proprietors either. That made Persona unlikely to make a meaningful dent in the login-service space dominated by the social-media companies. So Mozilla stopped working on the code (or, as the official announcement put it, "transitioned Persona to community ownership") and moved the Persona developers over to work on a revamped Firefox Sync. But Persona.org remained active even after development wound down.

The Persona.org shutdown announcement was sent out on January 12 by Mozilla's Ryan Kelly. According to Kelly, the Persona.org site will finally be decommissioned on November 30, 2016. Afterward, Mozilla will destroy all user data stored on the servers, and will retain the persona.org domain name indefinitely, but with no services running on it (presumably to prevent a malicious third party from taking control of the domain and hijacking any lingering Persona transactions). Between now and then, Mozilla will continue to apply security updates to the Persona.org servers and will keep the mailing-list and IRC support channels functioning as normal.

The announcement says that the decision to shutter the service was due to "low, declining usage," but Mozilla has still published a transition guide to help the remaining users migrate their sites to a new authentication provider before the shutdown occurs.

The suggested replacement systems include the rather obvious options of using another identity provider (like Google or Facebook) or self-hosting an authentication system. But the suggestions also point out that there are other authentication systems that, like Persona, rely solely on the user's email address to establish their identity. For example, there is Passwordless, a Node.js middleware that emails per-session login tokens to the user's address—much like the authentication flow of the Persona.org site.

The adoption problem

No doubt Persona has far fewer adopters than the Facebook or Google authentication systems, but some in the development community contend that Mozilla failed to give Persona enough time to grow a user base. In December 2015, Stavros Korokithakis criticized the short amount of time that the Persona team was given to develop and deploy the system—a little under two years:

No one can be expected to revolutionize authentication in two years! What one can do in two years is try to discover whether it’s possible to create fully private, decentralized authentication. Not only did the Persona team demonstrate that such a thing is possible, they brought a mature product implementing the protocol to market! I doubt Google would have done any better.

Along the way, he quotes Persona developer Dan Callahan, who reported that the team was taken by surprise by requests to show adoption numbers:

We thought we had more time to experiment with the core protocol and product design, but with Mozilla Labs' somewhat sudden dissolution, we were unexpectedly asked to demonstrate traction and commercial adoption that simply wasn't there.

The need to give a new protocol adequate time to gain acceptance was a theme raised in the Hacker News (HN) discussion thread about the November-shutdown news. Jan Wrobel noted that:

Core open protocols behind the Internet that we have today took years of development and refinements. It seems that in the current model, where projects are expected to be widely adopted within a short period of time, the development of such protocols is hindered.

Others lamented the fact that Mozilla did not make a concerted push to have Persona established as a formal specification or the fact that the client side of Persona in Firefox was implemented in a JavaScript shim rather than natively in the browser. For many, however, the situation was similar to the one seen with OpenID: large web service providers have a vested interest in running their own centralized identity solutions, and without a large userbase to rival Google or Facebook's, any authentication scheme promoted by a small non-profit organization stands little chance of success.

Persons of interest

Mozilla's shutdown does not necessarily spell the end for the underlying Persona concept, of course. When news of the shutdown broke, Korokithakis was among those in the HN thread who advocated taking the Persona code and developing it further. The interested parties eventually pooled their resources and formed a GitHub group named Let's Auth. The group has put together a roadmap, which notes a desire to not have a single point of failure akin to Persona.org as well as the importance of implementing native browser support. The roadmap also highlights the importance of getting an existing web-framework project (such as WordPress or Rails) on board.

The plan seems to be a move away from directly picking up where Persona development left off and, instead, stripping the idea down to basics and reimplementing what is necessary. It may be a wise choice; Callahan weighed in on the revival effort, saying that "I'd strongly suggest learning from Persona's design rather than directly re-hosting the code."

In its own post-mortem analysis, Mozilla noted many of the same issues raised in the HN thread and by the Let's Auth project. It also pointed out that Persona suffered feature creep, implementing session-management and attribute-exchange features that distracted from the the core authentication function. If the attempt to reboot Persona outside of Mozilla takes those lessons to heart, perhaps there is still a future for the project's decentralized authentication concept.

Good intentions and lessons learned do not guarantee that a revival effort will succeed, but it is nice to see interest in evolving the concept of Persona further. As several people have pointed out, one lingering gift that Persona gave to web developers was a simple exit strategy. All of the site maintainers abandoned by the Persona.org shutdown will still have their users' email addresses, so they can easily move to a new authentication solution. Such would not be the case had they chosen instead to delegate authentication to a proprietary web-service provider.

Comments (11 posted)

The past few years have seen a flurry of development effort directed at building secure and anonymizing apps for smartphones; one can run Tor on an Android device and has a choice of multiple encrypted messaging solutions. But, until recently, there has been comparatively little work in making mobile devices react in emergency situations—to, say, lock down or wipe the device's storage clean of sensitive information or to sound an alarm that something untoward has happened to the user. Now the Guardian Project has proposed an open-source framework to make "panic button" features available in every Android app.

The Guardian Project is a non-commercial developer of mobile apps with an emphasis on security and privacy. It is perhaps best known for the Android Tor client Orbot and the encrypted messaging app ChatSecure. Those offerings are fairly straightforward fare for anyone wishing to keep their communications private, but some of the project's other work has offered additional features.

In 2012, it developed InTheClear, an Android app that would securely wipe the device's storage when it was activated. The Courier news-reader incorporates a similar emergency-erase feature. So too does the still-in-development CameraV app, which also has a built-in ability to disguise the app's launcher icon. Similar ideas are found elsewhere, such as in the Panic Button app developed by Amnesty International with the goal of providing human rights activists with a "panic button" to clear out their phones in the event that they were arrested or otherwise placed in harm's way.

Now the Guardian Project has developed an Android library that will allow any app to respond to "panic" situations—by locking the app, erasing its data, hiding the launcher icon, or any other appropriate action. Called PanicKit, the system works by having each compatible app accept an ACTION_TRIGGER Intent from a separate "panic button" app. Thus, the user can activate a single panic button and have every configured app respond automatically.

How an app responds to the panic trigger can vary, and could be non-destructive or destructive (or perhaps provide the user with several options). The Guardian Project's blog post recommends that non-destructive responses (such as erasing caches or locking apps) be the default, though it notes that more serious measures may be what the user wants:

Deleting data is exactly what is needed in a panic situation, but the user must opt-in to enable this kind of response in order to prevent data from being mistakenly deleted. Sending a message can also be a very valuable panic response. But sending a message to the wrong person can cause harm, sending it at the wrong time can destroy people’s expectations: if you cry wolf too often, then people will stop hearing it. Disguising an app can also save people a lot of trouble. But if the user does not know this is going to happen, their experience will be that the app was deleted.

The scheme thus enables any interested developer to add "panic button" support to an app, and it allows the user to choose from potentially a multitude of possible "panic button" apps. The Guardian Project has released one such app, Ripple, and PanicKit support has been added to Amnesty International's Panic Button app. In addition, the Guardian Project has released a non-functional demonstration app called FakePanicButton.

Both take essentially the same UI/UX approach: the user can trigger a panic signal by opening the app and tapping an on-screen button. But, as the blog post notes, there are other possible ways one could trigger a panic signal—a "geo-fence" trigger that sends the panic signal if the phone enters a dangerous area, detecting the proximity of a designated Bluetooth or NFC "button," or even a "dead man's switch" that issues the panic signal if the user does not check in regularly.

PanicKit response support is available now in Orweb, InTheClear, Courier, and several other Guardian project apps. In addition, several third-party apps have added PanicKit support or are in the process of doing so, such as the chat client Zom and the Lightning web browser. The responses implemented in these apps vary, from erasing browser history or deleting data to sending pre-defined messages to specific, trusted contacts.

The blog post points out in several places that "panic button" situations are, naturally, times when the user is under considerable stress. Consequently, the project is taking care to work out design patterns and best practices to help avoid mishaps. The Ripple app, for example, takes two steps to send out a panic signal, and provides a five-second window during which the user can easily cancel the operation.

If PanicKit becomes a popular feature, though, there is also the risk that it could become too complex for its own good. Right now, for instance, one can install both Ripple and Panic Button. Since each app on the device must register to accept an Intent, the user can configure some apps to respond to Ripple and others to respond to Panic Button. Throw in geo-fence triggers and dead man's switches, then multiply by configurable options for each panic-response app, and there quickly becomes a lot for the user to configure.

Consequently, the Guardian Project has formed the Panic Initiative as a collaboration space where interested developers can address open questions about system integration, usability, and the like. The PanicKit wiki documents the project's design work and implementation progress so far.

Perhaps most Android users will never have any occasion to need a panic button, and no doubt it is a feature no one looks forward to using. But if it proves popular, PanicKit could ease the minds of users simply by making responding to panic situations an issue that they can think about once in advance, rather than it the heat of the moment.

Comments (5 posted)

The idea of sandboxing applications has a certain appeal. By restricting a program's access to various features and parts of the system that it shouldn't need, any harm that can come from a compromise can be reduced—often, substantially so. But putting together the required pieces for a given application is a tedious task, which is part of why projects like Firejail have been started. Firejail uses namespaces, seccomp BPF, Linux capabilities, and other kernel features to apply restrictions to arbitrary programs, but it also has profiles targeting popular applications.

One of the goals of the project is to make using sandboxes easy or, as the Documentation page puts it: "There is no difficult in Firejail, at least not SELinux-difficult." To that end, running Firefox in a sandbox is done with a simple command:

$ firejail firefox

That command will launch Firefox inside of a sandbox with a whole list of pre-configured restrictions . One can also modify the profile or create a new one with different restrictions.

The firejail command is a setuid-root program that sets up namespaces, seccomp filters, and capabilities before executing the desired program. It is a C program that is available under the GPLv2; it also comes with profiles for more than 30 different applications. There is a Qt-based GUI, called Firetools, available as well.

Simply invoking firejail will start a shell using the generic profile. That profile will remove all capabilities, create a user namespace with only one user (the current user, thus typically no mapping to the root user outside the namespace), disallow any network protocols other than Unix sockets, IPv4, and IPv6 using seccomp, blacklist access to certain files (by mounting empty root-owned files or directories on them), and so on. Profiles can also use the include directive to reference other profiles. So there are some commonly used profiles that are included by the generic profile to restrict access to a large number of home directory files and directories (e.g. .bashrc , .emacs , .ssh ), system files (e.g. /etc/shadow ), and management utilities (e.g. mount , su ). While those lists cannot be exhaustive (especially for various application-specific configuration directories in the home directory), users can add their own entries to the blacklist.

In addition, as described on the Basic Usage page, Firejail can be started with the --private option to replace the user's home directory with an empty one. It does that by mounting a tmpfs atop the home directory; the tmpfs will be destroyed when Firejail exits. Alternatively, users can specify a persistent directory ( --private=~/my_sandbox_dir ) to store sandbox data.

The default behavior for Firejail (when invoked without the generic profile using the --noprofile option) is to create new mount, PID, and UTS namespaces, but it can also be invoked (or configured) to use new network and user namespaces as well. If invoked with --net=eth0 option, for example, the network namespace will use the system's eth0 device with the macvlan driver to create a new network device inside the namespace that can communicate with the outside world. Bridging is also supported. The --net=none option will create a new network namespace without any devices, so processes cannot communicate outside of the namespace.

There is lots more to Firejail; the highlights of its feature set are outlined on the Features page. There is also plenty of documentation, ranging from man pages for firejail and firejail-profile (which describes the configuration options for profiles) to information on building custom profiles and filtering system calls using Firejail and seccomp. It is, in short, a rather comprehensive framework for applying a sandbox to applications.

But it is not only restricted to GUI applications like web browsers, email readers, BitTorrent clients, media players, and the like. It also supports running server processes in sandboxes. This is where capabilities are likely to come more into play. As described on the Linux Capabilities Guide page, programs like web servers and other network services can be restricted to just a handful of capabilities that are needed to do their job (e.g. CAP_NET_BIND_SERVICE , CAP_SETUID ). That will reduce what a compromise of those processes can accomplish (though Linux capabilities are known to have weaknesses).

Over time, the number of profiles available should grow and additions will likely be made to the existing generic profile and the other commonly included profiles. Obviously, getting those profiles "right" is an important piece of the puzzle. For the most part, it is a blacklist approach (though support for using whitelists of files is present), which may allow some important things to be unprotected. That said, it is clearly far better than simply running these applications with all of the access and privileges of the user. Root-level compromises are certainly terrible, but for most regular users, their crown jewels live in their home directory anyway, so a full compromise is not substantially worse.

The idea of Firejail came from the sandbox that Google uses for the rendering processes in its Chrome browser, but it goes much further than that. It uses many of the security and isolation technologies that have been added to the kernel over the last decade or so—including control groups for resource limiting the sandboxes. We have covered many of those technologies over that time, so it is nice to see them being used in ways that can help users protect themselves from attacks of various kinds. The next time you want to run an unknown new program or visit a dodgy web site, Firejail might be a good option to reduce the harm that might otherwise occur.

[ Thanks to Raphaël Rigo for giving us a heads up about Firejail. ]

Comments (11 posted)