10 ms·

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.

yegortimoshenko 7y ago
Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.
- letstrynvm 7y ago
  I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.
  - yegortimoshenko 7y ago
    Chain of trust does protect you from evil maid attacks. And yes, there can be bugs in application layer, but at least half of all CVEs are memory corruption bugs. These practices do offer a massive reduction in attack surface. You seem to argue it doesn't matter since it doesn't eliminate attack surface completely.
    - letstrynvm 7y ago
      No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way. Librem's security model is that of a Linux box, signed update packages... it's not a panacea against hacks but nor are the buzzwords you mentioned. At least they're trying to eliminate the really dangerous proprietary pieces that constantly provide new vulns.
      - pjmlp 7y ago
        You mean the one that had 68% of CVE exploits reported in 2018 due to memory corruption errors? Source, the Kernel Self Preservation Google's talk at the Linux Kernel Summit 2018.
      - strcat 7y ago
        > No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. This is only one of many privacy and security regressions from moving to a far less secure software stack without anything close to the same level of hardening or work on privacy / security. > If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way. Counting CVEs is not a way to judge security. Qualcomm's SoC hardware, firmware and driver security is the leader among the available options. The huge amount of both internal and external public security research targeting it is a strength rather than a weakness. The lack of attention given to other assorted drivers is not a strength of those drivers but rather reflects their obscurity and lack of hardening / auditing. It's also not the norm in the Linux world to assign a CVE for a security vulnerability when it's fixed. The norm is to fix them silently without trying to obtain a CVE. It's completely bogus to judge security based on counting CVEs for many reasons. Not having public lists of the fixed vulnerabilities with CVEs assigned doesn't mean there aren't a bunch of vulnerabilities being fixed, and it's even worse if the vulnerabilities aren't being found and fixed. Every x86 and ARM device is proprietary and has a massive amount of complex proprietary hardware, firmware and microcode. There is no escaping that for these architectures. The Librem 5 is not an open hardware device and has a proprietary SoC, proprietary Wi-Fi, etc. all with their own proprietary firmware and in some cases entire operating systems (Wi-Fi / Bluetooth, cellular, etc.). The distinction of an OS like PureOS is that they don't ship updates to this firmware but rather leave it vulnerable to all the fixed security issues, because they won't redistribute the proprietary firmware updates. The firmware is still present, but the OS is 'free'. Either way, that firmware is running, and with a bunch of known vulnerabilities if you don't update it. Proprietary hardware and software is also not inherently less private or secure than open source software. These are differences in development model, not privacy or security. You're very mistaken if you think open source software eliminates backdoors / vulnerabilities or even reduces them. It's not how things work out in reality. Open source reduces the barrier to entry for security research, whether it's for good or evil, but it's certainly still possible without it being open source. Either way, the comparison you're making is between proprietary hardware + proprietary firmware + open source OS to proprietary hardware + proprietary firmware (but without updates shipped by the OS) + open source OS. > Librem's security model is that of a Linux box, signed update packages Again, you're mixing hardware and software. The Librem hardware isn't only for PureOS and will be able to run Android. Signed update packages alone are inferior to not only having signed update packages but also verified boot and attestation. GPG also has far too much complexity and attack surface for this, and having online build / signing servers, etc. is a joke. Android is Linux, and the Linux kernel is not a strength but rather the most prominent weakness in Android. A massive monolithic kernel written entirely in a memory unsafe language and entirely responsible for enforcing the low-level privacy/security model is not a strength. That's a major problem which needs to be resolved, not a hole to dig deeper. It's fundamentally not fixable and while a bunch of work on mitigations can help, it's very limited in what can be achieved. Moving to the desktop Linux software stacks also gives up the vast majority of these mitigations and the security model that has been rapidly improved over the years. It gives up having such strict SELinux policies developed as an integral part of the base system, as just one of many things that are lost. This level of security cannot be obtained on a traditional Linux distribution without a well-defined base system that's developed together with lots of holistic systems level privacy and security work. Addressing it in a bunch of separate fragmented projects doesn't work out, and prevents having the same kind of security model and security policies. The way that SELinux is used on Android compared to a distribution like RHEL / Fedora is day and night. It's drastically different and not even comparable at all. The same goes for the deployment of other privacy and security features / models.
  - rst 7y ago
    Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.
    - letstrynvm 7y ago
      That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning. The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.
      - pjmlp 7y ago
        Large majority of Android security exploits are in C and C++ written drivers, hence why with each release the amount of freedom with native code gets further locked down. Android Q has another round of such measures. https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html?m=1 https://android-developers.googleblog.com/2019/05/queue-hard...
        mpol 7y ago
        Those may be security exploits, but the real malware is what gets installed through Google Play.
        maroonedanchor 7y ago
        Hence a Play Store free alternative like GrapheneOS.
        pjmlp 7y ago
        Nothing can be done to prevent stupid users to install everything that shines. Even HNers do curl | sh without thinking twice about it.
- pjmlp 7y ago
  While with each Android interaction, Google locks down the amount of C and C++ code that gets exposed to outside world. https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html?m=1 https://android-developers.googleblog.com/2019/05/queue-hard... As such I have a very hard time believing that Librem with be as secure as modern Android.
  - mbrumlow 7y ago
    There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing. In FOSS initiatives spent ages building fee and and open software, combating proprietary systems and software that they had no control over. All that would be loss just to give it up now that we have moved from PCs to phones.... I for one want control over all the software I run on hardware I own. I am not sure why we are so willing to give that control up simply because the platform changed.
    - opencl 7y ago
      What freedom does PureOS offer that AOSP without Google services lacks?
      - groovybits 7y ago
        I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it. In some facets, AOSP is not a complete and working OS as is. In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out. Additionally, many (that is, 95%) of all Android apps that you would find on the Google Play store do not function properly without Google services (which AOSP does not have). Applications that are built to run on stock AOSP are not the 'Snapchats' or 'Instagrams' of the world. They are typically FOSS projects that are built out of passion, but recieve little funding or corporate support. These shortcomings often carry over to third-party ROMs, such as Lineage. So in my experience, as someone who used to flash a new Android ROM every week, it is not about freedom - its about basic functionality. One could also argue that, since the world operates on all kinds of propietary platforms that aren't available on stock AOSP, so do we also lack the freedom to use AOSP as our daily driver - simply because it often does not interface properly with these propietary platforms. Edits: grammer and clarifications
- chupasaurus 7y ago
  Attestation of what? Software security is inferior in Android (hello leaky API), hardware is untrusted in Librem sinde Day 0. Show me a TPM chip with open firmware or it's a security disaster on my board. Seccomp is a thing. Also, Flatpak is the last thing I would concider to use.
- Reelin 7y ago
  > isn't going to be particularly security-focused: no attestation, no trusted boot This is only true initially, presumably due to time and funding constraints. From the FAQ (https://puri.sm/faq/ https://puri.sm/faq/): > What are your plans for tamper-proofing the Librem 5? > We hope to have a version of PureBoot available for the Librem 5 for users who want to verify it with a Librem Key. We cannot commit to it being available at launch but it’s a goal. A PureBoot description can be found at (https://puri.sm/posts/pureboot-the-high-security-boot-process/ https://puri.sm/posts/pureboot-the-high-security-boot-proces...).
- PyroLagus 7y ago
  I imagine it would be possible to get Genode running on the Librem 5, which would be even more secure than Android. Only you'd be limited in what applications you can run. Still, even on Linux, you can set up SELinux or Apparmor to harden your system as much as possible, run untrusted applications as a different user, compile your own hardened kernel, and so on. It's going to be a less secure system for casual users, but it'll allow power-users to more easily (you can do that on Android as well, but it's more difficult) secure their system as much as they want.
  - strcat 7y ago
    > It's going to be a less secure system for casual users, but it'll allow power-users to more easily (you can do that on Android as well, but it's more difficult) secure their system as much as they want. No, it really won't. Doing substantial privacy and security hardening requires a years of work by a team focused on it and the OS needs to be developed with it in mind. Sure, you can enable SELinux elsewhere, but you won't have anything remotely comparable to the complete, full system SELinux policies developed as part of the Android Open Source Project and deeply integrated into it. You're talking about users doing all this from scratch somehow when there is hardly any interest in it for that ecosystem. There's barely any application sandbox or permission model to speak of and projects like Flatpak are not approaching it in a meaningful way that avoids trusting apps. You're suggesting throwing out having an application security model and all this privacy / security work to reinvent it all from scratch for a new ecosystem without existing applications. It's hard to understand how that makes anything easier. Having the well-defined base OS with verified boot and clear separation between the OS and applications which are sandboxed and offered capabilities via a permission model is crucial. It's not an advantage for security to completely do away with that. It's important to implement each feature / capability in a way that fits into the overall security model. Developers love taking shortcuts and doing this in a lazy / negligent way, and you can see exactly that with how people implement features via the shortest path of depending on app-accessible root instead of doing it properly, even when that's a niche thing.
ocdtrekkie 7y ago
Indeed. I'm tired of each new attempt to fix Android and make it usable and safe. Apps written for Android are written to work with Google's expectations and assume the presence of Google's servers and proprietary APIs, and that's getting worse, not better. Librem is going the right way, and there are a handful of other companies working along the same path. Necunos is another I heard of as well: https://necunos.com/community/ https://necunos.com/community/
- ForHackernews 7y ago
  Also https://postmarketos.org/blog/2017/05/26/intro/ https://postmarketos.org/blog/2017/05/26/intro/ - "Aiming for a 10 year life-cycle for smartphones" using mainline Linux kernels.
  - ocdtrekkie 7y ago
    Yeah, and pmOS adds an interesting angle that they're adding legacy Android hardware to these companies' work on their own hardware, all running real Linux. Note that Necunos' phone could actually be bought with pmOS preloaded as well, so you can really start to see how a few of these different projects are starting to work together and build on each other. Hopefully we can have a truly FOSS mobile ecosystem in the next couple of years.
    - juliangoldsmith 7y ago
      pmOS should support the Librem 5 when it comes out, as well. We have several contributors working on them.
yorwba 7y ago
> Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it. Have you checked whether there's a LineageOS build for your device? https://wiki.lineageos.org/devices/#samsung https://wiki.lineageos.org/devices/#samsung (Darker links indicate a build is maintained and available.)
- kbenson 7y ago
  Unfortunately, based on how the devices are supported by volunteer work, supported hardware has large gaps. My Samsung galaxy S6 (march 2018 patch level) wasn't supported the last few times I checked, but older galaxy models were.
- dingaling 7y ago
  Lineage are quite aggressive in dropping older hardware since they pivoted towards 'experience'. My 2013 Galaxy S4 is no longer supported.
markstos 7y ago
I hope Librem remains viable. As someone who needs some specific apps for work, I won't be able to switch for practical considerations unless those services work well enough on the device. For example, Slack. I could carry a second device for personal use, but am unlikely to.
- ocdtrekkie 7y ago
  Specific app needs have killed dozens of potential third party mobile OSes. I suspect that PWAs may finally help with that.
- wowtip 7y ago
  Exactly. How much I like the idea of a truly open phone platform there are some obstacles: - Decent hardware available at competitive price -- While I could make do with some degraded performance for a truly open phone concept, most people would not, especially if price point is similar to, or higher, than established closed platform brands - Must have apps available - needed for wide acceptance -- My personal examples of must have apps: -- BankID (Swedish e-id, needed for banks, taxes, government sites, payments) -- Swish - Swedish app for personal micro transactions -- Public transportation apps (tickets/timetable) -- Bank application -- Signal Without these apps, a open platform phone would be next to useless to me. And I am a big proponent of open platforms. And looking at how reluctant BankID were to even support older version android phones, I am not optimistic to them adding a completely new platform to support. I know people who were forced to upgrade from "old" phones because BankID no longer supported their Android version, and phones would not get newer Android version.
vasili111 7y ago
The big problem is the price which too high.
- chupasaurus 7y ago
  R&D and a small batch size are the only reasons.
  - vasili111 7y ago
    I am not blaming them for that, I understand that but I understand also customer who does not pay twice as more as for other phone.
strcat 7y ago
> with completely Open pieces AOSP is completely open source. Hardware and firmware is a much different story, but that applies to the device you're promoting just as much... > They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it. What's the relevance? It's also quite important to note that the Android patch level includes firmware. Purism doesn'tship firmware updates in PureOS as part of it being 'pure', so you would be stuck with the equivalent of an ancient patch level at least with the stock OS. You're also no less dependent on the companies releasing firmware updates. You're also bringing up hardware as an alternative to an OS that would run on the hardware that you're talking about. It's hard to understand the point. The Librem 5 will be a hardware target for GrapheneOS to consider. It will be missing many of the core hardware security and robustness features, so it couldn't be a tier 1 target, but it could still be unofficially or even officially supported. If it doesn't depend on any out-of-tree kernel drivers, that will apply to Android and GrapheneOS too. I'm not sure why you're bringing it up as something distinct.
- deleted 7y ago
  [deleted]
- cyphar 7y ago
  > AOSP is completely open source. This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements. I use LineageOS (and have for a while), which is mostly AOSP, and the applications from AOSP today feel older than the ones I used on Google's Android ~5 years ago. As a simple example, Google's Calendar application can create very complicated recurring events while the AOSP one is much dumber. > Hardware and firmware is a much different story, but that applies to the device you're promoting just as much... The Librem 5 hardware was specifically chosen so that it contains no firmware blobs and all the firmware is free software and upstream in Linux. There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial).
nerd7473 7y ago
I'm really excited for it. I also have my eyes on the Pine phone project.
deleted 7y ago
[deleted]
jammygit 7y ago
I don’t fully understand why it was not easier to build a fork of aosp, but it is exciting at least
Tepix 7y ago
What's wrong with AOSP? It's fully open source, supported by a huge amount of phones and has a snappy UI. The only other open source UI that has managed that so far is Sailfish OS. Just dump all the proprietary Google add-ons and enjoy the F-Droid app store. You will have amazing battery life, less detractions, less ads and a lot more security and privacy. I enjoyed this with CopperheadOS (the GrapheneOS predecessor) on a Nexus 5X until the project folded. Google stopped supporting the Nexus 5X with updates a few months later.

yegortimoshenko 7y ago

Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.

letstrynvm 7y ago
I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.
- yegortimoshenko 7y ago
  Chain of trust does protect you from evil maid attacks. And yes, there can be bugs in application layer, but at least half of all CVEs are memory corruption bugs. These practices do offer a massive reduction in attack surface. You seem to argue it doesn't matter since it doesn't eliminate attack surface completely.
  - letstrynvm 7y ago
    No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way. Librem's security model is that of a Linux box, signed update packages... it's not a panacea against hacks but nor are the buzzwords you mentioned. At least they're trying to eliminate the really dangerous proprietary pieces that constantly provide new vulns.
    - pjmlp 7y ago
      You mean the one that had 68% of CVE exploits reported in 2018 due to memory corruption errors? Source, the Kernel Self Preservation Google's talk at the Linux Kernel Summit 2018.
    - strcat 7y ago
      > No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability. This is only one of many privacy and security regressions from moving to a far less secure software stack without anything close to the same level of hardening or work on privacy / security. > If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way. Counting CVEs is not a way to judge security. Qualcomm's SoC hardware, firmware and driver security is the leader among the available options. The huge amount of both internal and external public security research targeting it is a strength rather than a weakness. The lack of attention given to other assorted drivers is not a strength of those drivers but rather reflects their obscurity and lack of hardening / auditing. It's also not the norm in the Linux world to assign a CVE for a security vulnerability when it's fixed. The norm is to fix them silently without trying to obtain a CVE. It's completely bogus to judge security based on counting CVEs for many reasons. Not having public lists of the fixed vulnerabilities with CVEs assigned doesn't mean there aren't a bunch of vulnerabilities being fixed, and it's even worse if the vulnerabilities aren't being found and fixed. Every x86 and ARM device is proprietary and has a massive amount of complex proprietary hardware, firmware and microcode. There is no escaping that for these architectures. The Librem 5 is not an open hardware device and has a proprietary SoC, proprietary Wi-Fi, etc. all with their own proprietary firmware and in some cases entire operating systems (Wi-Fi / Bluetooth, cellular, etc.). The distinction of an OS like PureOS is that they don't ship updates to this firmware but rather leave it vulnerable to all the fixed security issues, because they won't redistribute the proprietary firmware updates. The firmware is still present, but the OS is 'free'. Either way, that firmware is running, and with a bunch of known vulnerabilities if you don't update it. Proprietary hardware and software is also not inherently less private or secure than open source software. These are differences in development model, not privacy or security. You're very mistaken if you think open source software eliminates backdoors / vulnerabilities or even reduces them. It's not how things work out in reality. Open source reduces the barrier to entry for security research, whether it's for good or evil, but it's certainly still possible without it being open source. Either way, the comparison you're making is between proprietary hardware + proprietary firmware + open source OS to proprietary hardware + proprietary firmware (but without updates shipped by the OS) + open source OS. > Librem's security model is that of a Linux box, signed update packages Again, you're mixing hardware and software. The Librem hardware isn't only for PureOS and will be able to run Android. Signed update packages alone are inferior to not only having signed update packages but also verified boot and attestation. GPG also has far too much complexity and attack surface for this, and having online build / signing servers, etc. is a joke. Android is Linux, and the Linux kernel is not a strength but rather the most prominent weakness in Android. A massive monolithic kernel written entirely in a memory unsafe language and entirely responsible for enforcing the low-level privacy/security model is not a strength. That's a major problem which needs to be resolved, not a hole to dig deeper. It's fundamentally not fixable and while a bunch of work on mitigations can help, it's very limited in what can be achieved. Moving to the desktop Linux software stacks also gives up the vast majority of these mitigations and the security model that has been rapidly improved over the years. It gives up having such strict SELinux policies developed as an integral part of the base system, as just one of many things that are lost. This level of security cannot be obtained on a traditional Linux distribution without a well-defined base system that's developed together with lots of holistic systems level privacy and security work. Addressing it in a bunch of separate fragmented projects doesn't work out, and prevents having the same kind of security model and security policies. The way that SELinux is used on Android compared to a distribution like RHEL / Fedora is day and night. It's drastically different and not even comparable at all. The same goes for the deployment of other privacy and security features / models.
- rst 7y ago
  Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.
  - letstrynvm 7y ago
    That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning. The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.
    - pjmlp 7y ago
      Large majority of Android security exploits are in C and C++ written drivers, hence why with each release the amount of freedom with native code gets further locked down. Android Q has another round of such measures. https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html?m=1 https://android-developers.googleblog.com/2019/05/queue-hard...
      - mpol 7y ago
        Those may be security exploits, but the real malware is what gets installed through Google Play.
        maroonedanchor 7y ago
        Hence a Play Store free alternative like GrapheneOS.
        pjmlp 7y ago
        Nothing can be done to prevent stupid users to install everything that shines. Even HNers do curl | sh without thinking twice about it.
pjmlp 7y ago
While with each Android interaction, Google locks down the amount of C and C++ code that gets exposed to outside world. https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html?m=1 https://android-developers.googleblog.com/2019/05/queue-hard... As such I have a very hard time believing that Librem with be as secure as modern Android.
- mbrumlow 7y ago
  There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing. In FOSS initiatives spent ages building fee and and open software, combating proprietary systems and software that they had no control over. All that would be loss just to give it up now that we have moved from PCs to phones.... I for one want control over all the software I run on hardware I own. I am not sure why we are so willing to give that control up simply because the platform changed.
  - opencl 7y ago
    What freedom does PureOS offer that AOSP without Google services lacks?
    - groovybits 7y ago
      I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it. In some facets, AOSP is not a complete and working OS as is. In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out. Additionally, many (that is, 95%) of all Android apps that you would find on the Google Play store do not function properly without Google services (which AOSP does not have). Applications that are built to run on stock AOSP are not the 'Snapchats' or 'Instagrams' of the world. They are typically FOSS projects that are built out of passion, but recieve little funding or corporate support. These shortcomings often carry over to third-party ROMs, such as Lineage. So in my experience, as someone who used to flash a new Android ROM every week, it is not about freedom - its about basic functionality. One could also argue that, since the world operates on all kinds of propietary platforms that aren't available on stock AOSP, so do we also lack the freedom to use AOSP as our daily driver - simply because it often does not interface properly with these propietary platforms. Edits: grammer and clarifications
chupasaurus 7y ago
Attestation of what? Software security is inferior in Android (hello leaky API), hardware is untrusted in Librem sinde Day 0. Show me a TPM chip with open firmware or it's a security disaster on my board. Seccomp is a thing. Also, Flatpak is the last thing I would concider to use.
Reelin 7y ago
> isn't going to be particularly security-focused: no attestation, no trusted boot This is only true initially, presumably due to time and funding constraints. From the FAQ (https://puri.sm/faq/ https://puri.sm/faq/): > What are your plans for tamper-proofing the Librem 5? > We hope to have a version of PureBoot available for the Librem 5 for users who want to verify it with a Librem Key. We cannot commit to it being available at launch but it’s a goal. A PureBoot description can be found at (https://puri.sm/posts/pureboot-the-high-security-boot-process/ https://puri.sm/posts/pureboot-the-high-security-boot-proces...).
PyroLagus 7y ago
I imagine it would be possible to get Genode running on the Librem 5, which would be even more secure than Android. Only you'd be limited in what applications you can run. Still, even on Linux, you can set up SELinux or Apparmor to harden your system as much as possible, run untrusted applications as a different user, compile your own hardened kernel, and so on. It's going to be a less secure system for casual users, but it'll allow power-users to more easily (you can do that on Android as well, but it's more difficult) secure their system as much as they want.
- strcat 7y ago
  > It's going to be a less secure system for casual users, but it'll allow power-users to more easily (you can do that on Android as well, but it's more difficult) secure their system as much as they want. No, it really won't. Doing substantial privacy and security hardening requires a years of work by a team focused on it and the OS needs to be developed with it in mind. Sure, you can enable SELinux elsewhere, but you won't have anything remotely comparable to the complete, full system SELinux policies developed as part of the Android Open Source Project and deeply integrated into it. You're talking about users doing all this from scratch somehow when there is hardly any interest in it for that ecosystem. There's barely any application sandbox or permission model to speak of and projects like Flatpak are not approaching it in a meaningful way that avoids trusting apps. You're suggesting throwing out having an application security model and all this privacy / security work to reinvent it all from scratch for a new ecosystem without existing applications. It's hard to understand how that makes anything easier. Having the well-defined base OS with verified boot and clear separation between the OS and applications which are sandboxed and offered capabilities via a permission model is crucial. It's not an advantage for security to completely do away with that. It's important to implement each feature / capability in a way that fits into the overall security model. Developers love taking shortcuts and doing this in a lazy / negligent way, and you can see exactly that with how people implement features via the shortest path of depending on app-accessible root instead of doing it properly, even when that's a niche thing.

ocdtrekkie 7y ago

Indeed. I'm tired of each new attempt to fix Android and make it usable and safe. Apps written for Android are written to work with Google's expectations and assume the presence of Google's servers and proprietary APIs, and that's getting worse, not better. Librem is going the right way, and there are a handful of other companies working along the same path. Necunos is another I heard of as well: https://necunos.com/community/ https://necunos.com/community/

ForHackernews 7y ago
Also https://postmarketos.org/blog/2017/05/26/intro/ https://postmarketos.org/blog/2017/05/26/intro/ - "Aiming for a 10 year life-cycle for smartphones" using mainline Linux kernels.
- ocdtrekkie 7y ago
  Yeah, and pmOS adds an interesting angle that they're adding legacy Android hardware to these companies' work on their own hardware, all running real Linux. Note that Necunos' phone could actually be bought with pmOS preloaded as well, so you can really start to see how a few of these different projects are starting to work together and build on each other. Hopefully we can have a truly FOSS mobile ecosystem in the next couple of years.
  - juliangoldsmith 7y ago
    pmOS should support the Librem 5 when it comes out, as well. We have several contributors working on them.

yorwba 7y ago

> Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it. Have you checked whether there's a LineageOS build for your device? https://wiki.lineageos.org/devices/#samsung https://wiki.lineageos.org/devices/#samsung (Darker links indicate a build is maintained and available.)

kbenson 7y ago
Unfortunately, based on how the devices are supported by volunteer work, supported hardware has large gaps. My Samsung galaxy S6 (march 2018 patch level) wasn't supported the last few times I checked, but older galaxy models were.
dingaling 7y ago
Lineage are quite aggressive in dropping older hardware since they pivoted towards 'experience'. My 2013 Galaxy S4 is no longer supported.

markstos 7y ago

I hope Librem remains viable. As someone who needs some specific apps for work, I won't be able to switch for practical considerations unless those services work well enough on the device. For example, Slack. I could carry a second device for personal use, but am unlikely to.

ocdtrekkie 7y ago
Specific app needs have killed dozens of potential third party mobile OSes. I suspect that PWAs may finally help with that.
wowtip 7y ago
Exactly. How much I like the idea of a truly open phone platform there are some obstacles: - Decent hardware available at competitive price -- While I could make do with some degraded performance for a truly open phone concept, most people would not, especially if price point is similar to, or higher, than established closed platform brands - Must have apps available - needed for wide acceptance -- My personal examples of must have apps: -- BankID (Swedish e-id, needed for banks, taxes, government sites, payments) -- Swish - Swedish app for personal micro transactions -- Public transportation apps (tickets/timetable) -- Bank application -- Signal Without these apps, a open platform phone would be next to useless to me. And I am a big proponent of open platforms. And looking at how reluctant BankID were to even support older version android phones, I am not optimistic to them adding a completely new platform to support. I know people who were forced to upgrade from "old" phones because BankID no longer supported their Android version, and phones would not get newer Android version.

vasili111 7y ago

The big problem is the price which too high.

chupasaurus 7y ago
R&D and a small batch size are the only reasons.
- vasili111 7y ago
  I am not blaming them for that, I understand that but I understand also customer who does not pay twice as more as for other phone.

strcat 7y ago

> with completely Open pieces AOSP is completely open source. Hardware and firmware is a much different story, but that applies to the device you're promoting just as much... > They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it. What's the relevance? It's also quite important to note that the Android patch level includes firmware. Purism doesn'tship firmware updates in PureOS as part of it being 'pure', so you would be stuck with the equivalent of an ancient patch level at least with the stock OS. You're also no less dependent on the companies releasing firmware updates. You're also bringing up hardware as an alternative to an OS that would run on the hardware that you're talking about. It's hard to understand the point. The Librem 5 will be a hardware target for GrapheneOS to consider. It will be missing many of the core hardware security and robustness features, so it couldn't be a tier 1 target, but it could still be unofficially or even officially supported. If it doesn't depend on any out-of-tree kernel drivers, that will apply to Android and GrapheneOS too. I'm not sure why you're bringing it up as something distinct.

deleted 7y ago
[deleted]
cyphar 7y ago
> AOSP is completely open source. This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements. I use LineageOS (and have for a while), which is mostly AOSP, and the applications from AOSP today feel older than the ones I used on Google's Android ~5 years ago. As a simple example, Google's Calendar application can create very complicated recurring events while the AOSP one is much dumber. > Hardware and firmware is a much different story, but that applies to the device you're promoting just as much... The Librem 5 hardware was specifically chosen so that it contains no firmware blobs and all the firmware is free software and upstream in Linux. There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial).

nerd7473 7y ago

I'm really excited for it. I also have my eyes on the Pine phone project.

deleted 7y ago

[deleted]

jammygit 7y ago

I don’t fully understand why it was not easier to build a fork of aosp, but it is exciting at least

Tepix 7y ago

What's wrong with AOSP? It's fully open source, supported by a huge amount of phones and has a snappy UI. The only other open source UI that has managed that so far is Sailfish OS. Just dump all the proprietary Google add-ons and enjoy the F-Droid app store. You will have amazing battery life, less detractions, less ads and a lot more security and privacy. I enjoyed this with CopperheadOS (the GrapheneOS predecessor) on a Nexus 5X until the project folded. Google stopped supporting the Nexus 5X with updates a few months later.