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.
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.
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).
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.
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.
This is only true initially, presumably due to time and funding constraints. From the 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-proces...).
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.
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/
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.
Have you checked whether there's a LineageOS build for your device? https://wiki.lineageos.org/devices/#samsung (Darker links indicate a build is maintained and available.)
My Samsung galaxy S6 (march 2018 patch level) wasn't supported the last few times I checked, but older galaxy models were.
I could carry a second device for personal use, but am unlikely to.
- 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.
It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).
What happened with CopperheadOS was unfortunate [2]. I hope Daniel [3] is able to work on GrapheneOS on his own terms [4]. The work that was done had garnered a lot of following and there's hope, given his exploits in the past, that he'd be able to steer this non-profit to heights where industry leaders building SilentCircle [5] and CyanogenMod failed.
Sure will be following the project from afar and routing for its success.
Good luck Daniel.
[0] https://www.reddit.com/r/CopperheadOS/comments/8qdnn3/goodby...
[1] https://news.ycombinator.com/item?id=9551937#9552769
[2] https://news.ycombinator.com/item?id=17289536
[3] https://news.ycombinator.com/user?id=strcat
And there's also a useful incremental path for evolution, that starts with a familiar GNU/Linux and moves gradually towards handheld tweaks (UI, power, devices, apps).
It's important to be upfront that PostmarketOS is not yet viable as a daily driver, or people will feel they wasted their time looking at it. What it really needs is programmers, like the earlier Linux ones, who will power through the pain of getting things working well, and stick with it for months, as a labor of love.
> Details on the roadmap of the project will be posted on the site in the near future. In the long term, it aims to move beyond a hardened fork of the Android Open Source Project. Achieving the goals requires moving away from relying the Linux kernel as the core of the OS and foundation of the security model. It needs to move towards a microkernel-based model with a Linux compatibility layer, with many stepping stones leading towards that goal including adopting virtualization-based isolation.
So in order to get that is more secure and more independent from Google I have to buy a Google phone?
You can buy a contactless smartcard for $15 each and install this on it https://github.com/tsenger/CCU2F
Android can give you privacy and enough security for most people. This can't add much more as long as its running on the same devices.
This is a great effort and I support it, but let's not imagine this will make our phones that much more secure.
This would work in China though, since they don't have the Play Store in the first place.
Lastly, I wonder how this will do over time considering Fuschia.
GrapheneOS includes sub-projects including standalone projects like https://github.com/GrapheneOS/Auditor and https://github.com/GrapheneOS/hardened_malloc that are portable to other operating systems. This also applies to a lot of work that's under active development and not yet published as part of the stable releases.
It intentionally doesn't stick to the Compatibility Definition Document / Compatibility Test Suite requirements required to be Android, so it can't be referred to as Android, but rather it's an OS with Android app compatibility. It preserves what's actually needed for compatibility in practice, while not being strictly bound by those requirements. The intentional deviations from these are documented, and there are a bunch of them.
> Lastly, I wonder how this will do over time considering Fuschia.
If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.
Fair enough though.
>If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.
I see.
Microg is a (very welcome!) band-aid for the fact that the android ecosystem is critically dependent on a proprietary piece of software called play services.
PMO is a different, libre, OS and ecosystem that doesn't have that problem to begin with since it is truly a Linux (as opposed to AOSP) and truly free (as opposed to android's "can read most code but Google holds all the cards")
Having a massive monolithic kernel at the core of the operating system written entirely in a memory unsafe language is obviously a huge problem, and will need to be addressed over the long term. It's an increasingly blatant weakness, and the enormous amount of ongoing work that has gone into userspace doesn't translate well to the kernel. Developing increasingly more sophisticated mitigations helps a bit, but it can't solve the fundamental issues with the choice of language, architecture or development process. Linux ultimately isn't a viable choice for creating a system with decent security. However, Linux compatibility is part of Android compatibility and is essential. That means the Linux kernel either has to be kept around in virtual machines or replaced with a compatibility layer on top of a microkernel. https://github.com/google/gvisor is an existing project which could be ported to arm64, expanded as needed and adjusted to run on top of another kernel but it doesn't need to be the starting point. It's usually a good idea to start from an existing base like this and try to land everything needed upstream though, rather than burning far more resources starting from scratch and losing out on the shared benefits from collaboration with a larger community.
Using virtualization is a nearer term goal, with a compatibility layer as a much longer term aspiration. There's not much written about the roadmap on the linked page, but this stuff is actually mentioned, and I'd recommend checking it out before wrongly assuming that the goal is simply having a hardened fork of AOSP. There has already been substantial work on experimenting with integrating virtualization for app containment, although containing user profiles would be another approach and potentially more useful.
https://web.archive.org/web/20111130031013/http://www.ok-lab...
CompSci folks have been doing it, too. Here's a paper describing the design style:
https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
Genode OS Framework is only one I know building something like this in FOSS. The rest, esp used in phones, were commercial. One might port Android to something like it or seL4 with dynamic, resource management. Rewrite drivers or anything that's moved to kernel mode for performance in safe language or lots of verification tooling thrown at it.
Stop spreading FUD. In this conversation we are talking about phones filled with bloatware that spies on the user in every instant and you nitpick about memory safety in the kernel.
I had summarized public information and questions from as the implosion was happening, trying to be impartial and not voice my guesses as to what actually went on, and concluded that everyone should be given the benefit of the doubt, given all the unknowns.
But that impartiality could be upsetting to one of the parties (by bringing up things that, say, a good guy maybe can't talk about), and maybe this isn't the time, as people are recovering and moving forward.
At the same time, HN people might need to know some lessons from this noteworthy incident in development and privacy&security, since it should inform how we think about how other projects and startups can fail.
For example: a prominent security product can suddenly be compromised (e.g., in the sense of trusted security update mechanism broken, or a change in who controls updates), or a business partner can force out you and your intentions/stewardship of the product that you think depends on you being in the loop to not be evil, or a different business partner can delete very important keys, or (vaguely) this is another way it can be difficult to reconcile privacy&security goals with business ones.
These failures might be things we briefly consider as hypotheticals when planning or evaluating, but they do happen, in real life, on prominent efforts.
It's probably not wise to post this, since I never talk about it publicly, he might not like it, and this thread should be about GrapheneOS, not Rust or myself. But with the mention of his Rust involvement and the history of CopperheadOS, I feel compelled at the moment to add some context and give him props.
He is an exceptionally skilled developer.
Some of his contributions to Rust were crucial. Of particular note, he re-designed Rust iterators to their current form. But he added to Rust so much more, both with his ideas and code.
And from what I recall he was in high school at the time. Amazing.
I happened to be the Rust team lead during much of his time contributing to the project, and a good deal of the blame for his departure belongs to me. It was a difficult learning experience for everyone.
It is totally fair to say that Rust would not be what it is today, both technically and socially, without him.
I was happy to see him rebound with CopperheadOS, and again here with GrapheneOS.
Good luck, Daniel.
(edited to remove some Rust cheerleading)
I wanted him to stay a little more around the Rust 1.0 era because I thought as many warts as possible should have been fixed before the backward compatibility guarantee was made, but he left too early.
Didn't know about the CopperheadOS incident, too bad such a situation happened to him. Good to see it's kinda resolved now.
It seemed like he got royally screwed just given the amount of time and effort he put into the project, easily shown just from his activity and responses during its life cycle.
I find it interesting that people bring up my time contributing to Rust as a negative thing, largely due to my former business partner misrepresenting it and falsely claiming I was kicked out of the project. To be clear, I don't think you're doing it maliciously, but it's quite weird that contributing so much of my time to an open source project and then having that used against me as if working on a set of open source projects nearly full time for a year as a volunteer was a terrible thing to do. It's a large part of why I now avoid doing work without compensation. If people are going to value my work so little, then I'm at least going to get paid for it.
I left Rust on my own accord because I wasn't enjoying it anymore and I'd determined that it was extremely unlikely that it would turn into a career which is part of why I'd persisted long past the point that I was enjoying it. It became harder and harder to accomplish anything of substantial value as it moved towards stability. I had strong opinions on many of the topics and to get anything done as an outsider I had to make strong arguments and be incredibly persistent, which rubbed some people the wrong way. It was also very rough at that time being an outsider and trying to have a significant influence on it, especially when I disagreed in many areas with the core developers. The way things were done drastically changed later on for the better. I left the project for the same reason a few people didn't like my involvement in it. I was getting burned out dealing with them and they were getting burned out dealing with me. It certainly went both ways and the vast majority of the people involved in the project didn't have issues with me. Out of thousands of people, there were only a couple that I truly didn't get along with and literally only one person where that persists today (and believe me, I'm not the only person who doesn't click with them).
I've certainly evolved how I communicate with people online since then. I still take serious issue with people bending the truth and being dishonest / misleading, which can make arguments very heated if people aren't trying to debate based on the facts. There's a tiny minority of people that I absolutely don't get along with because they'll keep bending the truth and I'll keep pointing out that they're doing it, which they can interpret as an insult. In the context of a debate over the design of a project where the stakes are high, I'll choose not to be very diplomatic when the alternative is letting someone walk all over me with false claims. It's too tiring refuting things over and over and having facts treated as subjective things rather than being able to agree upon a set of facts and argue things based on their merits. I think the world would be a better place if people didn't tolerate this so much. I was no good at playing politics and choosing my battles carefully which played a big part in it too.
The objective truth is that I decided to leave the Rust project and community, and I removed myself as a contributor from the repository. If I recall correctly, I think someone misinterpreted what happened and posted a thread on /r/rust incredibly angry because they thought I was kicked out of the project. The people who saw the thread but weren't aware of the details assumed that it actually happened and then had a massive fight with each other about whether something that didn't happen was justified or not. The reality is that it didn't happen in the first place.
I also seriously doubt that I would be kicked out of any project for occasionally being a bit abrasive in arguments. It would be a bit ridiculous for a project to ban people from contributing for having that kind of personality or not being neurotypical. It's possible that they would have asked me to start being less abrasive in debates, sure, but they hadn't. I definitely don't think I was always fun to work with, particularly once things had soured with Mozilla, but I don't think it's entirely fair to put all the blame on me for that. I was upset about what had happened overall and that definitely influenced how I participated.
My experiences with Rust and other projects are what led to me making sure that I'd own and control the projects that I'd be heavily working on in the future so I wouldn't need to spend so much of my time debating and playing politics. When I co-founded Copperhead, I made sure that it was explicitly agreed that my open source work would remain under my control despite the company sponsoring it. It was explicit that I would own and control the OS development project. It's worth noting that there were 3 co-founders, and 2 of us believed in open source and the company building value around it rather than by selling it. Unfortunately, the 3rd co-founder left early on before shares were even divided up, and I ended up owning the company 50/50 with a narcissistic sociopath who ended up totally screwing me over. Internally, there was conflict and dysfunction long before it became public. I wanted to be free of that company for a long time, but I couldn't leave because I couldn't just abandon the people using the project and it had become too tied to the company. Eventually, my business partner decided to throw away all the agreements and just try to take over the project with threats / ultimatums. I don't think it was at all rational for him to do that. It wasn't at all in his best interest even from an entirely selfish point of view. There's absolutely no way I was going to turn over ownership / control of my project to someone that by then I considered highly untrustworthy and downright dangerous. Unfortunately, they had set up everything to be able to completely screw with over by tricking me at various points and being very strategic about how the domain, infrastructure, etc. was set up. It ended up not mattering at all that I owned 50% of the shares because they just ignored my rights as a shareholder and banked on me not wanting to spend a huge amount of money fighting them in court.
GrapheneOS is the direct continuation of my work on this, which began before Copperhead became involved in it. It had existed before it was CopperheadOS. I've learned a lot of lessons from the experience there. One of the biggest mistakes was being tricked into not being a director early on, but that was also before the stakes had become so high. It also really shouldn't have mattered to the extent that it did if the Copperhead lawyer had been at all competent and truly looked after the interest of the company instead of acting solely on behalf of my business partner. Anyway, I'd rather not be directly involved in businesses at all. I've had almost nothing but bad experiences with governments, businesses, etc. including things far worse than the stuff with Copperhead.
Essentially, the goal for the project is for it to be an OS compatible with Android apps, using the Android Open Source Project software stack to run them, but the underlying base can become whatever is most suited to the task. For now, the most practical approach is using virtualization to reinforce the app sandbox and user profiles. Eventually, the virtual machines can drop having their own Linux kernels (see gVisor as an example of this). In the very long term, the Linux kernel at the core of the OS could eventually go away too.
I'd recommend checking out the standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor for an idea of what the project is focused on doing. The hardened_malloc implementation supports other operating systems, as does Auditor, which supports verifying the stock OS on many mobile devices (they need to be added one-by-one to the internal database based on users submitting attestation samples with the app) and CalyxOS in addition to GrapheneOS.
The OS project itself is still in the early stage of reviving it, porting over past work and getting the basics done. It's very focused on the infrastructure and low-level work right now. Working on the higher level features that are more user facing and bundling various apps, etc. is not a priority right now. It doesn't even bundle F-Droid right now, because it's not quite at the point where bundling any third party apps makes sense. It also needs to be determined how to best approach that. A lot of these things will also be done in collaboration with other projects like CalyxOS, with GrapheneOS focusing more on low-level security hardening. CalyxOS is primarily working on areas like the backup service implementation and various other higher-level services, and a lot of this will be used by GrapheneOS too.
A micro-kernel, with a linux virtualization layer, being abble to run Linux executables as if they were native.
My hunch is that in the long term, Google will probably use Zircon as the 'first-level' kernel, and run the android apps using some emulation layer.
Maybe it could be the answer for what you are trying to accomplish, without having to create a whole micro-kernel OS from scratch, while at the same time benefiting from whats already there.
I bet that with such a thing in place, the Linux kernel could totally go away, with only a emulation layer in place if you want to.
A PC with UEFI (except for a few of those which Microsoft locked down) lets you turnoff secure boot, and install your own keys, and turn it back on. So you actively delete the stock keys that boot stock Microsoft/Ubuntu/Redhat, and then custom sign your Grub bootloader or UEFI-Stub Kernel, add that cert to SecureBoot and turn it back on.
You can argue device security all day long, but if manufactures can't update Android security patch sets as they come out, then you have gaps in your device security anyway.
Google controls ASOP. They could literally force manufactures to be compliant, have UEFI or devicetree as a standard, demand every device allow a stock reinstall just like Windows and even create shims to fix the broken Linux driver ABI. But there is more money in planned obsolescence. Gotta throw out that phone after two years and just buy a new one.
Yes, people find it ironic, but that's how it is. Google's hardware is always better than competition for security: not just in phones, but also look at chromebooks. However, not running proprietary google software is left as an exercise for the reader.
See https://grapheneos.org/#early-stage-of-development and https://grapheneos.org/#device-support. There's barely any content on the site, since it's so new, but this is covered pretty well. It does support other devices already. There's a difference between that and deciding to do all the work to provide official releases with seamless over-the-air updates covering all firmware, etc. along with porting all device-specific hardening work.
> So in order to get that is more secure and more independent from Google I have to buy a Google phone?
The goal is primarily implementing privacy and security improvements. It doesn't include Google services for privacy reasons, but that's not the purpose of the project. A project aiming to project AOSP with the baseline privacy/security intact and work to fill in gaps left by not having Play Services would be useful, but that's a tiny subset of what GrapheneOS is about. It's primarily about the privacy/security research and development work.
You can see that the GrapheneOS Auditor project supports a large range of devices already:
https://attestation.app/about#device-support
That's because it's quite easy to add support for each device one-by-one once users submit attestation samples with the app. The main list is for devices with the stock OS. It also supports CalyxOS and GrapheneOS on all their supported devices and will happily include other operating systems with verified boot and the security model intact. There are now a bunch of devices supporting verified boot with alternate operating systems.
The obvious way to get a phone not running T-Mobile spyware is to not buy a phone from T-Mobile.
Not trying to be snarky here, I have one of these phones too. Though if you happen to have a T-Mobile Oneplus phone like I do it is possible to flash the international ROM and replace the T-Mobile spyware with Chinese spyware.
Components with DMA can be contained by IOMMU, and that's the industry standard today. However, you seem to be implying that backdoors are being inserted into non-CPU SoC components, and it's very hard to understand the threat model you're applying to this. Why would there even be a backdoor inserted into an SoC component like the image processor, which is contained by the IOMMU, rather than the CPU? These SoC components aren't third party components. They're on the same die as the CPU and come with it. That doesn't mean they can freely access all memory... but it does mean that supply chain attacks targeting them would generally be able to target the CPU instead.
If a hardware component is compromised, an attacker would target the driver and gain code execution in the Linux kernel via an exploit. The Linux kernel is a weak target (monolithic - no internal security boundaries, fully written in a memory unsafe language) and drivers are rarely well hardened against attacks from hardware since developers have a tendency to trust it and to not apply an adversarial model towards it as they do with userspace. They don't need unrestricted DMA access, and proper IOMMU setup keeps them from having that. Having DMA does not mean having full control over all memory. Not having DMA doesn't mean that the component is well isolated. Whether or not the component is on the same die is totally orthogonal to whether it has DMA access. These are common misconceptions, and are being abused by dishonest marketing to trick people.
> Android can give you privacy and enough security for most people.
Some of that is due to the improvements landed upstream based on the work in this project.
> This can't add much more as long as its running on the same devices.
I don't agree with that at all. It can't improve the security of firmware directly, but it can certainly improve the isolation of it by auditing and improving IOMMU configuration along with hardening the drivers. It also won't be supporting devices without decent IOMMU support and firmware security updates. The project has also reported various firmware security issues to the relevant companies over the years of the project, so that's an indirect way of improving them.
A large portion of the project will also be on app layer projects like https://github.com/GrapheneOS/Auditor usable on the stock OS and other operating systems. Auditor / AttestationServer support the stock OS on a bunch of devices, along with CalyxOS and GrapheneOS. Other apps will generally be more portable, but in this case it has to have a database of the verified boot key fingerprints and other device properties. The verified boot key is the only information included in the signed hardware attestation data that it can use to distinguish between devices which it needs to do in order to show the device model and apply different checks based on the device. That's why devices need to be added to Auditor one-by-one based on users submitting sample attestations with the app.
I don't disagree with your overall post. I do want to add that there's a good reason to not put the backdoor in the CPU: it's main place they'll look with plenty of people capable of spotting it. The guy that taught me about hardware subversion years ago preferred hiding stuff in analog parts of mixed-signal ASIC's. He said digital people neither saw it nor understood it. He and others taught me about how the two can interact in invisible ways where analog or RF portions might pick up leaks. So, deniability is maximum if it's some kind of analog or RF part of a chip. He claimed to have never found backdoors but that he and others used this for I.P. obfuscation a lot.
I do like the IOMMU and firmware work. There's a lot of custom I.P. to build before being competitive with one of high-end SOC's. One thing I considered about trying to make an open phone is whether a company with money could just pay for Snapdragon to be integrated with the RISC-V cores. Modify RISC-V core to use microcode for security updates and product enhancements. Put security barriers in key places so Snapdragon I.P. is a little less dangerous or can even be powered off component by component. Then, if the agreement gets more data on hardware, use that with secure, development practices to make robust drivers. Include method for secure boot and update that still allows user to put their own stuff on the phone if they choose.
What you think?
EDIT: In case it wasn't clear, I know there's stuff like IOMMU's in Snapdragon. I'd just prefer an independent, security-focused company to be making those components. Sort of a check against incompetence or malice on Snapdragon's end.
This is misleading.
> A maliciously inserted backdoor designed to be stealthy would be indistinguishable from those
This is a false equivalence. In most closed source systems the vendor does not need to put efforts into designing a stealthy backdoor.
It just adds tons of code that spy on the user and call it features. The amount of homecalling done by android, ios and windows is staggering.
Not to mention the ability to push an update that can contain a backdoor on a specific, targeted device without the users being aware of it.
The whole point behind it is working on a new mobile OS, while providing Android app compatibility by using the Android Open Source Project. As the page states, the long-term goal is to turn AOSP into an application layer while moving away from entirely depending on Linux for low-level security since it's a huge liability / weakness. It already isn't 'Android' since it makes changes deviating from what's required to be Android (the Compatibility Definition Document and Compatibility Test Suite). The goal is practical compatibility with Android applications rather than conforming to what's requiring to be Android.
> All I can say is good luck with various firmware, custom services and drivers.
Hardware, firmware and drivers aren't an OS specific issue beyond drivers being tied to Linux. There's barely any content on the site yet, but it does cover how important it's going to be to make careful choices about which hardware to support in the device support section. It talks about how much of the privacy and security is tied to hardware capabilities and security support.
Seriously though, I hear Apple is super great on privacy now as long as you take their word for it and not their track record of being a member of PRISM https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%... , etc
There were consequences to the US passing draconian surveillance laws like the Patriot Act and the updates to it. Companies / organizations and individuals based in the US are subject to those laws. Many other countries have similar or even more oppressive laws when it comes to these things.
A company being based in for example France doesn't mean that the same kind of things don't apply.
If you don't want data to be subject to warrants requesting the information from companies, you need to either avoid having your data there or make sure it's encrypted with a key that the company doesn't have. End-to-end encryption is important. The companies could also have the data exposed by a malicious insider or a data breach. Many countries will happily demand the key from you and then treat you as a criminal for not turning it over but that doesn't work for mass surveillance.
https://ewwlo.xyz/evil https://infosec-handbook.eu/blog/e-foundation-first-look/
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.
Check the Google IO 2019 talk about Linux support on ChromeOS.
In general, if you want any hope of unlocking your phone (either for use on other carriers or unlocking the bootloader) then you should NOT buy from the carriers' online or brick & mortar stores.
It can only see hardware, files and processes that the user allows to as well.
It was written in Rust.
Check the ChromeOS support for Linux talk at Google IO.
The OP expressed he wanted to use (or create idk) a micro-kernel based OS, and that in the end he would like to scrap the Linux kernel.
Of course the solution you are pointing out will deliver in one of those axis, but the solution im pointing out would deliver in both, Linux emulation/sandboxing and a micro-kernel based OS controlling all of this.
I just think that the direction Fuchsia is going, has a little bit more to do, to what he is trying to achieve.
But he can totally mix the 'syscall proxy' solution of ChromeOS and a micro-kernel, even if this would still be Zinc or something else. And depending on the goal, maybe having this in userspace level would make more sense. He just need a good and flexible IPC communication (like the one in Chrome, or something on the kernel level).
Android itself has a wide variety of issues which might be solved (or at least solutions might explored) by creating projects that go outside of the mold of Android ROMs.
I want a real Linux in a phone as much as anyone. In fact, I have stuck to the Maemo N770-N9 saga as much as I could.
But I am also realistic. Developing a new secure Linux distribution for phones and, most importantly, a healthy ecosystem with useful applications will take a lot of time and effort.
In the meanwhile, as discussed in other threads here, using AOSP on a Pixel (or even better, GrapheneOS) is a really good solution. It's remarkable how few people use it in comparison to the benefits it brings into the table, and given it's quite easy to migrate to it with the appropriate hardware (hopefully device-independent ROMs make this less restrictive).
If standard applications in AOSP are lagging behind, then it'd be probably worthy to spin off an effort to replicate all proprietary functionality. An equivalent to MicroG.
That said, I've never missed anything major. For me, Firefox/Chromium, K-9, Conversations/Signal, OsmAnd and Termux provide a great userland experience.
Interesting, I did not know that. What are the reasons for this? Military application? Are these laws subject to change?
I always thought that there is no way to separate the CPU from the baseband/communications PU.
AOSP sample applications like Calendar are exactly that: samples. I'm not sure why those are at all relevant. There's a very healthy and active open source app ecosystem, along with many other apps that work on AOSP. Those AOSP apps are included as samples, and they're being removed from the project as at this point there's no real need to have these samples.
It's also not true what you claim about the stock applications shipped on a phone like a Pixel. Apps like Dialer, Contacts, DeskClock, etc. are still actively developed and maintained in AOSP with the Google variants being extended versions of those apps. It's true that some apps like the keyboard forked away from the AOSP version, but it doesn't make AOSP any less viable of a basis for an OS. It's not a bad thing for AOSP to not ship a bunch of user-facing apps when there are a bunch of good alternatives outside of it. Apps do better without a release cycle tied to the slower pace of the OS releases.
> 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).
This is completely untrue and absolutely a false claim. The SoC is entirely proprietary with proprietary hardware, firmware and microcode along with the other components like Wi-Fi, the baseband, etc. being the same. The cellular baseband is not an exception. It applies to all of the hardware components in general. Librem 5 is not open hardware and does not have open firmware or microcode. It's simply untrue, and you're falsely representing it. I can see why you would be under that misunderstanding based on their incredibly misleading marketing but they never actually claim what you are claiming.
Not providing firmware updates for these things is a security disaster. The firmware that's upstream in Linux is rarely open source. It's a subset of the necessary firmware for most devices and is still proprietary. Projects like linux-libre / PureOS do not ship these upstream Linux firmware updates. They strip all of this out of the kernel. They also don't provide all the additional firmware updates beyond what is upstream.
The hardware and firmware is just as proprietary. The boot chain has open source components near the end before the OS (coreboot), just as many mainstream devices do (https://source.codeaurora.org/quic/la/abl/tianocore/edk2).
There's a huge difference between choosing hardware that has built-in firmware and can work without the OS supplying it each boot and hardware with open firmware... what they are doing is shipping a device that can work without the OS providing firmware updates, since they don't do that to keep it 'pure' of proprietary code. The firmware is still present and running, except it's out-of-date and vulnerable to many patched security vulnerabilities. You're completely misrepresenting the reality and falsely portraying it as having open hardware and firmware when it absolutely does not.
https://twitter.com/mjg59/status/1129124275464441856
What you claim about not being allowed to have open cellular baseband firmware is also nonsense. It's also not particularly different from how Wi-Fi works. Wi-Fi firmware is a comparable secondary OS, and the same applies to a lot of other components. These hardware and firmware components on the Librem 5 are not any more open. What you're doing is spreading misinformation and false claims to promote it as something that it's not.
You're substantially misrepresenting the events that occurred based on a very incomplete account of the events that you've seen. People seeing your comment are going to end up with an incorrect understanding, just as you did. You're stating your assumptions and misconceptions about what happened as if they're facts. It's a very incorrect account of a very small part of the story. This game of broken telephone where people misinform themselves and then propagate variations of that to many other people is a poor way of spreading knowledge.
>It was a problematic relationship long before you heard about it
Probably day 1 as it sounds like there was a fundamental conflict with the business and non business entities, I don't get what anyone thought such an arrangement would really do that would be positive. Hopefully everyone learned from their experience, can do some good work now, and can avoid such things in the future.
Research is currently ongoing into choosing at least one decent low-end device with the least security compromises. There's no way to avoid losing some of the fancier hardware security features like the HSM because they aren't offered. The expectation is still that all the basic hardware / firmware security features are intact, which includes a decent IOMMU implementation, verified boot / attestation, at least a TEE-based hardware keystore (if they don't have a nicer HSM implementation like the high-end targets), etc. Many of the baseline security properties are tied to the SoC, including the IOMMU implementation for SoC components. Device vendors and the peripheral hardware vendors (like Broadcom for Wi-Fi) end up responsible for properly setting up IOMMU containment for peripherals, and that's often where the ball is completely dropped. There are often problems tied to where there are boundaries between organizations because there's often a lack of responsibility taken for these things. SoC security is unavoidably something that the SoC companies are responsible for handling, but issues like properly containing the Wi-Fi SoC can end up relegated to being treated as someone else's problem by every company involved.
I do think more research is needed.
https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem
Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections and futz with any traffic, eg, deny main OS updates until it can attack it via an unpatched vuln. TLS is good but it'd only take one hhtp connection through unpatched webview.
Focusing on the cellular baseband is missing the bigger picture. There are dozens of computers in modern personal computers running their own operating systems. Cellular basebands are very directly comparable to the Wi-Fi SoC. It's a mistake to think that the same things don't apply to Wi-Fi, especially when on so many devices it's much less contained than the cellular baseband. I'd recommend checking out https://googleprojectzero.blogspot.com/2017/04/over-air-expl... which is about exploiting the Wi-Fi SoC older generation device, which then provides full direct memory access since it wasn't meaningfully contained by the IOMMU. It was a configuration and driver coding issue, as the hardware was entirely capable of containing it but was unfortunately not set up to do it.
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.
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.
Okay, so you're saying: "If a backdoor is present than your security prioritization doesn't matter, the result is bad." I understand, but:
1. If there is a back door in open source code that goes unnoticed (and it certainly does) because of persistent but bad practices in the open source community (e.g., a stubborn refusal to stop using C-like memory management semantics and primitives when dealing with untrusted inputs), then why don't said accidentaly backdoors invalidate the open source work?
2. Does "control" actually matter in the context of AOSP? Strictly speaking, you have essentially everything you need up utill you hit the hardware drivers. You can easily rewrite that to your hearts content.
3. Given Librem's recently move into commodity-based social products (and the poop-from-great-height attitude they initially adopted), are you genuinely sure that they're actually trustworthy actors? If they're coerced, how will yu attest that they never injected a deeply subtle backdoor on millions of lines of code which you'd like to be unique and less scrutinized?
I can't really work out why you feel the way you do, so I ask these questions.
This applies to the entire industry. It's not something specific to the open source community. It's also extreme to call the use of C as "bad practice," as any language has its own strengths and weaknesses.
With OSS you get more people working on a project that actually care. A proprietary business project prioritizes making money over actually creating a good product everyone loves.
You're right that this is not a perfect solution. All software has bugs and all software may have malicious back doors. I just find it much easier to trust the development that happens in the open with community involvement than the development that happens in secret where I have absolutely no way see what's going on.
If you had an inkling that someone was trying to poison you, would you rather eat the food you watched be prepared or the food that was prepared in secret? Both dishes might be poisoned, but it's reasonable to prefer the one you were able to examine.
I don't trust all open source software, but I trust it by default more than I trust closed software. And I know that if something really bad gets exposed the odds of a solid fix are better in open source. I get to see the warts of OSS. There's public criticism over small details on a lot of important projects. That doesn't happen for closed stuff. Sure, a vendor may have four of the brightest devs in that field and they might hash it all out behind closed doors. The open alternative usually has another four of the top 12 minds in that field along with four pretty competent others and they have a better process for hashing it out.
Then there's that other guy who's not in the top 12 who goes it alone and comes up with something spectacular. So three of the four from the other open project jump on board because they can. And since this new project tries very hard to be backwards compatible, it just snaps in as an overnight replacement. That's part of the awesomeness of OSS.
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
Android isn't secure, it's limited, that's the whole problem here. Any security you can't control isn't a security feature but just a limitation. It's "secure" because you can't do anything interesting with it.
Still, I can do plenty of interesting things with my Android gadgets.
I don't. But nor do I assume it has less. My point, as restated elsewhere, is that from a user's point of view Openness of Source is more about protecting against negligence.
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.
GrapheneOS has a Network permission toggle, which is one of the features already restored from the past work on the project. There are many other privacy and security features that still need to be ported to the latest release, although a lot of them have become standard features especially in Android Q. https://gist.github.com/thestinger/e4bb344dcc545d2ee00dcc22f... is an overview of the Android Q privacy improvements(not security improvements, just privacy) in the context of GrapheneOS. To conserve development resources, the past features that are becoming standard aren't going to be ported over rather than just waiting for the standard implementations being released around August. Some of them will need to be adjusted to make them a bit more aggressive when it comes to apps targeting the legacy API level, but that's a lot less work than maintaining downstream implementations of all of this.
> you cannot update or modify the OS pieces at will
Having a well-defined base OS with verified boot and proper atomic updates with automatic rollback on failure is a strength, not a weakness. It's the same update system (update_engine) as ChromeOS. The update system is not the problem with the broader Android ecosystem with lack of updates to vendor forks. The migration towards everything being apk components that can be separated updated rather than moving more towards the ChromeOS design is a negative thing in terms of GrapheneOS and it's one of the things that has to be changed downstream to improve verified boot.
> Librem will answer these.
That's nonsense. First of all, that's hardware, and also moving to a far less secure software stack with non-existent privacy and security, an inferior update system and no verified boot is not a solution to these problems. The solution to privacy and security problems is not completely throwing away privacy and security...
Android Q has another round of such measures.
https://android-developers.googleblog.com/2019/05/queue-hard...
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.
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 ) 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.
Source, the Kernel Self Preservation Google's talk at the Linux Kernel Summit 2018.
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 ) 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.
Microsoft of the 90s, which no one emulates these days and it's a wrongheaded comparison anyways, would have said that all the open options are bad to begin with.
If you meant to say "anti-free software" then maybe we could have a conversation, but that's hardly the problem Microsoft faced in the 90s and 2ks.
Seriously, what does your post mean? Could you maybe be specific? And while we're at it, what's your connection if any with the company that sells Purism phones.
At least MS wasn’t built on open software, unlike Google.
> And while we're at it, what's your connection if any with the company that sells Purism phones.
None at all. I’ve just heard of this project a few days ago via a DDG search.
Believe it or not, not everyone is a corporate shill.
That's not what I said. To sum it up: Open source is not really a security proposition. It eliminates problems related to negligence.
> having control doesn’t matter
In what concrete way does the Purism OS give you more control over your device than AOSP?
It really seems like you are confusing open source and free software for this entire conversation, as literally every line of code we are discussing is shared under a license that allows you to look at, modify and use as you see fit.
> None at all. I’ve just heard of this project a few days ago via a DDG search.
The depth of your consideration was already fairly easy to guess, but thanks for being honest.
> Believe it or not, not everyone is a corporate shill.
Physician, heal thyself.
Doesn't stuff like fs-verity help with stuff like this instead of just a block based RO partition that can be verified ? Overall, for the android ecosystem, it seems like a net gain if google moves more and more stuff out of band away from OEMs as OEMs are not incentivized to do anything other than sell devices. That is, as long as everything is still pushed to AOSP.
Privacy is security!
BSD/Linux derived FOSS is still the C stronghold.
The Morris worm was in 1988, since then C has collected enough CVEs due to memory corruption issues to consider its use bad practice.
Something that even Apple, Google and Microsoft security reports now advise against, and with Google actively engaging into taming C's usage in Linux kernel.
Oh that's ok then, it's not like that accounts for most of the world's server and embedded infrastructure, open or otherwise...
And regarding embedded space, AUTOSAR now requires C++14.
I think there are enough computers with wheels to deem it relevant.
I know they've introduced a lot of ways that memory management becomes easier or automatic, but I'm not sure you can call it "memory safe" can you?
Still it does provide a stronger type system, proper string, vectors, reference paramenters and strong type enumerations, to prevent a large amount of C security exploits.
C++ teams that care about security do use such features and respective static analysers on their CI/CD to enforce them.
While it doesn't cover everything, it is much safer than plain C.
Ideally, we will reach a state where both C and C++ get nuked, or ISO C++ just drops its C copy-paste compatibility, which in the end means it is anyway easier to switch to something else.
However that process will take decades, and is hampered by relying on POSIX based systems.
Even HNers do curl | sh without thinking twice about it.
Kind of, Google can release Android running on top of any OS that implements the NDK stable APIs, plus their POSIX subset, and besides OEMs no one would notice the change.
https://developer.android.com/ndk/guides/stable_apis
Other than that I fully agree with your statement regarding being a security weakness.
I don't want to make a song and dance about C being awesome or anything - we've certainly got massive issues with allowing that extreme amount of flexibility without ensuring that the developer really, really means what they've just told the machine to do - but it's hardly a small enclave that's holding out, it's still huge.
And there are still companies developing in it. I've seen a sort-of-microservices-in-C-implemented-as-a-sort-of-supersized-cgi-bin approach relatively recently.
And yes it was an abomination!
Windows Phone, JavaScript, .NET (VB and C#) and C++.
iOS, JavaScript, Objective-C, C++ and Swift, C only due to BSD stuff.
Android, Java, Kotlin, JavaScript, C++, C only due to Linux kernel. Its sucessor. Project Treble drivers use Java and C++. Fuchsia is written in a mixture of Rust, Dart, and C++.
ChromeOS, JavaScript, C++, Rust, C only due to Linux kernel
An irrelevance given their complete lack of market presence.
The rest all have significant underlying C components you've identified. All I'm saying is that's a hardly a 'niche holdout' when it appears to be at the heart of the vast majority of shipping devices.
By the way on iOS, drivers are written in C++.
The big contribution of Purism phones is that more open hardware. After that, the real question we should ask is, "What software platform can offer us the greatest values in the multi-dimensional optimization problem we face?"
It's true though that you wouldn't just flash AOSP. But it's also true that dismissing Graphene BECAUSE it is based on AOSP is unfair.
I am not meaning to paint those who work on AOSP or third-party ROMs in a bad light. The work they do is terrific and great for the community. I also do not mean to dismiss any of the fantastic work that Graphene brings to the Android community.
I am simply stating that the biggest difference between Librem and Android is that there are more hurdles to jump through to provide a completely usable and free AOSP phone to an end-user in 2019. Android has been made to host a Google ecosystem, where the Librem 5 is being created to host an open ecosystem.
It sounds like the Purism team identified this issue ahead of time and decided to provide that open hardeware platform for us.
Yes, a significant fraction of Android apps do not work on AOSP without Play Services. And 100% of Android apps do not work on PureOS. F-Droid alone has ~1800 apps. I do not see PureOS or PostmarketOS catching up to that level anytime soon.
FOSS projects that are built out of passion, but recieve little funding or corporate support? Exact same situation on PureOS.
Are the Snapchats and Instagrams of the world going to port their apps over to this entirely new platform when they can't even be bothered to make versions of their Android apps that work without Google's services?
This is a fair point. It's not a huge argument for me because I'm only interested in maybe 20 categories of app and I've never been thrilled with the 30 contenders in each category. For instance, if it has only one browser and that one is Firefox, that will be ok with me to begin with. It won't bother me if there are five other choices in F-Droid. But in general, more choice is good, so I grant that this is an important consideration.
> Are the Snapchats and Instagrams of the world going to port their apps over to this entirely new platform when they can't even be bothered to make versions of their Android apps that work without Google's services?
Android without Google's services is a tiny fraction of Android and a smaller fraction of the whole market. PureOS or anything else with even smaller share can expect to be similarly ignored. But Android sans G seems even less likely to go viral than something else.
For one thing, it's too fractured. There is no AOSP brand. There's a bunch of little no-names that happen to offer AOSP under some name that isn't "AOSP" and has no recognition at all. If two or three lower-tier makers offer "Brand C" phones, it could spark. Maybe not in your neighborhood. But if it catches on in India or Malaysia or Brazil, it might be enough to attract Instagram or Twitter. Remember that those companies don't want to depend on Google. They very much want Google out of the picture.
So a handful of apps can legitimize a new platform that is attracting a million or ten users anyway. Then it becomes perilous not to be on that platform. WhatsApp can't afford to let some up and comer get a foothold just because WhatsApp wasn't available on the viral new platform.
Ahhhhhh. Ok I'm going to quit dreaming for now and get back to work. I'm not holding my breath, but I do think it can happen. It just takes the right lucky timing. There have been so many helps lately that I think if there was something ready to take advantage of these incidents, the timing is right.
That lack of awareness seems to be your own.
> 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.
GPS doesn't require Play Services, etc. Play Services provides supplementary network-based location services for providing a coarse, inaccurate location estimate without waiting for a while for a GPS lock. The infrastructure for this is open source and part of AOSP. It has generic, provider-agnostic support for services like supplementary location providers, text-to-speech, speech-to-text, geocoding, etc. Play Services is what provides these on phones with Google Play, but there are alternative implementations used by Amazon and in China.
> Applications that are built to run on stock AOSP are not the 'Snapchats' or 'Instagrams' of the world.
Yet apps like WhatsApp, Facebook's apps, Microsoft's apps, etc. do work without Play Services... despite what you claim. A lot of these mainstream apps do work fine, and there's a large ecosystem of open source apps that are mostly designed to run without Play Services. Providing the Play Services APIs with an alternate implementation and is also certainly possible, although I would prefer a different approach than microG.
How is any of this resolved by moving to a completely different OS with far less privacy and security, none of these mainstream applications you talk about and barely any open source application ecosystem by comparison? I don't get it.
My worry with Librem and all those initiatives is that rebuilding an ecosystem like F-Droid takes a lot of effort and time.
I tried many of the well-known ROMs: Lineage, Paranoid, Ressurection.
I also tried many of the OnePlus-specific ROMs, that were typically maintained by only one or two devs each.
Most of the features worked perfectly fine on both phones. But the deal-breakers were often the simple things: GPS (w/o downloading extra geolocation database services) and Bluetooth were the kickers for me. These services were consistently spotty across every ROM I tried.
My experience is as of a couple years ago. I have since moved away from the ROM scene, simply because I do not have the time to deal with this sort of stuff anymore.
The reality is that Librem is unnecessary because we have F-droid. There's nothing wrong with F-droid and as time goes on more mainstream apps will continue being brought over.
GrapheneOS is sadly only available on Pixel devices.
The microg project has been fantastic in providing an open mechanism to interface with Google's services. When I first tried it, I believe they did not yet have a working implementation of all the Google services. Some apps complained about Google services, some did not. You still needed to sign into Google though, which might turn some people away.
For those who want to interface with Google on an open-source ROM, microg's image is probably the way for you.
Microsoft's apps are specifically an example I've given of how closed Android truly is: Even Google's competitors, which have all of the same service capabilities, are essentially forced to use Google Play Services. Especially when you consider the other top HN item today about how Google now essentially requires all apps use a closed source Firebase library for push notifications.
And while yes, Google Location Services is a location provider that slots into Android, you are missing that Google has convinced app developers to call it directly, rather than using the Android location provider. This means that no alternate location provider will do: Google Location Services is hard coded into almost every location-based Android app today.
In short, of the apps I tried that weren't distributed via F-Droid, most of them suffered from varying degrees of brokenness without Google Play Services (and these same apps work fine on my HTC One M8 and my current-daily-driver OnePlus 5T, both of which run LineageOS w/ GApps).
You're right, though, that "some Android apps work fine" is a better situation than "no Android apps work at all". Hopefully GrapheneOS can leverage that advantage well. It'd just be useful to acknowledge that it ain't all sunshine and rainbows just because it's AOSP-based; whether it's microG or something that ain't a security landmine waiting to blow off someone's leg, addressing that issue with an alternative service provider would be a game-changer, and would readily address the one issue I ever had with CopperheadOS (and - it seems - likely would still have with GrapheneOS).
Could you write more on the state of open hardware, and perhaps point me to open-hardware endeavours that have the slightest chance of success?
I understand that it is an very expensive undertaking to deliver a hardware mashine that is based on an open architecture from the CPU to the actual communication/data storage devices (logical design, actual layout, photolithography, assembly). Since patents on older circuitry must be all expired by now, it must be the lack of money that is the actual stopper for truly open systems.
And, I would much rather "make my location known" to about fifty other companies before I would want Google to have it.
https://www.maptoaster.com/maptoaster-topo-nz/articles/how-g...
And it's just out there. Usable with no subscription, no account, nothing. It's just free data.