zlacker

>>jstanl+(OP)
It's an interesting article (and thanks to the author for putting it out) but I wonder what their end goal is. Is it to have a 100% secure/private phone? I'm not sure if that's possible with the proprietary firmware (though the hardware kill switches are certainly a good idea). Most importantly, the questionable usability means that either the Librem team needs to work much more, or... this becomes a "smarter" alternative to a dumb brick without giving data to Big Tech. (Ignoring the fact that a sim card automatically makes you lose privacy to the government/telecos).

When comparing against something like a Pixel running GrapheneOS, it's honestly a bit more puzzling to me. Granted, I'm definitely not the audience for this, but with G_OS you can do most things that a regular phone can do, without taking several minutes to install Firefox.

As much as I love privacy (going as far as having a semi-random username), this phone is a bit puzzling. I hope someone can throw more light on this.

>>user_7+X7
The general idea behind any 'pure' Linux phone is to have a device that you can trust at least as much as a desktop running Linux. Security is definitely a key aspect for many. But it's also the flexibility of not being locked in to anything on the software side. Ideally, it also extends the useful life of the device as when vulnerabilities and bugs are found, they can be fixed rather than junking the device for lack of updates. It's still pretty early days re: 'full' Linux on mobile and so it doesn't look like much yet... it takes time. Desktop Linux didn't look like much in 1994 either.

I'm not familiar with GrapheneOS but I assume it follows the usual model when repurposing Android devices of taking various closed source blobs (i.e. drivers etc) and rebuilding the open source bits around them? If so, this approach usually locks you into a Linux kernel version to remain compatible with the blobs which limits you on kernel features and fixes as well as who knows what exposure the blobs have to offer, which also will likely never get updates.

>>blihp+ka
Linux desktops are not secure in any meaning of the word. Running everything as the same user is a catastrophe, see the recent “package-manager wiping out $HOME issue”. This should simply not happen in the 21st century, and we really should not make ourselves believe that we are safe just because desktop linux is seldom targeted and that the community is giving and well-intentioned for the most part. It is no longer a small village where everyone knows everyone and we could leave the doors open.

>>kaba0+2Z
Sure, if you run (most of) them in their default configuration. However, they can trivially be made much more secure which is one of the appeals of Linux to some: you're not limited to whatever set of compromises a vendor decided was acceptable.

>>blihp+Fc1
Just because there is firejail, it won’t magically make it secure. It also has to be comfortable to use, for which you need communication between the app and the os handling permissions a la ios/android. Flatpak is going in that direction but I don’t necessarily like the approach of mixing packaging and sandboxing together.

>>kaba0+pd1
Those are just two options (I'm not a big fan of either)... there are a myriad of other options available.[1] While I disagree with your assertion that Linux desktops are not secure, I would agree that making them more secure is not trivial. If you changed your assertion to 'they are not secure by default', I would agree with you.

I would disagree with 'has to be comfortable to use' as that is often at odds with 'secure'. Some of the things I do to secure my system make infrequently done/high risk things quite uncomfortable to use. Not because I wanted to make it uncomfortable, but because that's what it took to get the level of security I desired.

[1] I would also argue that spending too much effort here before addressing other attack vectors first is rather silly. (i.e. web browser, network, minimizing usage of/isolating 3rd party binaries)

>>blihp+bu1
Sure, I may have used stronger language than necessary because I do feel strongly for the issue as I am really fond of the kernel and many of the excellent work of the ecosystem. What I meant under “comfortable to use” is that a sandbox needs to communicate with the sandboxed application and with the general system to be truly usable. Otherwise it is more like a firewall for syscalls. Which has its place and is good for an absolute boundary, but it is not a UX for end users. If I use a bad firefox profile in firejail it should not just crash, firefox should be told what’s the situation. The most basic example would probably be a file chooser dialog — the application should be able to call for such a dialog but the dialog is made by the OS and only the selected file should be made available to the sandboxed program. Flatpak’s portals are a good direction, but I’m not sure that it is a good implementation.

I also have to agree with you on the “one can make it secure” part, e.g. android builds on top of pretty standard linux tools to achieve its better security, namely selinux for a larger boundary and the most important: running different processes as different users! It is such a gaping security issue in typical DEs, as otherwise not even the very crude UNIX permission system can do anything meaningful (other than the relevant xckcd comic: the attacker can access all my files, my browser cache, etc, but at least can’t install a video driver)