
Malware Found in the Ubuntu Snap Store - dafran
https://www.linuxuprising.com/2018/05/malware-found-in-ubuntu-snap-store.html
======
geofft
There is no review process or central restrictions on who can upload to the
Ubuntu Snap Store, so in a sense, this isn't surprising.
[https://docs.snapcraft.io/build-
snaps/publish](https://docs.snapcraft.io/build-snaps/publish)

Does the name "Ubuntu Snap Store" carry a connotation that code is reviewed
for malware by Ubuntu, the way that the Apple, Google, Amazon, etc. mobile app
stores are? Or does its presence in the software center app imply a
connotation that it's endorsed by the OS vendor?

I was at a PyCon BoF earlier today about security where I learned that many
developers - including experienced developers - believe that the presence of a
package on the PyPI or npm package registries is some sort of indicator of
quality/review, and they're surprised to learn that anyone can upload code to
PyPI/npm. One reason they believe this is that they're hosted by the same
organizations that provide the installer tools, so it feels like it's from an
official source. (And on the flip side, I was surprised to learn that Conda
_does_ do security review of things they include in their official
repositories; I assumed Conda would work like pip in this regard.)

Whether or not people _should_ believe this, it's clear that they _do_. Is
there something that the development communities can do to make it clearer
that software in a certain repository is untrusted and unreviewed and we
regard this as a feature? The developers above generally don't believe that
the presence of a package on GitHub, for instance, is an indicator of
anything, largely because they know that they themselves can get code on
GitHub. But we don't really want people publishing hello-worlds to PyPI, npm,
and so forth the way they would to GitHub as part of a tutorial, and the
Ubuntu Snap Store is targeted at people who aren't app developers at all.

~~~
eat_veggies
I like Arch's package management model, where sources are split into the
official repositories, which are manually approved, and the AUR, which
everyone knows are not officially endorsed or reviewed, and to check the
sources and PKGBUILDS for anything sketchy before installing.

The processes for installing from the two are also different enough that the
user can't mistake one for the other: official packages are a pacman -S away,
but installing from the AUR either requires a git clone and a makepkg -sri, or
an AUR helper that bugs you to review the PKGBUILD.

~~~
dtx1
Well as a lazy arch user i installed pacaur and just use official and AUR
sources without much checking. It's just convenient that there's an AUR for
everything

~~~
matthewbauer
Be warned that malware like this is in the AUR all the time. It's so common
it's not even newsworthy. They are usually pretty good at handling it though.

~~~
pierrec
I've never heard of this happening and I can't find a single occurrence of it.
I mean, I agree with "don't blindly trust everything in the AUR", but this
seems wrong.

~~~
nerflad
I maintain 14 AUR packages and have also never heard of this happening.

------
solomatov
The problem with snaps is that they didn't take security really seriously on
desktop: [https://www.zdnet.com/article/linux-expert-matthew-
garrett-u...](https://www.zdnet.com/article/linux-expert-matthew-garrett-
ubuntu-16-04s-new-snap-format-is-a-security-risk/)

>"X has no real concept of different levels of application trust. Any
application can register to receive keystrokes from any other application. Any
application can inject fake key events into the input stream. An application
that is otherwise confined by strong security policies can simply type into
another window," he wrote.

They might have wrapped X protocol to provide more security and control.
Instead they decided not to.

They might have created a system which is as bulletproof as on iOS where you
can install any apps and be 99.9999% sure that they won't steal your data
unless you allow them to. But they created this instead.

~~~
btashton
The issues with X11 you mention is part of what Wayland tries to fix. And why
early on seemingly benign things like screenshot tools broke.

~~~
solomatov
Yes, I understand that there're people in the community who try to fix the
problems. But it's really unfortunate, that Canonical tells us that it's
secure whereas it's not: [https://snapcraft.io/](https://snapcraft.io/)

>Snaps are containerised software packages that are simple to create and
install. They auto-update and are safe to run. And because they bundle their
dependencies, they work on all major Linux systems without modification.

~~~
matthewbauer
From what I gather, Snappy is mostly a marketing gimmick by Canonical. If you
want to packages apps, you should use something like FlatPak or AppImage.

~~~
solomatov
Do you know whether they more secure than snaps? I like the idea of running
whatever I want on my hardware without compromising security very much.

------
userbinator
_used a proprietary license_

Does the license actually mention it mines? I am reminded of a lot of
"freemium"/"ad-supported"/etc. software that makes its author money via ads or
whatever else --- and you agree to that if you read the license --- and it is
a bit shady to name the miner 'systemd', but it seems rather overboard to call
this "malware"... when I see that term I think of software that self-
propagates and exfiltrates personal data, delete/encrypts files for ransom,
etc.

Also from the page:

 _Size 138.8 MB_

I'm not really familiar with the latest trends in (bloatware?) development,
but a simple game like that taking >100MB would make me suspicious --- even
10MB is in the "questionable" range, and ~1MB would be closer to what I
consider "typical". 138MB is bigger than the installed size of Firefox, and
that's a far more complex application...

~~~
faho
>a simple game like that taking >100MB would make me suspicious

Nah. Games often feature a bunch of textures and video and sound files. Bad
compression or too high resolution on those is quite common, which is why
games _are_ often that large.

Also proprietary software usually ships a bunch of libraries - games often
ship with a premade engine, which are also often quite large.

As a datapoint, I have a copy of "Strata", which is a simple /minimalistic
puzzle game, and it _is_ 78MB.

~~~
colejohnson66
I remember the Facebook app being less than 20 megabytes in size half a decade
ago. Now it’s almost half a _gigabyte_

~~~
scarface74
And for the life of me I can't understand why people use the Facebook app. The
mobile web page loads faster, it's automatically sandboxed by being just a
browser page and it can do almost anything that the app can do.

Besides on iOS at least, if you click on a link from the Facebook web page,
you can take advantage of whatever content blocker you have installed.

~~~
fjsolwmv
If you log into Facebook on web, then visit any other site, they send your
browsing info to Facebook via Like button.

The Facebook app is _more_ sandboxed, since it can't snoop on your web
browsing.

~~~
michaelmrose
The facebook app for quite a while was actually sending facebook data about
your phone calls and sms so guess again.

~~~
scarface74
Only on Android....they couldn't do that on iOS.

------
paulpauper
A Monero miner is one of the more innocuous forms of malware ,compared to a
C&C trojan or a keylogger. Some websites will mine monero in the background.
Because it's just a js script, it's not much different than a banner ad except
it's less intrusive, yet somehow 'currency miner' has more negative
connotations than 'ad server'. That is the downside of decentralized mining
and asic resistance is you end up with a lot of zombie miners.

~~~
crispyporkbites
> Because it's just a js script, it's not much different than a banner ad
> except it's less intrusive

Tell that to your electricity provider

~~~
superkuh
The same thing can be said about JS ad analytics scripts and ads. Or sites
that turn the entire webpage into a JS 'web app' when it'd work fine as HTML
with static images and text.

~~~
viraptor
Not the same thing. JS increases the usage a bit. Badly broken JS may use a
lot of CPU - but the author still has the incentive to fix it. But mining is a
completely different category - it's designed to peg your CPU at 100%, because
that's what's profitable.

~~~
the_why_of_y
And what's worse, for every dollar you spend on electricity for CPU-mining,
you (or, in this case, someone else) receive 5 cents worth of cryptocurrency.

------
alsadi
Unlike flahub where either original develop or flathub admins take control

Canonical's Snapcraft literally says "Get published in minutes"

Any random guy would publish his malware with near no review

[https://dashboard.snapcraft.io/snaps/](https://dashboard.snapcraft.io/snaps/)

Yes, they maybe win the counter for published apps compared to flathub.
Congratulations!

~~~
matthewbauer
I really don't see the use case at all for Snappy. I mean FlatPak makes sense
for devs who want to "package- once, run everywhere", but Snappy is Ubuntu-
only. The thing is Ubuntu through Debian is really good at having lots of up-
to-date packages. Why abandon that for some crummy app store?

~~~
evand
The "Users by distribution" table at the bottom of the Spotify page is worth a
look: [https://snapcraft.io/spotify](https://snapcraft.io/spotify)

Snaps are not Ubuntu-only. You can find install instructions for many distros
here:
[https://docs.snapcraft.io/core/install](https://docs.snapcraft.io/core/install)

~~~
alsadi
Snap is a proprietary format that is canonical-centric, don't tell me that the
community make choice to make client opensource but official store both
hardcoded (initially) and closed source.

On the other hand,flatpak is a freedesktop project, done using open standards
like OCI and ostree.

~~~
popey
No. Snap is not a proprietary format at all. It's a squashfs file with a small
amount of metadata. You can make a snap by plopping a file in a folder, add a
simple snap.yaml which describes the application and then "make" a snap with
the common mksquashfs tool.

There is room in the world for flatpak and snap to co-exist. We created snaps
as an evolution on from clicks on the Ubuntu phone, and it covers use cases
that flatpak wasn't designed for.

~~~
alsadi
Remember ubuntu one storage solution? An opensource client does not make the
whole thing free software and open standard.

------
logane
Whoa, I made Hextris
([https://github.com/hextris/hextris](https://github.com/hextris/hextris), one
of the games removed from the store) a few years ago! Is there any precedent
in OSS developers being held responsible for misuse of their code?

~~~
shawn
From the license you chose:

 _The licenses for most software and other practical works are designed to
take away your freedom to share and change the works. By contrast, the GNU
General Public License is intended to guarantee your freedom to share and
change all versions of a program--to make sure it remains free software for
all its users. We, the Free Software Foundation, use the GNU General Public
License for most of our software; it applies also to any other work released
this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our
General Public Licenses are designed to make sure that you have the freedom to
distribute copies of free software (and charge for them if you wish), that you
receive source code or can get it if you want it, that you can change the
software or use pieces of it in new free programs, and that you know you can
do these things._

Part of the problem with letting people have freedom is that they have the
freedom to make decisions that impact communities in a negative way. But it's
usually worth the tradeoff.

This is probably the most relevant line though:

 _For the developers ' and authors' protection, the GPL clearly explains that
there is no warranty for this free software._

i.e. you have nothing to worry about, but you also probably can't do anything
to punish the misuse. After all, misuse is subjective.

------
the_common_man
This is exactly why you should not run random docker images and snaps. Docker
images are also run as root in many cases. It is better to build app images
from scratch and understand what exactly goes into the image.

~~~
solomatov
Why not run random docker images? As far as I understand, docker container are
pretty solid. Not super solid but solid enough.

~~~
subway
Those random docker images are rarely used in isolation. They typically handle
your data and often your customers data.

Beyond that, numerous escape exploits in linux containerization (and docker
specifically) have popped up over the years, and many more are going to pop up
over the coming years. This is not a mature space.

Running random binary code distributed from an non-curated source, even in a
"container" is going to end in heartache.

~~~
kuschku
And that’s why you should usually build your own images, and only trust docker
images from the same people whose binaries you’d also trust with all your
data.

(e.g. a docker image from RedHat may be okay, one from zhenghe8 likely not)

------
newnewpdro
It's only a matter of time before some major successful linux system attack is
delivered via snap/flathub.

Distributions and their package maintainers serve an important role. In the
interests of consuming more & faster people seem to be ignoring that.

I wish we had enough resources in the free softare community for all software
to be packaged and maintained in the distributions by independent parties
unaffiliated with the creators as a rule.

~~~
badsectoracula
In theory you can have the last bit with flatpack (and perhaps snap), the
issue here is auditing what goes in the repositories, not the package format.

~~~
newnewpdro
Have you ever gone through the rigamarole of getting a project into a major
distro like debian?

A bunch of the guidelines governing that process are simply unenforcable in a
model where the developer builds and publishes the release.

I am not of the opinion that those rules are irrelevant to the stability and
security of our systems.

There's a significant push to establish a more app-store model for linux
distributions, taking the distributor largely out of the loop for software
that isn't part of the base system.

This has both positive and negative consequences.

Today the negative consequences are largely hand-waved away with something
along the lines of "containers will protect you".

~~~
badsectoracula
I do not really see the difference between the app-store model and the
distribution repository model, at the end of the day both are models that
teach the users to only download stuff from a specific place. This introduces
gatekeeping middlemen that personally i'd rather do without. But if there is
going to be a central """trusted""" place, i'd prefer it to be distribution
agnostic.

(although even that isn't ideal since in practice it ends up with the major
popular distributions pushing agendas to the smaller distributions through
whatever requirements are there for "compatibility")

~~~
newnewpdro
It makes a substantial difference when we're talking about open software the
distributor builds from source. The major distributors set a relatively high
standard for the build process.

The same cannot be said for developers in my experience, who often don't even
see a problem with the build process accessing the network - and frequently
will publish releases built from the same host environment they use for their
general daily computing.

From the perspective of a distributor, the packages should be perfectly
buildable (and for official releases, preferably so) with a toolchain of known
provenance in a clean environment without network connectivity.

The priorities are quite different for the developer of software and the
distributor of systems incorporating that software. It's similar to the
tension between system administrators and developers.

------
_eht
This is the Snap distribution system working as intended with unfortunate
consequences.

------
thepumpkin1979
There is no review process for sandbox apps, the manual review is for apps
with access system wide.

------
mihaifm
Can anyone clarify if this is a possibility for apt packages as well? As far
as I understand, there are 4 types of apt repositories (for Ubuntu): Main,
Universe, Restricted, Multiverse.

I guess Main is safe since it's handled by Canonical, but the rest?

Moreover, a lot of installers simply add a custom repository to sources.list.

What are some good practices for a novice user, regarding apt?

~~~
matthewbauer
So, most source-based package managers are going to have higher standards &
catch something like this. Not every line is going to be audited, but
demanding free licenses, active git repos, and wide userbase goes a long way
to keep stuff clean. Obviously many valuable packages are left out & you will
be tempted to install the .deb files.

I would say if you are at all concerned about safety: don't install apps
through .deb file that developers sometimes push. They are generally safe, but
there is always a potential that these files are malware.

For instance, lots of people use Atom as their text editor, but Atom does not
make it possible/easy for packagers to build Atom from source[1]! Everything
used to come with a configure, build, & install script, but I guess it's not
hip enough anymore.

[1]: [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=747824](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=747824)

~~~
mihaifm
Indeed, building from source is falling out of fashion, with everyone creating
a package manager these days. I find some of these very opaque, for example
Rust has it’s own package manager which downloads and runs binaries at its own
discretion.

[https://github.com/rust-lang-nursery/rustup.rs](https://github.com/rust-lang-
nursery/rustup.rs)

------
chris_wot
I only get my packages from the central repos. I would be very wary of
downloading snaps unless I knew exactly who was distributing them.

Repositories are why Linux repos are free of malware. With more snap-based
packages being made available then we are going to see a lot more of this sort
of thing.

------
spullara
Apple's strategy for their store looks better and better every day.

~~~
kirubakaran
[https://www.bankinfosecurity.com/apple-battles-app-store-
mal...](https://www.bankinfosecurity.com/apple-battles-app-store-malware-
outbreak-a-8538)

~~~
scarface74
From looking at the link, it looks like it just sends information from the
device to a web server. It doesn't look like it would have access to anything
that any other app wouldn't have access to without explicitly asking for the
users permission.

------
DC-3
Nice case study in why Arch types are adament that you should properly take
the time to read your PKGBUILDs.

~~~
tarruda
Arch makes it clear for users that AUR packages are not official.

Ubuntu snaps very easily installable, just a quick command away, which can
give users a false sense of security.

------
Iolaum
If you use snaps, be aware that they update automatically on their own. You
have the option to set upgrade time windows but you cannot completely disable
automatic updates and use your own custom solution to update and administer
your system.

Discussion of this issue with snap developers here:
[https://forum.snapcraft.io/t/disabling-automatic-refresh-
for...](https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-
from-store/707)

~~~
jake_the_third
This is very unfortunate. Despite the negative press snaps is getting, I was
planning on releasing a commercial product as a snap. One of the key reasons
for doing so was that users had control over what the app is allowed do (via
plugging/unplugging slots), a feature flatpack lacks as far as I can tell.

However this changes everything. Disallowing owners from controlling their
software and hardware is not something I want to encourage. We have enough of
that from Microsoft (and to some extent GNOME Shell developers).

Does Flatpack also force developers' intentions upon their users? Or is
AppImage my only recourse?

I want a solution that doesn't mistreat customers.

------
yani
It great to see that the community acts fast and educates others.

------
jordigh
While this is obviously malicious, I think I would favour paying for things
with a few CPU cycles, as long as it was voluntary and overt.

Want to read this article? Please click here to mine a cryptocoin for 30
seconds. Great, thanks! Here's a cookie so we won't ask you again to mine for
a whole month.

I would much rather have this than being shamed into looking at ads. It always
struck me as utterly bizarre to be told that not wanting to see ads is somehow
immoral.

~~~
dingo_bat
That may be fine on desktops but absolutely unacceptable on mobile and
laptops, due to battery usage.

~~~
jordigh
Wouldn't be a payment if CPU cycles didn't have some scarcity.

My laptop would be fine with 30 seconds of a CPU spike, though. Most phones
could probably also tolerate it.

------
sleavey
As someone who hasn't yet used Ubuntu 18.04, is the snap store something I'll
be using in 5 years time instead of APT, is it just another attempt by
Canonical to jump on the app store bandwagon, or is it something completely
different?

Excuse my ignorance but I'm intensely suspicious of "stores" on open source
operating systems.

~~~
Sylos
You might be using it instead of APT for some things, but it won't replace
APT.

Say you want the newest version of LibreOffice for whatever reason. This is a
typical use-case where Snaps will come in handy. They have most dependencies
bundled into the application, so you don't have to worry about your whole
system getting wonky by installing newer versions of those dependencies to go
with the newer version of the application.

This is also meant to serve as a way for devs to release software without much
hassle. So, they don't have to open-source their code, hope that someone finds
it, packages it for Ubuntu and in like five years time is available to end-
users through the repositories.

They also don't have to worry about building a .deb, .rpm, Arch's format and
whatever else there is, including accounting for the differences between
distros. So, Snaps are supposed to work on all distros the same.

Ultimately, this will bring in more proprietary applications.

Well, and Snaps are sandboxed, so there's some protection, which makes those
proprietary applications somewhat more acceptable, but as this piece of news
shows, it's not complete protection.

Is it another attempt of Canonical to jump on the app store bandwagon? Most
definitely yes. There's a competing format, Flatpak, which does pretty much
the same, also AppImage which is somewhat older and without sandboxing, and
Canonical is mainly just pushing their own format, because they'll have
control of the store behind it.

Like, it's not impossible to hook up other Snap stores, but Canonical has
established their infrastructure as the primary source and then how many users
are going to look elsewhere?

~~~
sleavey
Thanks for the info. I like that Canonical are trying to solve the problems
with package managers, but it's a shame we can't focus on making APT and
friends more capable of the positive parts of app stores without bundling
things into binaries akin to Windows executables. Allow multiple versions of
libraries able to be installed, provide path translation (so systems that
store binaries in /opt and others in /usr can still work from the same .deb
file) and make sure repositories are more frequently updated. This might
require Ubuntu to move to a rolling release, at least for some of their
products (maybe they could keep releasing LTS versions every two years but
have a rolling release for everything else). Sandboxing is arguably nothing to
do with the package manager or app store - it's the kernel's problem. And
bundling dependencies together is bad for security - critical vulnerabilities
(recent example being in SSH) would not be able to be patched with one update,
leaving unmaintained code that bundled a vulnerable dependency permanently
flawed.

I think I'll wait for this most recent example of the trend to make everything
into an app to blow over...

------
jancsika
Is there some workable way to just add rando user-requested distros (or, more
importantly, Debian) to a PPA? Is there some alternate/sane way to distribute
packages for Gnu/Linux without smothering my development process in molasses?

I don't even mind creating a VM for _every single distro_ a user requests, and
doing a huge automated binary compilation fest for every release. The only
thing I care about is that the software is distributed through channels which
make it explicit that the current stable version is the _only_ version I
support.

~~~
j605
It is not the job of the developer to package software, that is for
maintainers. The best you could do is specify dependencies and tell them how
to compile. If it is proprietary, then you might have to support a few popular
formats(debs and rpms) and make sure they also work on other distributions
without much effort. For example Arch User Repository has google-chrome that
repackages it into the native package format but since all dependencies are
known, the binary packaged for Debian also works in Arch Linux.

------
rrix2
It's too bad there isn't some sinister cabal of trusted individuals within the
Ubuntu project that can review packages for quality and package them securely
and in an auditable fashion.

~~~
aritmo
A snap package may ask for elevated permissions. In that case, it goes for
manual review.

But if it does not ask for special permissions, then it goes in automatically.
Because the app is quite confined.

Compared to other package repos, here it's somewhat better.

------
nkkollaw
I've had bad experiences with Snap.

I understand that with Snap devs have to bundle their own dependencies and
take care of upgrading, which is bad if I understood correctly.

In my case, a few programs I had installed needed to be connected to other
snaps, and they would suddenly stop working for no apparent reason. Only by
trying to launch the misbehaving program from the command line I'd find out I
had to update the connected program(s).

Has never happened to me with Apt, so my opinion so far is that installing
.deb files is vastly superior, at the moment.

------
hsivonen
How does one figure out who a given snapcraft packager is? E.g. Sublime Text
says it's packaged by Snapcrafters. Who is that?

~~~
hsivonen
Presumably it's
[https://github.com/snapcrafters](https://github.com/snapcrafters) , but what
links the Snap Store identity to that GitHub org?

Where does snapcraft.yaml get executed? On my computer? On Canonical's infra?
On the packager's computer?

~~~
popey
The build service at build.snapcraft.io is what builds it. Anyone can hook up
their github repo (containing a snapcraft.yaml) to build and have to
automatically rebuild the snap when changes in the git repo occur. It then
pushes the snap to the 'edge' channel in the store. Developer validates that
build and then pushes to stable for all users.

~~~
hsivonen
Thank you.

As a user, how (other than asking here) was I supposed to convince myself of
the identity binding between “snapcrafters” and the GitHub org and to convince
myself that trust in the correspondence between snapcraft.yaml and what I get
when I install a snap is rooted in Canonical’s build service and not in
trusting an individual uploader not injecting different binaries?

------
hsivonen
The risk here is not just going to the Snap Store. At least right now on
Ubuntu 18.04 if you type a command that's not installed but is provided by a
Snap app, the shell suggests that you install the snap the way it suggested an
apt command previously.

------
tarruda
I'm not familiar with Ubuntu snap store, but how does it compare with Google
play store in terms of security?

For example, do apps need to request permissions for accomplishing specific
tasks, or is there any kind of sandboxing involved?

~~~
aritmo
The snap packages can either ask for elevated privileges or ask for standard
access. In the former, they go through some manual review.

I do not know if there are any auto checks when the package is added
automatically.

------
alsadi
One need to take special care about snaps as they need to be a sandboxed gui
apps. According to OMG ubuntu report this incident installed system services.
And we know that snaps can ship even kernel modules.

------
dschuetz
Snaps was initially tooted as _the_ bestest securest container based
application solution by Canonical back then. It is impossible for the app the
steal your data, they said. Because of "secure encapsulation" and such. So,
that means that there is no need for a review process for uploads, just to
make installing packages even _more_ easier than it already is?

I'm sorry, Canonical and Ubuntu are the point were Open Source Software
apparently breaks with its traditions. No review on binary blobs uploads most
certainly made with OSS when marked "proprietary"? They are kidding, right?

------
ezoe
Ubuntu 18.04 is horrible on this.

The default GUI package manager, "Ubuntu Software" shows up snap packages just
like ordinary packages. It was uploaded by somebody who is not bright at the
domain and badly configured for locale. It can only handle ASCII characters.
Probably reviewed by nobody.

------
dingo_bat
Can somebody explain the need for this new package management thingy when apt
exists and works nicely? Why have 2 softwares to do the same thing.

~~~
nerflad
I agree; I have zero interest in installing software using anything other than
my system's default package manager. The whole point of package management is
centralization, keeping track of chaotic dependencies and install states.
Having multiple package managers, that don't know about each other's state, on
the system defeats the purpose entirely.

------
ahbs66
>For example, the 2048buntu snap was submitted as proprietary, so we can't
actually see the package contents, except for the init script which you can
see above.

Unless the Snap Store uses some kind of DRM, I don't see how that can be the
case. Just install it and see the contents in your filesystem?

~~~
tmerr
It probably refers to distribution of binaries without source code, which MIT
license allows. Wording could be better

------
Kototama
One more confirmation that Ubuntu cannot be recommended anymore.

~~~
coatmatter
I think it would be useful if such declarations followed up with an
alternative suggestion.

I have no alternative suggestion, because Ubuntu is still what I would
recommend to new users even if it's not what I personally use anymore, because
they have the track record for getting new Linux users on board and helping
them out (via the prominent search results for common problems people come
across, etc). On the whole, I also think their design has been consistently
decent (including Unity).

------
xyproto
> Nicolas Tomb used a proprietary license for at least some of his snaps. For
> example, the 2048buntu snap was submitted as proprietary. The game in
> question, 2048, uses a MIT license

No! MIT is not a proprietary license!

~~~
Xylakant
The article doesn’t say it is. The snap uses a proprietary license which is
possible since the game on which the snap is based uses MIT - which allows
redistribution under a proprietary license.

