[kwlug-disc] linux distro ... -> sandboxed runtimes

Tue Oct 21 14:26:21 EDT 2025

I've been using LibreWolf for a few months now, and I like it better than
FF  (Chrome is out of the question!)

LibreWolf can be a bit fussy sometimes, and cause some websites to fail,
but overall it's a solid browser.

As to Snaps versus Flatpak, I actually dropped Ubuntu after many years
because they were getting to pushy with the Snaps business.  They were
getting too Microsoftish in trying to shoehorn users to do things
their way.  I'm now on Debian and much happier.  I do use Flatpak on
occasions, but mostly I live in the package manager, or even the occasional
AppImage.

On Tue, 21 Oct 2025 at 16:21, Doug Moen <doug at moens.org> wrote:

> On my Linux desktop systems, I use flatpak instead of snap.
> The main difference, from my perspective, is that flatpak puts the user in
> control of their experience, and puts the developer in control of what they
> ship, while with snap, Canonical is in control.
>
> I can add or remove sandbox permissions from a flatpak using "flatpak
> override ...".
>
> My phone runs GrapheneOS. Graphene has a richer set of sandbox permissions
> than Android (eg, you can deny network access). As a user, I can add or
> remove permissions from my apps.
>
> For me, flatpak and GrapheneOS are the best available solutions (for
> desktop and mobile) of the problem that Mikalai describes.
>
> For desktop browsers, I have replaced Firefox with LibreWolf, and I have
> replaced Chrome and Chromium with Ungoogled Chromium. Both provide superior
> security, privacy and control. Of the two, I like LibreWolf better, but I
> like to have multiple browsers based on different engines. For me,
> LibreWolf takes the GrapheneOS attention to detail for security, privacy
> and user control, and applies those values to a desktop web browser.
>
> https://librewolf.net/
>
> Mikalai talks about curated and trusted app stores. The important thing is
> that you should have a choice, rather than the corporation that owns the
> platform having total control.
>
> On Kinoite, the flatpak app store defaults to a selection of apps that are
> endorsed by the Fedora project. There is a button for adding Flathub as an
> additional source, and Flathub is more of a free-for-all. The flatpak
> ecosystem was designed to support multiple app stores, and I'm already
> subscribed to two of them on Kinoite.
>
> On Android, I do not trust the Google Play Store and I won't use it. I get
> most of my apps from the F-Droid official repo, because I consider them to
> be the most trustworthy. The F-Droid client permits you to add additional
> repos curated by other people with different priorities, and I have added
> some additional repos for a handful of the apps I've installed.
>
> Doug.
>
> ----- Original message -----
> From: Mikalai Birukou via kwlug-disc <kwlug-disc at kwlug.org>
> To: kwlug-disc at kwlug.org
> Cc: Mikalai Birukou <mb at 3nsoft.com>
> Subject: Re: [kwlug-disc] linux distro ... -> sandboxed runtimes
> Date: Tuesday, October 21, 2025 2:08 PM
>
> There is an important aspect with sandboxed runtimes. Sandbox doesn't
> allow program to "do anything", requiring permissions, ... but who
> should be passing a judgement call: "Big Store" or a "little user/me".
>
> Context quote:
>
> > My own personal experience with Snap as a developer is such that I won't
> allow Snap on any of my machines. When I was working on the Curv open
> source project, a contributor created a snap package for Curv. I tested it,
> and it didn't work on my machine due to a sandboxing problem. But Blender,
> another 3D modelling program, did work on my machine in snap form. The
> difference was in the sandboxing parameters. I asked the contributor to use
> the same sandboxing parameters for the Curv snap as was used by the Blender
> snap. The answer was: this is impossible, because Canonical would not
> accept the Curv snap with those parameters, and therefore it was impossible
> to distribute the snap. Only Canonical had the power to allow Curv to run
> correctly, and the Curv project did not have the same level of political
> power as the Blender project, so we were out of luck.
>
> Let's replace: snap -> Android Google Play store, parameters for Curv ->
> permission to use camera, -- and we would get a similar situation where
> another "Big Store" makes decision on behalf of users, ... to protect,
> of course, ... while removing any freedom from users, by removing
> competition.
>
> Argument would then go, "how could little user/me" know?
>
> Let me come back to short discussion at our October meeting:
> - many of these systems with sandboxed runtimes for apps have explicit
> permissions parameters, in manifests.
> - tools can be made to analyze relationships and give "little user"
> actionable suggestions. Information is there, in every user's system.
> - such tools where not observed, even by those who are tasked with
> making information security judgements.
>
> What if there is a meaningful help to "little user" for making
> permissions? Then the "free world" stops being a synonym with "dangerous
> world".
> What if it is a "middle user", organization's admin? Then we can have
> secure organization context without giving all controls to "Big Co's",
> with their tendencies.
>
> Note that browsers are also similar sandboxed runtimes, and many learn
> phrase "User Agent" first in browser context. Hence, experience with
> browsers is also relevant here.
>
>
>
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.
>
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20251021/f702f526/attachment-0001.htm>