https://grapheneos.social/@GrapheneOS/117282080803799576
Since they are working with two OEMs (one for GrapheneOS support and one for getting embargoed security patches), I think they know what they are taking about.
27,097 karma · joined June 29, 2010
https://grapheneos.social/@GrapheneOS/117282080803799576
Since they are working with two OEMs (one for GrapheneOS support and one for getting embargoed security patches), I think they know what they are taking about.
But many Android OEMs are probably terrible at software engineering and have their attention spread across multiple SoCs, etc. It’s their own fault.
They are mostly relying on LineageOS now and putting their own cloud, microG, and App Store app and branding on top of Lineage. Even now they are not able to roll out Android releases and WebView updates timely. Them maintaining an AOSP fork would probably end up in an outdated, broken mess.
My money is on GrapheneOS and maybe LineageOS to do it when needed.
Google should not be allowed to abuse its duopoly position in this way. I recommend EU citizens to report every case they are (potentially) affected by to the EU DMA team.
Also, major Android releases and QPR2s have many security fixes (anything not marked high/critical), yet OEMs are not rolling them out (QPR2) or very late (major releases).
Just to say that OEMs were probably violating the act already before Google started withholding source code.
I also think it’s an attempt of Google closing up AOSP more, otherwise they wouldn’t make it so darn hard to get updated Pixel kernel trees.
The alternative are other AOSP-based OSes like GrapheneOS and Lineage. Once they are used widely enough and funded enough, they could fork AOSP when needed. In some sense they have already soft-forked in that they use major and QPR2 releases, but put a lot of patches on top to fix issues, improve security, etc.
GrapheneOS has an estimated 500,000 active installs now, apparently LineageOS has 1.4M active installs. Probably around two orders of magnitude more than traditional Linux desktop-based phones, which have been trying since, checking notes, Maemo in 2005?
This is all only mentioned in the footnote of an iCloud security document [1].
Apple cares about your privacy, so much that they made a backdoor through bad defaults, well in reach of the CLOUD Act.
[1] Footnote 9 in https://support.apple.com/en-us/102651
It looks like a nice device at a reasonable price. I looked at the video, but it doesn't solve any problems I have. We ban screens at the dinner table, it's for having attention for each other, not for screens. I never have to ask for a recipe for french toast, it's either in my head, or in cookbook, or written down on paper. The very rare number of cases someone loses their key, we can just look it up with Find My on the phone, it's such an irregular occurrence that it's not a hassle to find it with a phone. For random queries, phones with Siri can already listen, but the voice recognition or LLM fails on too many queries anyway not to be frustrating.
I could see it being useful as an additional control panel for the smart home, but Home Kit and the Home app are still pretty useless for the smart home. It can't even show a temperature graph or trend, let alone do many other things. So I would like a Home Assistant/Homey/whatever display (which would be possible if it supported apps).
I am sure this will sell plenty. It's an Apple device, people will just buy it for that reason, especially if it's not in the Apple Vision Pro price class. Will the get used a lot? Probably by a very small subset of people. Just like Siri doesn't get used a lot beyond setting timers when you are not in an English-speaking country, or even worse, use multiple languages in daily life. I am not in the US and most people I know never use Siri.
Aside from that most people seem to be more interested in digital detox than getting more pervasive tech in their lives.
People use a phone for their most private information, including banking credentials, credit card credentials, car keys, etc. The banks, etc. are never going to permit running their apps on devices that can run arbitrary binaries. Most are already blocking rooted Android devices and Android devices with an unlocked bootloader. The fact that this is still possible on desktops (though not everywhere anymore, e.g. my bank requires you to use a phone app for authentication) is for historical reasons.
Also, you are an extremely small niche. If you are sufficiently motivated, you can live like that (run Linux phones, work around banks, etc.), but this will never be mainstream and this was implied in the question of the post (Will Linux phones become a viable alternative to the Android/iOS duopoly?).
If there will be a viable alternative to the Android/iOS duopoly, it will look a lot like Android/iOS. The best chance is an AOSP-based system like GrapheneOS.
You can still run traditional Linux desktop apps in a VM on such phones.
- Memory-safe languages where possible.
- Sandboxing of applications, parsers, etc., along with a strong permission model.
- Mitigation like secure app spawning, zeroing out pages, etc.
- Modern mitigation hardware-assisted mitigation like MTE and PAC.
- Storing secrets in a separate secure enclave (not ~/.config or ~/.ssh).
- Read-only and fully verified system partitions (anti-persistence).
This graph:
https://security.apple.com/assets/image/generated/xlarge_adv...
from Apple's MIE docs [1] shows where modern systems like iOS and Android are. An attacker often needs a long exploit chain to compromise a device and it becomes increasingly difficult with various mitigation techniques. On the standard Linux desktop it's often as easy as exploiting an image parser in a client. Old parsers in C have a history of bad vulnerabilities, exploiting one often gives you privileges of the process calling the function, since Linux applications mostly don't separate/sandbox parsers and from there you have direct access to all data of the user, since Linux applications are typically not sandboxed.
[1] https://security.apple.com/blog/memory-integrity-enforcement...
It is sometimes annoying to me. I cycle a lot and sometimes my wife or somebody else sends a message when I'm on the go (like picking up some extra groceries) and then I miss it.
There is a longer discussion with various people here:
You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).
A lot of people from the FOSS community seem to believe that (at least from recurring discussions) that Linux is secure because the software is open source and you can trust the maintainers. The idea that even trusted software can have vulnerabilities and that the 80s/90s security model of the standard Linux desktop means that you are only one Mastodon/e-mail/RSS/whatever client vulnerability away from exfiltration of your whole home directory does not even occur to them. All the while all these applications use (XML/image/...) parsers from the 90/00s written in C.
The only reason we don't see mass-exfiltration of data is because the Linux desktop marketshare is effectively meaningless. Though we see some results of the desktop security disaster (also to some extend of macOS) through leaked credentials obtained by compromised NPM, PyPI, etc. packages.
But no, let's reinvent the wheel and start the complete ecosystem from scratch. Of course, looking at the history of Linux, this is not surprising at all. Even something immature as mobile Linux already has multiple projects + stacks (Sailfish, ubports, Plasma Mobile, PureOS, etc.) trying to achieve the same. I say this as a long time Linux user (since 1994), the Linux desktop community manages to shoot itself in the foot over and over again.
But yeah, then there was the constant forking, preferring rebooting development over iterative improvement (e.g. GNOME 2 -> 3 was really a hard cut for a lot of people, resulting in forks that exist till this day), hostility towards closed-source applications (you can hate them as much as you want, but people are not abandoning Photoshop/Illustrator for GIMP/Inkscape on a whim), etc.
Hopefully something changes with all the government-driven sovereignty desktops that are popping up, the resulting influx of money, and KDE EV et al. becoming very mature organizations.
Given that Android apps target old API levels, it would also stay compatible for years and nothing would hold you from implementing APIs from the docs.
To be honest, I don't think AOSP will fully close up, since Google probably fears the regulatory pressure and the fallout from vendors. The larger risk is Play Integrity, but that applies equally to other Linux systems if you want to tap into the large Android app ecosystem. But the solution for that is not technical, the EU and other regulatory bodies should make forbid it in its current form due to anti-competitiveness.
You are moving the goalposts, you said:
The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. [...] Once we can actually target the hardware, open source alternatives will be much better than first party options.
So, it's not the hardware gatekeeping that is the issue, it's that nobody is polishing the experience for hardware that already exists and qualifies. The hardware can also be purchased very easily in some regions (e.g. Europe). I can literally hop on a bike right now and pick up a Fairphone in ten minutes. I know that it's different in e.g. the US, but Murena has been selling them in the US for years now.
The most effective path would be for the FLOSS ecosystem to pour their resources into making AOSP independent from Google. But instead people will just fork N half- or non-working solutions for reasons.
The problem is not only hardware support, the problem is also that the stack on top of it is very immature compared to AOSP and not something you could give to a daily phone user.
It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.
LLM-driven optimization is a good point. However, Linux desktop communities tend to be quite aggressively anti-LLM. E.g. GrapheneOS has been heavily attacked by these people for only using an LLM for security auditing. But maybe these projects will fork into LLM-accepted forks who will then rapidly out-innovate.
I have had several generations of ThinkPads and to this day, battery life is typically ~50-60% of that of Windows, even with all battery optimizations applied. And Windows is terrible compared to Mac or Android/iOS phones.
And I say this as a long-time Linux user (used Linux in some form since 1994). It's just a very hard nut to crack if you miss a certain amount of vertical of integration and coordination across the ecosystem.