Last Friday (11 May 2018) we learned that a snap was mining cryptocurrency in the background while the application was running. The practical implication of that is the overuse of local resources on a user’s system, well beyond what a typical application would use, consuming more energy than would be expected. The net effect is an exchange of a small amount of non-personal information and compute resource which equates to revenue for the publisher in question, proportional to the resources used.

The snaps released by that publisher have since been unpublished and will be re-published with proper content by a trusted party but this raises some interesting questions worth discussing.

Evil, naive or interesting?

The first question worth asking, in this case, is whether the publisher was in fact doing anything wrong, considering that mining cryptocurrency is not illegal or unethical by itself.

That perspective was indeed taken by the publisher in question here, who informed us that the goal was to monetise software published under licenses that allow it, unaware of the social or technical consequences. The publisher offered to stop doing that once contacted.

Of course, it is misleading if there is no indication of the secondary purpose of the application.  That’s in fact why the application was taken down in the store. There are no rules against mining cryptocurrencies, but misleading users is a problem.

Software reviews

One of the most challenging aspects of running a modern software repository is just making sure that the published software is indeed only doing what it’s supposed to. In the classic Ubuntu repositories, we have the great privilege to work only with software built on trusted infrastructure, from source. That has obvious advantages but also requires a very long time for new bits to show up for millions of users. Snaps enable a much more direct path for publishers to deliver their software to users across a wide range of Linux distributions, ensuring that those apps are securely confined.

App Stores for iOS, Android and Windows follow some standard patterns for quality and security control – automated checkpoints that packages must go through before they are accepted, and manual reviews by a human when specific issues are flagged. The Snap Store implements both of these patterns.

Even then, the inherent complexity of software means it’s impossible for a large scale repository to only accept software after every individual file has been reviewed in detail. That’s true whether source code is available or not as no institution can afford to review hundreds of thousands of incoming source code lines every single day. Because of that, the most successful trust model is based on the origin of the software, not its content. In other words, trust the publisher rather than the application itself.

It’s also particularly useful to be able to say more accurately what we are trusting the software with. It’s better to say “we trust Pauline’s software to access the camera” than to have a binary view of trust. The technology implemented in snap packages is a major step in the right direction as it allows that trust to be defined with very high levels of granularity, using modern Linux kernel security capabilities. It allows answering questions such as whether the snap wants access to a web camera, or has the ability to access files in the home directory, for example, and also allows having an opinion about it, for instance revoking that access, and many other sensible variants of that. But even then, the concept of trust is still present and important.

Imagine, for example, that someone installs a web browser published by an unknown party. Even if the only thing that this web browser has access to is its own storage space, the display, and the network, it remains that all of the data flowing through that browser is at stake. There’s no way around trusting the publisher to be honest and careful before using it.

The road to safety

Several years ago when we started the work on snap packages, we understood that we could not instantly implement an alternative that was completely safe from all perspectives. In addition to being safe, it had to be useful. So the challenge we gave ourselves was to significantly improve the situation immediately, and then pave the road for incremental improvements that could be rolled out gradually.

Our roadmap continues to reflect these choices: we have very interesting security features in the works that will improve the safety of the system and also the experience of people handling software deployments in servers and desktops.

As just one example that is relevant in the context of this event, a simple but fairly effective feature that we are working on is the ability to flag specific publishers as verified. The details of that will be announced soon, but the basic idea is that it’ll be easier for users to identify that the person or organization publishing the snap are who they claim to be. The need for trust still remains but it will help users inform their decision further before installing.

Other features are more gradual and less visible, such as the regular encoding of new interfaces that allow mediating other aspects of the system, or the upstreaming of all the AppArmor kernel patches, allowing more Linux distributions to benefit from additional confinement capabilities.

Concluding

The event identified over the weekend was unfortunate but also expected in the sense that any popular software store will need to handle and mitigate abuse. We take these events seriously and will continue to both watch the store closely and to improve the security of the platform as a whole.

We run this project as an open and friendly community, so if you are interested in these problems and want to help defining the future of software distribution on Linux, please join us in our discussions at snapcraft.io.