1. 39
  1.  

  2. 18

    I’ve preordered it back in … jeez, 2017? What makes the Librem5 a major improvement (imo, of course) in comparison to Android or iOS is that it is actually free software and hackable. Those security features (someone called it security-LARPing recently–I think that fits here) always felt like they are to generate more press around it, and looking at how it was covered in the relevant media, it worked.

    1. 4

      I sadly had to refund my order a few months ago to pay for repairs on my car :(

      1. 1

        I’ve preordered it back in … jeez, 2017?

        Same here. That’s a long time ago. I hope to receive it sometime this year.

      2. 24

        Hackerism strikes again. Linux is not gonna save us from Google/Apple, but a serious project with focus on UI/UX, backed by little (cooperative?) manufacturers and a solid ecosystem will do. Let’s make a mobile OS for everyone, not just put Linux on the phone.

        1. 13

          That was my issue with so many of these Linux phones - the phone isn’t interesting just because it has Linux on it. A Nokia N900 was a great phone because it had UX polish, an ecosystem, and quality hardware and software. Otherwise, you get something uninteresting like a Freerunner.

          1. 3

            I never had a N900, but I did have the N9 successor, and to this day it’s probably the best phone I ever had UX-wise.

            But … WhatsApp didn’t make an app for it, so eventually it was kinda useless as I couldn’t talk to my friends. Unfortunatly, building a viable non-Android/iOS phone is much harder than building just a good phone. Microsoft discovered this as well.

            1. 3

              I loved my N900. And I loved my Windows Phone after that. Android is still a slum compared to either of these, sadly; it did get better than it used to be a decade ago, at least. (If I can’t have a Librem 5 or it’s not feasible to use/any good (likely, sadly), it’s the new iPhone SE for me.)

              1. 3

                I just get the cheapest phones I can find these days; I tend to lose/break them anyway. I currently have a Galaxy A2 Core for about €70 which runs on Android Go, and it actually works surprisingly well. The only thing I miss is that the screen doesn’t light up on notifications.

          2. 8

            Linux is not the right choice at all to begin with, which is why Google is working on Fuchsia.

            The monolithic kernel approach prevents any hope of security or responsiveness, as the kernel is huge, runs fully privileged and would be impossible in practice to formally verify to be secure and to be able to meet some hard realtime deadline, no matter how high (like, years) you set this deadline; The kernel might never yield the cpu. There’s simply no proof it ever will.

            In contrast, seL4 is formally proven. It can enforce separation, and the kernel grab on the cpu will never exceed the WCET.

            It is by no means easy to build a sizable secure system or realtime system. But at the very least it is possible to do so with the microkernel multiserver approach. It simply isn’t with Linux.

            1. 8

              The monolithic kernel approach prevents any hope of security or responsiveness, as the kernel is huge, runs fully privileged and would be impossible in practice to formally verify to be secure

              I’d be interested in an analysis of reported Android security bugs cross-referenced to where they ultimately occurred: in the kernel, in a specific kernel subsystem, or module, or in a layer above the kernel. I think, but don’t know, that we’d find that very few of them were ultimately in the kernel at all.

              I appreciate your comment was really about formal verification. Is the iOS kernel formally verified? Or any smartphone kernel past or present?

              1. 7

                Is the iOS kernel formally verified? Or any smartphone kernel past or present?

                As far as I am aware, no and no.

                There’s much yet to be done in the operating systems field.

              2. 8

                In short: Linux can be used just fine for systems like this, monolithic and unverified as it is. The proof is, after all, in the pudding, not in the recipe used to make it.

                Longer: Theoretically those verified systems do have several advantages when it comes to designing secure (in all the meanings of the word) products but thus far this theoretical advantage has failed to pan out at scale in real-life systems. Why is that? Ever since the inception of Linux and the well-known spat between Tannenbaum and Torvalds this discussion has been going on while Linux spread like wildfire. In that period a whole host of theoretically-superior-when-it-comes-to-security systems has seen the light… and failed to thrive. Why is this? What makes Linux (and similarly ‘evolved, not designed’) systems thrive while these alternatives wither on the vine? Is it just the unwillingness of the market to invest in alternative solutions? If that were the case I’d have expected at least one of these alternative systems to have thrived in the alternate world of academia but this has not happened.

                I suspect the reasons are many:

                • evolved systems consistently outperform designed systems
                • lack of hardware support (a.k.a. ‘drivers’) keeps designed systems back, partly due to the need for formal verification - a system is a strong as its weakest link
                • verified systems and proprietary software do not mix - no binary blobs in verified systems…
                • …leading to even less hardware support because vendors don’t want to expose their ‘intellectual property’ for all to see
                • to make a difference in real life, everything needs to be designed and verified, from the ‘kernel’ (in whatever form or shape, from monolithic to micro to whatever) to that silly little clipboard app which suddenly got popular, otherwise the resulting product will still leak data to the adversary. Who gets to be the gatekeeper to separate the chaff from the grain? The user? Some benevolent overlord? In the former case many users will just install the damn app because of reasons and poof there goes trust. In the latter case a new apple or google or big brother just saw the light.
                • more reasons: _________________ (fill in the blanks)

                Anyway, given the open nature of this new crop of hardware - Librem, Pine, etc - the chance of proving the merits of these designed systems is there, may the next Linux Torvalds rise to make fame as the one who managed to launch seL4 or any of the other candidates into the main stream. Until such time, Linux will do just fine.

                1. 6

                  If that were the case I’d have expected at least one of these alternative systems to have thrived in the alternate world of academia but this has not happened.

                  Microkernel, multiserver systems are widely deployed, just not very visible.

                  Much progress has been done in the operating systems field. Tunnel vision manifests as only seeing Linux’s progress, and being blind to everything else that’s been going on.

                  A valuable resource on the topic is Gernot Heiser’s blog, for anyone who wishes to get started.

                  Ever since the inception of Linux and the well-known spat between Tannenbaum and Torvalds this discussion has been going on while Linux spread like wildfire.

                  For anyone who hasn’t read it, here’s the last installment.

                  The proof is, after all, in the pudding

                  No, it isn’t. Dressing Linux up nicely won’t change the fact it is not suitable. Google has discovered this already (Fuchsia), so has Huawei (HarmonyOS).

                  evolved systems consistently outperform designed systems

                  Linux is fundamentally incapable of security and of hard realtime. No amount of duct tape will change the fundamental facts of a system.

                  to make a difference in real life, everything needs to be designed and verified

                  Actually, this is not the case. Once isolation can be enforced (as seL4 manages to) and assuming the system is modeled around capabilities (Not to be confused with POSIX capabilities. There’s a good introduction to capabilities in Genode’s Book), mitigation actually works. Nothing can overstep its capabilities as the system actually mandates so.

                  silly little clipboard app

                  Would have a hard time justifying it needs access to the network (to leak your data). Just requesting such capability would quickly flag the app suspicious. Monitoring what the app does is also much easier when the capabilities it gets do come from wrappers designed for the purpose. The clipboard app would only see an interface, and have a hard time determining what the implementation is.

                  1. 1

                    The silly little clipboard app will want network access to allow it to react ‘intelligently’ to whatever is on your clipboard so it can do its thing - translate the contents, find better prices for the product you just marked, suggest alternative sources for the marked content, tell them which of their friends marked similar content, etc. People will say ‘OK’ when confronted with the choice to allow or deny network access, after all they want that silly app to work.

                    When confronted with fool-proof systems, ${god} reacts by creating better fools.

                    1. 5

                      If we accept the assumption that user is able to at the very least avoid sabotaging themselves by giving away all the keys, we can end this “no system can protect against user stupidity” tangent I won’t follow you further down with.

                      Then we can go back to discussing whether Linux’s design is a good fit. My take is, as you know, that it is not.

                2. 4

                  The monolithic kernel approach prevents any hope of security or responsiveness, as the kernel is huge, runs fully privileged

                  Even (NeXT/)Apple who pushed a microkernel (Mach) towards a monolithic kernel is now migrating to user-space drivers and networking extensions for security reasons.

                  1. 5

                    NeXT always ran Mach in a single-server model. In this mode, Mach is basically a hardware abstraction layer, not a microkernel. Most monolithic kernels have adopted similar layering (and, in the BSD world, pulled in a lot from Mach) but there’s no real advantage to having isolation between a HAL and a single security context running on top of it, so this largely went away.

                    Single-server Mach is much closer to a hypervisor than what most people think of as a microkernel and hypervisors are incredibly common. Even Android is moving towards having a hypervisor (hafnium) under Linux to run the security-critical things in a non-Linux VM.

                    1. 4

                      NeXT always ran Mach in a single-server model. In this mode, Mach is basically a hardware abstraction layer, not a microkernel.

                      I never meant to suggest that they ever used it differently than a single server kernel. This is well-documented history. I should have completely left out this comment. It was more meant as a nod towards Mach’s original development goal [1] to make a microkernel (and things are going more towards that direction again). Even though they only reached that goal with Mach 3.0 (which was too slow to be a practical UNIX kernel anyway).

                      [1] I may be wrong there, I always thought that this was one of their original goals, but maybe this was only a goal of Mach 3.0?

                    2. 3

                      Even (NeXT/)Apple who pushed a microkernel (Mach) towards a monolithic kernel

                      Mach is a first generation microkernel or so called pre-Liedtke. The context switch cost of Mach is horrendous, thus it is seldom used in a multiserver configuration.

                      NeXT did what they had to do at the time, and Apple could have switched to L4 or some other post-Liedtke kernel, but they unfortunately have not.

                      Linux is also slowly getting more interfaces and optimizations to “run drivers and subsystems in userspace”, but as with Mach, it is ill-suited for this.

                      The whole industry will move past Monolithic kernels. Give it time.

                      1. 3

                        Mach is a first generation microkernel or so called pre-Liedtke. The context switch cost of Mach is horrendous, thus it is seldom used in a multiserver configuration.

                        Sure. But it seems that they want to move things that they have traditionally had in kernel space to user space, but probably find it more attractive to gradually morph their kernel into something more secure than doing an abrupt rebase of their system. Which makes Fuchsia all the more impressive, but we have to see when/if Android actually switches to Fuchsia.

                        That said…

                        NeXT did what they had to do at the time, and Apple could have switched to L4 or some other post-Liedtke kernel, but they unfortunately have not.

                        Apple is no stranger to L4, since their secure enclave runs an L4-based OS, so every recent iDevice/Mac is running L4, just like any modern Intel CPU with ME is running Minix :p:

                        https://support.apple.com/guide/security/dedicated-boot-rom-and-anti-replay-services-sec0fe6a5c39/web

                  2. 5

                    Let’s make a mobile OS for everyone, not just put Linux on the phone.

                    But isn’t putting Linux (or some free-as-in-freedom OS) on the phone the very first step? Perhaps I misread the implication, but I think what you (and others) are saying is that projects like Librem are a net negative, whereas in my opinion they are a huge leap forward.

                  3. 20

                    This is technically 100% true but completely misses the point (ahem). Yes, Android and iOS sandbox their apps and have a better security model to prevent applications from accessing eachother’s data. But the entire reason this is necessary is because you’re essentially running untrusted, user-hostile applications on your device. To me that’s pure madness and a never-ending arms race which, indeed, requires very high levels of security. Besides, many apps ask for way too many permissions (the typical example being a flashlight app requiring access to your contact lists and network access), and a majority of users are happy to just click OK, anyway, because it’s entirely unclear what they are saying OK to.

                    Now, there’s still something to be said for sandboxing even of trusted applications, to prevent them from accessing your data after having been exploited through a vulnerability. For this, I’d love to see something like OpenBSD’s pledge on Linux.

                    I, for one, am very happy that there are new developments outside the Android/iOS duoculture.

                    The non-software parts of the article do make some sense, because we still cannot trust hardware manufacturers, but this just supports my initial point: if you can trust the software (or firmware) not to be actively spying on you, a lot of these security measures are unnecessary. Then, kill switches just become some additional measure to know for a fact that your device isn’t accidentally recording, and to protect against external actors trying to track you via your bluetooth/wifi MAC address.

                    1. 10

                      But the entire reason this is necessary is because you’re essentially running untrusted, user-hostile applications on your device. To me that’s pure madness and a never-ending arms race which, indeed, requires very high levels of security.

                      Applications do not need to be user-hostile to be considered untrusted. They just need not to be formally proven.

                      Once you notice this, you can see the value of mitigation (such as done by openbsd, pledge/unveil/W^X/layout randomization), sandboxing (as done by android, docker) and systems designed for enabling actual least-privilege, which pretty much implies capabilities (not to be confused by POSIX capabilities) and a pure microkernel, multiserver design.

                      This is why Google is working on Fuchsia (as they’ve hit the limits on what can be done with Linux), and Huawei on HarmonyOS.

                      1. 8

                        This is why Google is working on Fuchsia (as they’ve hit the limits on what can be done with Linux), and Huawei on HarmonyOS.

                        I wonder how many of those limits are related to GPL2 more than technical reasons…

                        1. 8

                          If if was about the license, they’d just save effort by reusing bsd/mit license code.

                          1. 3

                            Yes, I suspect porting the Android userland over to a BSD derivative kernel would be a vastly easier task than writing a whole new OS. FreeBSD already has a linux-compatible ABI that supposedly works fairly well, if that’s even necessary.

                        2. 5

                          They just need not to be formally proven.

                          Just insecure. Formally proven apps can be insecure if what’s proven doesn’t block the attack vector. An easy one is formal correctness or memory safety not stopping information leaks from shared resources. Even if software does, the continuous number of hardware-based leaks means verified software is no guarantee.

                          That we probably won’t see them get that under control means anything on complex, insecure hardware must be considered compromised with security measures just limiting damage of this versus that component, attacker, or whatever.

                          Edit: Your other comment mentioned seL4 is proven to do separation. It’s proven to do so under a number of assumptions. Some are false. So, it can’t do separation in those cases.

                          1. 5

                            Just insecure.

                            Right. My intent was to say that a non-formally-proven app should always be assumed insecure, and sandboxed accordingly.

                            Which doesn’t go to say we should disable the sandboxing when the app gets formally proven; We should be sandboxing everything that can be sandboxed. Working with capabilities is the only way I see going forward.

                            1. 4

                              That all sounds much better. Layer by layer, component by component, prevent what we can, and catch the rest. :)

                          2. 3

                            This is why Google is working on Fuchsia (as they’ve hit the limits on what can be done with Linux)

                            Fuchsia smells like a Senior developer retention program to me.

                            Given Google’s focus, even if that project was serious, what’s the change it would still be alive 3 years after shipping?

                            1. 8

                              Fuchsia’s been active for several years now, the android runtime has been running on it for a few years also, and it has been active throughout.

                              I very much doubt that it isn’t the operating system Google plans to use as base for pretty much everything in the not so distant future.

                              1. 2

                                You mean like Google+?

                          3. 6

                            But the entire reason this is necessary is because you’re essentially running untrusted, user-hostile applications on your device.

                            Suppose you’re wrong, just once, and some FOSS developer betrays your trust. Maybe not even that - maybe the download server for one of their dependencies gets trojanised and it’s built into a binary you’re running.

                            Problem 1: If the app wasn’t sandboxed you have now been comprehensively owned. Every secret on your account is now void.
                            Problem 2: There’s no reason you would notice if problem 1 occurs.

                            I too am pleased to see developments outside Android/iOS but I can’t get on board with the notion that we should lower our guard because software hasn’t come from a corporation with corporate interests.

                            1. 3

                              Fair point!

                              Now as far as I can tell, Android is Linux, so it shouldn’t be fundamentally impossible to port the Android security model / sandboxing system to Librem, even though this post seems to imply that Android is somehow completely different from it and inherently more secure.

                              1. 2

                                As far as I can tell, there’s so little “Linux” in Android you really would need to do a lot of hard work to get a similar system running.

                                And all the different little Linux-based phones would have to set aside their differences concerning distros and whatnot and agree on how the kernel should be patched to enable whatever features this new userland requires.

                                Sadly many of these Linux-based phones run old Android kernels because the hardware manufacturers never open-sourced their drivers.

                                It’s a complete world of pain and grief, which no one would invest in because the market leaders are so huge.

                                Despite that I’m still a Sailfish user.

                                1. 2

                                  Sadly many of these Linux-based phones run old Android kernels because the hardware manufacturers never open-sourced their drivers.

                                  Somewhat true. They open sourced their kernel forks, but not the userland drivers.

                            2. 1

                              100% agree on this.

                              I rather use unsandboxed applications from people I trust than sandboxed applications from people I don’t trust. It’s the same for distribution repos vs. Flatpak.

                            3. 9

                              To me, these devices are about the hardware being workable, not about the software.

                              There’s nothing stopping these devices from running Android.

                              But with a friendly such a device at hand, it is possible to work on a decent solution, which ultimately means not based on Linux.

                              Genode is targetting the librem5. I am expecting that a future Genode release will implement a PoC genode+seL4 librem5 build.

                              1. 4

                                Genode is targetting the librem5

                                That’s pretty awesome indeed. This is one of the great benefits of having more open hardware & software, even if you disagree with the entire original manufacturer’s stack.

                              2. 8

                                I’ve just switched to a developer pre-release PinePhone as my daily driver. Not because it’s more secure than Android, but because I want a more powerful general-purpose computer in the form factor of a phone, with LTE connectivity.

                                I don’t want to support Google’s advertising model more than I have to, I don’t want to support Apple’s walled garden at all, and above all I want a hacker-friendly device that I can hack on myself. The PinePhone (currently running Ubuntu Touch) checks all my boxes. I can even keep waiting for the camera drivers to work ;)

                                1. 3

                                  How well does it work as an actual phone? Do calls and SMS work well? It seems like a lot of phone manufacturers have forgotten what exactly the point of a phone is. I’ve heard a lot about how hackable the pinephone is, but not so much about how it stands up as a phone.

                                  1. 5

                                    I’m running the developer pre-release version with a WIP port of Ubuntu Touch; things are expected to be a bit wonky this early in the piece.

                                    That said, SMS works very well, and phone calls work well enough for me to use the PinePhone as my daily driver. Caveats: call quality is “tinny”, and both loudspeaker and Bluetooth headsets are currently non-functional.

                                    I expect call quality will improve as drivers are worked on (the actual sound quality from the speaker is great when playing music), ditto support for in call loudspeaker and Bluetooth.

                                    The main thing that’s bugging me right now is the lack of support for the camera. As soon as that’s functional I can stop using my old Note to take family photos :)

                                    1. 2

                                      That sounds promising - it can be difficult to tell when people say “daily driver” because some people never take calls or whatever, so thanks for letting me clarify!

                                      I’ll have to look into the project a bit more then, although my problem currently is that all my family use Whatsapp to communicate, and whatever my personal views on the matter I quite like being able to talk to them.

                                      Do you have to provide a camera as a separate board?

                                      1. 2

                                        Nope - it has two integrated cameras:

                                        • Main camera: Single 5MP, 1/4″, LED Flash
                                        • Selfie camera: Single 2MP, f/2.8, 1/5″

                                        I must admit, I did double check that after you asked, because it would provide a good explanation of why the camera doesn’t yet work :)

                                        1. 2

                                          Oh and one other thing I remember - the battery life isn’t great right now. Not an issue as I’m working from home during the pandemic, but it’s early days on power management optimisations in the kernel.

                                          Some good news on the battery front: the batteries are removable, and are rebranded Samsung J7 batteries. So you can swap them out, and keep spares charged with an external charger.

                                          1. 2

                                            Looks like it really has come on a lot. I think I’ll continue to watch from the sidelines for the time being, but I’m glad it really is becoming viable.

                                  2. 11

                                    full system MAC policies

                                    Overrated. A phone is not a government server with lots of actual human users with different secret access clearances, why would you need MAC? App isolation can be done in simpler better ways.

                                    verified boot

                                    Not doing it makes user control easier, screw fiddling with signatures :) But an option to have it would be nice.

                                    app sandboxing

                                    Much less necessary when the apps are FOSS from a trusted repo, instead of ad-ridden proprietary store apps. Firefox sandboxes its own content processes pretty well.

                                    Modem isolation isn’t anything special. Qualcomm SoCs have isolated the modem via an IOMMU for years.

                                    Well, I’d trust good old USB way more than Qualcomm’s piles of custom stuff.

                                    1. 14

                                      Much less necessary when the apps are FOSS from a trusted repo, instead of ad-ridden proprietary store apps. Firefox sandboxes its own content processes pretty well.

                                      You are only one Geary, KMail, Evince, or Okular vulnerability away from a full user account compromise. Sandboxing does not only protect against untrusted applications, but also against vulnerabilities in trusted applications. At least the OpenBSD folks understood this and made pledge, etc and introduced it across the base system. But the larger Linux/FLOSS Unix ecosystem does not seem to get this yet.

                                      The reason why the lack of a proper security model isn’t actively exploited yet, is that the Linux desktop is such a small blip on the radar that it is not a worthwhile target yet. But if you want to compete in the smart phone or desktop markets, you should address such issues.

                                      1. 24

                                        I’m certainly not a security professional, and I don’t want to twist your words, however it sounds to me like you’re advocating “security by not making mistakes.” As if it doesn’t matter how technically easy it is to compromise the whole system, because you’re always only running software written by trustworthy people.

                                        I think the main point of the article is that Android and iOS, while certainly laden with junk and corporate interests, do indeed have a better sandboxing and overall security model than traditional desktop / server OSes like Linux. You need an IT professional to set up sandboxing on Linux. But a regular consumer can have sandboxing by default on Android and iOS.

                                        So the author has a good point; I too am somewhat concerned that by discarding Android and iOS, we’re potentially throwing out the baby with the bath water.

                                        1. 2

                                          You need an IT professional to set up sandboxing on Linux.

                                          Most apps run fine with something like firejail. You don’t need to be an “IT professional” (however you quantify that..?) but I agree it’s not straight forward. The tools are there for someone (Purism?) to create something easier for folks to use out of the box.

                                          1. 8

                                            A CPU developer put it better than I could have:

                                            Security must be unobtrusive, unavoidable, and cheap.

                                            Or it won’t get used.

                                            If “most” applications work in Firejail, then most people (including me) won’t bother trying. It has to work with all of the applications that typical people want to try, and the best way to ensure that developers actually test their app with it is if it’s on by default and rarely turned off.

                                            1. 3

                                              the best way to ensure that developers actually test their app with it is if it’s on by default and rarely turned off.

                                              It’s best if security is at the core of the system. This is why investing in systems built around capabilities (not to be confused with POSIX capabilities) from the start is the only path going forward. seL4 is a good core to build such a system around.

                                            2. 6

                                              As someone who has used firejail and bubblewrap, this is a who needs Dropbox, you can do this trivially with curlftpfs comment. There is no way a common user is going to set up firejail. And setting up firejail for them for every (GUI) application is going to be either: meaningless, because you have to expose large parts of a system to make an applications usable; or useless, because your application is contained to such an extend that you cannot open files, pass data between applications, etc. Most of the work in implementing proper sandboxing is in providing mechanisms to securely open files from different places, passing data between applications, etc.

                                              1. 3

                                                Most of the work in implementing proper sandboxing is in providing mechanisms to securely open files from different places, passing data between applications, etc.

                                                This is best achieved in a system that’s designed this way from the get-go. This is what capability-based microkernel multiserver systems such as Genode/seL4 are. Google is no stranger to this, thus Fuchsia. Huawei isn’t sleeping either, thus HarmonyOS.

                                                1. 3

                                                  A capability-based system may be better, but until such a system becomes mainstream, we are better served by good sandboxing in a traditional OS than no sandboxing at all.

                                                  1. 3

                                                    Absolutely.

                                                2. 2

                                                  Well, I never said that firejail was ready for the masses. I was merely pointing out that it’s more approachable than most sandboxing options, and wouldn’t be a stretch for someone/people to make it even more seemless to use.

                                            3. 5

                                              Well, I’d trust good old USB way more than Qualcomm’s piles of custom stuff.

                                              In my experience USB stacks (both OS-level and FW-level) are riddled with security bugs. Not what I’d want to use for modem isolation.

                                              1. 3

                                                And yet, USB (< USB4) has some hardening built-in: for example, no ability for devices to do hostile DMA because that’s all host moderated (the host decides when transfers happen and which memory locations are involved).

                                                1. 2

                                                  But what does it even mean for the host to “decide” something if the USB device can hijack it via another vector and get it to “decide” something else? I’m sure it has some hardening, but I think even the designers of USB would have to agree it is poorly suited to this use case.

                                                  1. 2

                                                    What other vector would that be? Every USB transfer only happens when the host wants it to happen. There just is no way for a device to force a change to memory, and therefore the host behavior.

                                                    1. 2

                                                      Any buffer overflow in the USB stack on the host OS, or any similar error in the USB controller firmware.

                                                      Does the USB controller on the librem 5 have DMA, or is it going through an IOMMU?

                                              2. 2

                                                MAC has nothing to do with multi-users.

                                              3. 5

                                                No system is perfect, and I will choose a vulnerable one over a malicious one, obviously.

                                                1. 2

                                                  Then you should use use GrapheneOS, Replicant or LineageOS on regular hardware. I wouldn’t call them malicious but they are far more secure than PureOS or postmarketOS.

                                                2. 8

                                                  Another FUD piece. Sigh.

                                                  It’s a Major upgrade to Android and iOS. Why?

                                                  Android and iOS are completely designed for and oriented to the handset manufacturers and the service providers interests first and foremost.

                                                  You only feature in Android/iOS design list in the sense they have done whatever they can to stop you complaining to the support lines for the manufacturer or service provider.

                                                  If I buy and carry a device, my primary requirement is…

                                                  I AM (g)ROOT!

                                                  1. 2

                                                    If I buy and carry a device, my primary requirement is…

                                                    I AM (g)ROOT!

                                                    These issues apply to phones as much as they apply to workstations. Linux’s security model is weak.

                                                    But I do agree that having librem’s software stack is better than nothing. Everything has to start somewhere.

                                                    1. 2

                                                      The problem with Android and iOS is it is all about security is for the vendor… not me.

                                                      1. 1

                                                        I do not disagree. Not after the experience of having to mess with magisk in order to pass safetynet on lineageos, in order to be able to run many apps including the one from my bank. On a oneplus.

                                                        The alternative being to use OxygenOS, what oneplus ships with, where it just works, but where the vendor has been caught doing unsightly things before, not to mention shoddy security practices.

                                                  2. 4

                                                    The camera kill switch is no better than some tape.

                                                    I guess I don’t understand this gripe. How could a camera kill switch ever be substantially better than some tape?

                                                    1. 6

                                                      Well it doesn’t leave glue traces on your lens, and when you remove the tape you have to store it somewhere if you want to use it again later, and the tape will eventually get dust on it and stop working. Assuming the kill switch is simple to use and can handle being toggled more than 10 times without breaking it seems like any camera kill switch would be better than some tape. I was confused by that gripe too. Your comment cracked me up, thanks.

                                                    2. 3

                                                      I love how this guy is going like “Linux isn’t secure, because I can elevate arbitrary code execution into full system compromise, provide the user types in their sudo or root password”.

                                                      Well of course you can. This applies equally to all computing systems.

                                                      1. 6

                                                        Well of course you can. This applies equally to all computing systems.

                                                        Not really, no. In many systems, it is not possible to gain privileges, only discard them.

                                                        Try Genode’s Sculpt sometime.

                                                        1. 5

                                                          Does it though? IIRC on Mac OS there are some filesystem locations and executables that you can’t run with sudo, thanks to SIP.

                                                        2. 1

                                                          I don’t care about security. Maybe I’m ignorant.

                                                          1. 3

                                                            You’d be ignorant if you didn’t learn anything about it. I suggest doing your research first, then slipping into apathy and nihilism!