The worse Chromium gets the better. It will take decades to reverse the damage that HN and many web developers did by pushing a single browser engine instead of fighting back.
Next, Microsoft needs to get on top again and show Google how it's done. OG monopolism.
> A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
> First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed.
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store.
This is not entirely correct. Distributions can use a "brand store" to have complete control over which packages their users get.
> You can’t audit them
Many Snaps contain a build manifest in `/snap/snap-name/current/snap/manifest.yaml`. This manifest contains a log of everything that is used to build the package. For snaps built on Launchpad, this is automatically enabled and includes a link to the Launchpad build log for that snap. This is one of the build logs for the Chromium package, for example: https://launchpad.net/~osomon/+snap/chromium-snap-firstrun-n...
Using Launchpad as the source of truth, you can be 100% certain that the snap you're running is built from the source it presents. This is the same infrastructure that builds and provides trust for Ubuntu itself.
The snapcraft build service uses Launchpad in the background, so any snap built using that can be audited just like regular Ubuntu packages. Snaps built on third-party infrastructure can enable this manifest using an environment variable.
I don't know why Linux Mint is spreading such misinformation, but this is harmful.
Users have many ways to hold snaps temporarily. If they want to hold snaps indefinitely, then they should install them using he `--dangerous` flag. That won't give them any updates, but I'm guessing that's the point. They can always get the latest version of the app manually using `snap download snapname` and install it using `snap install snapname.snap --dangerous`.
> modify them
Just like a `.deb` package, users can unpack a snap, modify any file, repack and install the modified version. Alternatively, you can unpack the snap, modify any file and install the directory using "snap try". You can then modify files and rerun the app without having to reinstall it for every change.
> or even point snap to a different store.
The signing keys are baked into the Snap binary but the URL is configurable via an environment variable. So users can change to a different Brand Store without any issue. If they want to use a store with a different signing key, they have to install a different version of snapd which is compiled with the signing keys of the other vendors.
This isn't an insurmountable problem, but it is less flexible than apt, yes. Although I think "apt remove snapd; apt install snapd-fsnap" is still pretty easy..
The security issues SUSE raised were actually fixed, but the Snap developers did not respond quickly enough with the info that the issues were fixed.
> I'd like to point out that the reason for the closure was not a failure at addressing any of the raised issues, but a failure to reply to either of the requests for a status update in July and September.
Next, Microsoft needs to get on top again and show Google how it's done. OG monopolism.
Finally some blood!