I only have two accounts, one "serious" and one "off hours" but I still feel better protected than most people.
I only have two accounts, one "serious" and one "off hours" but I still feel better protected than most people.
Some Linux distros too have things like this but unfortunately there is no buy-in across the ecosystem so "sandboxing" is done in a half-baked way.
The problem is when applications in general aren't written with sandboxing in mind, and when you have to choose between apps not working properly or having a leaky sandbox, you will opt for the latter.
I wish some big corp bit the bullet and ported hundreds of apps to a new, sandboxed environment in Linux, while attempting to upstream the whole effort. This would necessarily involve things like fully migrating to Wayland (X11 security is awful), only granting filesystem access through distro-sanctioned file pickers (so you need some coordination among Gtk, Qt, and other toolkits), and generally having a deny-by-default policy: first you make secure, then you fix what broke.
I had wanted to add conditional compilation to one of my programs to work with the sandboxing but there are too many problems with the sandboxing system that it will not work, since my program requires that popen can call programs specified by the user at run time, and that some files it accesses depend on user configuration, and that it uses non-Unicode text, and accesses multiple files whose name are the same base name given on command-line arguments but with different suffixes.
Some programs might work even if they are not designed for the sandboxing, such as if it uses stdin/stdout/stderr only, and not other files. However, many programs will use other files too.
Personally, I am not so sure about Flathub (the 'official' repository for Flatpak bundles), but Flatpak itself is a welcome (and large) step towards universal sandboxing for desktop applications.
[1]: https://www.spinics.net/lists/fedora-devel/msg312784.html
I'm saying this because we're talking through a platform that is trusted by the majority of pepple to run malware - the web browser. We don't manually check if the Javascript or Wasm code is good or bad before we visit a web page. Few people disable scripts altogether. We could have this level of trust in applications running on our system - but does Flatpak deliver it?
For JavaScript, web browsers have good sandboxing, but arguably also have a smaller attack surface than Flatpak because the page cannot run system calls directly. I don't yet know enough about WASM to know if that tangibly changes the situation.
If I need it that badly, I'll build it myself.
I found one with some of those features and some more, with only one minute of googling https://apps.apple.com/us/app/graphcalcpro2go/id1091870099
That's for iOS but why not on Windows or Android? I'd be surprised to find one like that on Linux.
But it's much more urgent in ecosystems where the norm is to install untrusted, proprietary software supplied directly from developers/publishers with minimal real human oversight from anyone.
A lot of Linux users rely just on the distro itself for their software, which is way, way safer than the way people install software on macOS, iOS, Windows, or Android. This is probably part of why desktop Linux has lacked these facilities as a default for so long, and also why Flatpak sandboxing is seen by so many users as 'about' proprietary software.
It's definitely needed, by now, though. There's still a fair bit of proprietary software that has strong network effects which compel even some users of libre operating systems, like Zoom, Slack, and Discord. It's way better to install those with sandboxing than give them access to the normal packaging mechanisms whose design assumes a level of trust and social oversight that's just not there for third-party, vendor-provided packages and repos.
I'm also in the process of whipping through getting prosody (a subcomponent on which jitsi is built) set up in such a way as to also be able to handle most of what people would use Slack or Discord for.
The primitives for much of the modern corpo-ware environments have been available for a while. The best part is that those you build from scratch don't even require extra firewall config to nuke the telemetry of. Just leave that part out!
For the others, it can be more work.
Either way, the reality is that many people install those untrustworthy proprietary apps insecurely today, using vendor-provided DEBs that have a history of huge misbehavior and serious security vulnerabilities.
Trying to understand what's going on in a computer or a network can be overwhelming. I understand the need to simplify, to take for granted, to abstract away— to ritualize, even.
But sometimes I do feel frustrated that engineers (whether in application development or infrastructure or networking, whatever) can be frustratingly uncurious about the tools they're using. 'How it works' should never mean 'how to operate it', but a lot of people use those terms interchangeably, even within tech.
For me, though, using F/OSS isn't about reading code. It's about feelings and values like trust, respect, control, and peace. When you manage to avoid proprietary software entirely, you can recover those things in your computing life in a way that is totally opposite to the adversarial relationships most people have with the software they run today. It's easy to 'not know what you're missing', especially because you don't really get it from just using a few pieces of F/OSS on a proprietary platform.
But the real reason to use F/OSS is to take refuge and let go of that tension of the posture you have to take with software whose authors don't have your interests at heart, that alertness and readiness to swat away nags, to dodge traps, to dig up the checkboxes and registry hacks and configuration files you need to disable an endless onslaught of individually small but nonetheless malicious behaviors.
Imo, that makes it worth it to try to convince a few of your friends to explore Jitsi or Matrix or Revolt with you instead of trying to make room for whatever proprietary social media apps are trendy right now, even if you have never read a line of code in your life.
So what if you will have containers / jails? -- You still need to install multiple components into the same container / jail... because you need them to work together. It's not solving the problem at all. Of course, containers are useful, but not for the purpose of solving installation of software comprised of multiple components problem.
Lisp on bare metal, FORTH, anything. BASIC. It has to be small.