Zum Inhalt der Seite gehen


With all the BS of Apple doing their AI spying (amongst other issues), it's that time of year where I once again look for a "third party" phone to migrate to as a daily driver.

I've followed lots of Linux phones (running Ubuntu Touch, KDE Plasma Mobile, postmarketOS and others), feature phones running KaiOS, and others.

Heck I was even building my own phone on an RPi years ago (https://web.archive.org/web/20210725154717/https://www.tinker.sh/kde-plamo-rpi/ ) and have been following the PinePhone project for a very long time.

My current research is pointing towards a Fairphone 4 running e/OS (degooglefied android). I live in the US, so this is as close to the Fairphone as I can get currently: https://murena.com/america/shop/smartphones/brand-new/murena-fairphone-4/ (edit: Annnnd, it's no longer available.)

Really I just need a phone that runs Signal and can run some sort of GPS app. Everything else I can do via a web browser.

I hate Apple/iOS phones. The only thing I hate more than Apple phones are Google/Android phones.

#phone #android #ios #apple #google #fairphone #privacy #linuxphones
Dieser Beitrag wurde bearbeitet. (3 Monate her)
GrapheneOS seems pretty solid. Although, it requires a specific phone to install it on.
- Yeah Graphene OS, e/OS, and similar android forks that have been degooglefied are something that I've always been interested in.

I'm not in a place where I can mess with the OS on a daily driver much so it'd have to be close to "out of the box" as possible. (I can sideload things and install new OS's but I cant be tweaking things constantly).
GrapheneOS and /e/OS are very different projects. GrapheneOS is a hardened OS based on the latest release of Android. It preserves the standard security model, implements massive privacy/security improvements and our sandboxed Google Play compatibility layer for app compatibility. /e/OS is a fork of LineageOS, which are both focused on very broad device support and don't offer a reasonable basic level security or stability with the security model kept intact or basic patches.
There's a comparison table between Android-based operating systems on this third party site comparing a bunch of different types of software with a privacy focus:

https://eylenburg.github.io/android_comparison.htm

A comparison from GrapheneOS to the latest standard Android release is available via our features page, which lags a bit behind what we currently provide:

https://grapheneos.org/features

We don't support more devices due to our hardware security requirements listed here:

https://grapheneos.org/faq#future-devices
Pixels are the only devices providing competitive security with iPhones and the hardware-based security features we use including hardware memory tagging. They also provide very unique first class alternate OS support where all the hardware features including the security features can be used by an alternate OS. Installing GrapheneOS doesn't even void the standard warranty, although that is not one of our official requirements since it would be too unreasonable to expect it.
GrapheneOS is a production quality OS. Every official release is tested on each device, then released through our Alpha channel, then the Beta channel and then the Stable channel.

Android 15 QPR1 is the only LTS version of Android. Older releases get partial security patches backported to them, similar to iOS. Lagging behind weeks would be unacceptable to us. That ties into the hardware requirements and nearly all the work we do on the OS. It always has to be kept in mind.
Even the Fairphone 5 has an SoC from 2021 without current generation security features and lacks a secure element providing any of the features tied to that. They used a low-end SoC focused on IoT use with cheaper long-term support.

They already provide the security backports 1-2 months late, skip all the monthly/quarterly OS releases and provide the yearly releases over a year late. It will get much worse over time as it did with their older hardware. That would impact us too.
Fairphone 4 used publicly available private keys for signing the firmware and OS. Lack of working verified boot and attestation is far from the most serious security drawback but helpful for understanding how little goes into securing most Android devices.

Lots of people regularly ask them to implement the security requirements we list so GrapheneOS could support it and they explicitly said they don't even plan to add a basic secure element for working encryption for most users.
I'm pretty sure that I could relock the bootloader on my FP3 with LineageOS.

Please don't chastise me for saying that. ;) I have seen the light now! :)
LineageOS disables verified boot for a large part of the OS and implements incompatible changes rolling back the security model. Locking a device with it doesn't really accomplish anything. Since the Fairphone 4 had completely broken verified boot due to using publicly available signing keys, it's unlikely it worked on their earlier devices. It's likely they fixed that for FP5 but it still has the other issues.
We're not ever going to chastise you for using an insecure device. We just want people to be well informed about it. People should know that by moving from an iPhone to nearly any Android device they're losing a whole lot of privacy and especially security. The niche options marketed as privacy focused are among the Android devices with the worst security. iPhones do have overall very strong privacy and security.
Pixels have competitive hardware/firmware security with iPhones and the latest Android Open Source Project isn't that far behind iOS on security but it is definitely behind on privacy from apps. A fair bit of our features like Storage Scopes and Contact Scopes are needed to be competitive with iOS privacy. We don't actually claim GrapheneOS provides better privacy from apps than iOS right now, it's just competitive.
We provide a lot of privacy features iOS doesn't including our Sensors toggle, Network toggle, Contact Scopes being superior to what they added in iOS 18.

There are also standard Android advantages of better VPN support (which we improve fixing a lot of leaks) and profiles (Private Space, secondary users, local work profile management apps).

iOS still has some privacy features we don't. We're working on fixing it.
- I think the most important question right now is do you implement AI to sniff and injest everything on the phone and add it to your working model? (kinda not joking)
There's a full list of all the default connections made by GrapheneOS at https://grapheneos.org/faq#default-connections and a section below with a list of the non-default ones which may not be obvious to people. There's a lot of user configuration for it. That gives a good idea on how we do things.

We don't have any AI ourselves and if we did it would be 100% local based on the TPU hardware acceleration, but people can just install apps.
We don't bundle third party apps and services. We aren't very interested in developing any kind of AI software ourselves. Our approach to everything like that is people can install what they want.

Google apps including the Play Store and Play services can be installed and used on GrapheneOS but they're regular sandboxed apps on GrapheneOS with no special access via our sandboxed Google Play compatibility layer.
It's entirely possible to use the Play Store and a bunch of mainstream apps from it on GrapheneOS. It's also possible to entirely stick to open source apps like Signal or SimpleX for messaging, Organic Maps for local offline maps and so on. Android has a bunch of different app stores and a huge open source app ecosystem. We just leave all that up to users to determine what's best for them and make sure it works.
The only apps people can't use on GrapheneOS in practice are the ones banning using any non-stock OS or non-Google-certified device, mainly via the Play Integrity API. These are mainly a subset of banking/financial apps, location-based games and in rare cases other competitive games. These apps could use hardware attestation to permit GrapheneOS but are too lazy and we've only convinced a couple to actually do it.
- Ok, so I could have an entire degoogled experience (on the app level). Am I correct in observing that the only phones you support are Pixels?
There are no Google apps or services by default. You can choose to only use apps which don't depend on Google services or only open source apps. It's very usable that way, but that implies a major adjustment and learning curve.

There's the option to use Google Play as regular sandboxed apps but it's not the default. It opens up the option to use nearly any mainstream app. Many people use a dedicated profile for it.
Android has support for isolated profiles including secondary users, a work profile and a Private Space. Many of our users avoid Google apps and services, others simply use them as sandboxed apps in their main user and others in a dedicated profile.

We currently only support Pixels due to other hardware not providing good enough security and alternate OS support (requirements are listed at https://grapheneos.org/faq#future-devices).
We do want to support other hardware but that hardware doesn't exist yet. We aren't willing to give up features like a decent secure element with the standard Android Open Source Project APIs, hardware memory tagging and at least 5 years of proper updates. Current Pixels provide 7 years of updates from launch, which is a lot different from what Samsung and especially Fairphone mean when they talk about support time.
With Pixels, we regularly report security vulnerabilities, weaknesses and make proposals which they generally take seriously. As an example, Pixels implemented major improvements this year to defend against forensic data extraction. They added firmware reset attack mitigation in April 2024 which we proposed in January 2024. It cut off After First Unlock state exploits by XRY (MSAB) and Graykey (Magnet Forensics).
We published Cellebrite Premium docs at https://grapheneos.social/@GrapheneOS/112826067364945164 if you're curious. We have access to the latest January 2025 documentation too, but we don't publish it each month.

A summary is that GrapheneOS is successfully blocking their exploits but other Android OSes and iOS aren't. Pixel 6+ and iPhone 12+ successfully block brute force via secure element, no other Android devices do (most don't even have one).
We'll enthusiastically support more than Pixels when they provide what we need to defend users.

Since our focus is privacy and security, we really don't want to support devices where protecting users against even widespread commercial exploit tools is pretty much hopeless.

Ideally, we'd be working closely with an OEM making hardware built for GrapheneOS but for now Pixels are by far the best / only serious option.
- Got it. That's awesome! I appreciate the answers!
how long does grapheme generally support any given pixel model for? I’m also looking to find a phone that will become ewaste slower.
We fully support them as long as they have firmware, driver and other updates which for the past 2 generations of devices is a minimum of 7 years of support from the launch date.

See https://grapheneos.org/faq#device-lifetime.

You can see from https://grapheneos.org/releases that we've provided quite a lot of extended support past end-of-life for legacy devices but we strongly recommend not using extended support since it's not secure.
it’s super cool of you to have those extended support periods. There are probably plenty of people who are more sensitive to price or waste than having the absolute best security possible.
It's genuinely quite bad to be on a device with no firmware and driver security patches available. It's a significant portion of the High and Critical severity vulnerabilities. Firmware vulnerabilities are mostly only remotely exposed via isolated components where the OS can protect itself from being compromised through them but it still matters. We reluctantly provide extended support but it shouldn't be used.
Is there any alternative phone OS that has written their own drivers from scratch instead of reusing Android-intended blobs?
Android has little to do with firmware and drivers being open vs. closed source, firmware being signed in order to provide verified boot or how long the drivers end up being actively maintained. Drivers being in the mainline Linux kernel also doesn't mean they remain working or receive active maintenance including security support. That's just a common misconception and isn't how it works out.
Android devices have fully open source kernel drives in practice due to the Linux kernel being GPLv2 but that doesn't help without it being actively maintained. It doesn't mean they have to make their userspace driver libraries/services open source and the SoC companies like Samsung, MediaTek and Qualcomm generally have a huge open that's not open source. Nothing to do with Android that results in it.
> Drivers being in the mainline Linux kernel also doesn't mean they remain working or receive active maintenance including security support.

In theory it should, in practice there's no guarantee indeed.

I feel this is an issue that could've been mitigated by allowing things like Ada or Rust in the kernel sooner (the chances of getting it right the first time would be higher) or choosing a saner system architecture.

Regarding firmware, do most devices still fail to isolate between components such that compromised firmware can actually get results?
> Regarding firmware, do most devices still fail to isolate between components such that compromised firmware can actually get results?

Desktops generally fail to do it properly. Smartphones generally do it properly for the SoC components because the SoC vendor deals with it and there are higher expectations than the ones placed on Intel and AMD for desktops, and it's simply a cleaner platform.
> I feel this is an issue that could've been mitigated by allowing things like Ada or Rust in the kernel sooner (the chances of getting it right the first time would be higher) or choosing a saner system architecture.

Android kernel drivers are fully open source in practice. It doesn't change that they stop being maintained and no one takes it over. It's the userspace parts which often aren't.
The SoC companies love secrecy and view their code as having high value trade secrets, especially parts like the GPU driver library. Even ARM themselves doesn't release the Mali GPU library source code, only the kernel driver, and they essentially obfuscate the changes to the kernel driver by doing source code dumps without the repository history. Security backports are also not publicly released.
The strange aspect of this is that in order to maximize the amount of code they can keep closed source, they need to avoid putting it into the kernel driver. This has the positive side effect of pushing them to try to put as much as possible into userspace where it's possible to properly isolate it. Mainline Linux kernel drivers have the opposite incentive because the kernel doesn't ship a userspace.
Mainline Linux kernel development has a lot of pressure to put as much as possible in the kernel so it's available everywhere the Linux kernel is available. Not everyone uses the same userspace with it and they don't control shipping or updating userspace components at all. It gives a huge incentive to give code full privileges as kernel code instead of having as much as possible isolated in userspace.
It requires that companies release working code long before hardware is released and then it's going to be repeatedly changed by people not doing any testing of it. There are endlessly sweeping changes across the kernel which end up causing major regressions in drivers. It's often not discovered for years after and not necessarily ever fixed. It provides the illusion of very broad driver support.
A profoundly concerning outcome.

Alas, focus on correctness by design was absent when it was the time and now fixing that is unlikely.
If you've a Linux distribution on a laptop then you'll likely have direct experience with how regressions will keep coming and going. It applies more to rolling release ones but even the LTS kernel revisions have tons of regressions, although 'stable' distributions historically haven't shipped LTS kernel revisions much or at all. Ubuntu has even tended to use non-LTS branches for what they freeze.
It isn't simply that things don't work due to not being developed or tested in the first place. They regularly stop working. There's no active maintenance and development for a huge portion of the drivers but rather just people making changes to them without testing it to keep it building as the kernel APIs change. Some companies maintain drivers upstream and can review it or fix it afterwards.
It's not actually reasonable to take the mainline kernels and ship a product based on them. Need to use an LTS branch, heavily test everything on specific hardware and fix a ton of things, particularly when it comes to less easy to test functionality such as power usage. Moving to a new LTS branch is very scary and needs a ton of testing and work to fix regressions. Pixels are doing that now.
The kernel.org LTS releases were increased from 2 years of support to 6 years mainly to help Android devices extending their support. They're now going to back to 2 years. Takes up to a year to stabilize and get everything fixed and then shipped so it essentially implies any reasonable device has to move to a new LTS kernel branch every year for their whole lifetime which Pixels should start doing now.
- This is all great insight and perspective! I appreciate you taking the time to type this out!
I get the security part here, not that much about privacy. iOS it's fully closed source, how do you know anything your phone is doing at any given moment ? Just the internet connection checks will probably ping Apple servers with every possible information about the device itself, not to talk about GPS.
Open source does not have magical privacy or security properties. It is not inherently more private or secure through being open source. It is also not inherently more understood by people. It's a misconception that having source code published means that any significant review actually happens. iPhones get far more external privacy and security research than incredibly niche products and devices.
The mandatory services on iOS along with opt-in / opt-out ones can be directly compared to what's covered at https://grapheneos.org/faq#default-connections and https://grapheneos.org/faq#other-connections. GrapheneOS is certainly better in this regard. It's also certainly better than iOS or other Android variants at VPN support. It's certainly far better than other Android variants at providing privacy from apps, but iOS is very good at doing that.
It's quite clear cut that iOS provides better privacy from apps than the latest Android Open Source Project (AOSP). GrapheneOS eliminates a lot of the advantages it has especially with Contact Scopes (which is better than theirs) and Storage Scopes. We provide useful privacy protections from apps they don't offer but that's true the other way around too. We're gradually eliminating the areas they do better.
I see, thank you for the clarification! I am definetely out of the loop in audit and researches on iphone, I will check it.
From open source code I presumed it was at least easier to understand basic functionaliy of the system, of course doesn't mean privacy nor security.
I ran a FP4 with vanilla LineageOS. Rock solid. However I have now upgraded to a Pixel 8a with @GrapheneOS. It is also rock solid, but much better generally in terms of security.

My only gripe is that the hardware profits Google who I detest. I purchased the phone secondhand to mitigate that.
It's very different when it comes to stability, privacy and especially security.

Recommend the third party comparison at https://eylenburg.github.io/android_comparison.htm which is focused on privacy.

Fairphone devices are extremely far from hardware we could support due to major security flaws. Summary is no secure element, old SoC, months of delays for patch backports, years of delays for full updates. More details at https://grapheneos.social/@GrapheneOS/113845809289449075.
That's not to say that Fairphone devices are the worst. There are plenty of less secure Android and other devices. Fairphone devices with either of their stock operating systems (not LineageOS or /e/OS) are still more secure than plenty of low-end Android devices or a Pinephone. Fairphone is not the worst, they at least comply with minimum Android Compatibility Definition security requirements on paper but screw some up.
@tinker@infosec.exchange out of curiosuty, what's the argument against graphene os on a last-gen or used bought pixel?
Dieser Beitrag wurde bearbeitet. (3 Monate her)
- Pixel was made by Google and I have no clue what's running in the baseband processor.

Google touched it and I don't like it. (I feel like a toddler that wont eat mushrooms, but I can't shake it.)

¯\_(ツ)_/¯
wrt to baseband compromise concerns.. The pinephone pro (for example) does have hardware disablement switches for cell/WiFi/BT/GPS (nice!) although I'm not sure how robust app compartmentalization is under the various OSes currently available for it, without a lot of custom effort. Relative to pixel 8+, you'll miss out on stuff like MTE, which definitely does catch some badness. Not sure what's right or wrong for your situation, but maybe some factors to consider.
Dieser Beitrag wurde bearbeitet. (3 Monate her)
Pinephones have much less secure radios without proper firmware security updates and much weaker isolation from the application processor. The switches for provide a way to turn it off but the same security concerns apply if you ever use it. The cellular radio is a particularly strange designed for Windows laptops which runs a very outdated proprietary fork of Android next to the actual cellular radio basement on a CPU. The radio is basically a very low-end smartphone SoC.
One of our hardware requirements is having good isolation for components like radios (https://grapheneos.org/faq#future-devices). It would be nice to have an audio recording kill switch but it needs to be done differently than the Librem 5 or Pinephone to work properly. Speakers need to be blocked from being used as microphones and sensors usable as basic microphones need to be tied to it too. It's a minor nice to have feature for future GrapheneOS hardware but not a hard requirement.
Fairphone is a solid choice. One buddy went with it. If you want, I can buy a fairphone and ship it to you. Some shop may do it for ya, if you call them live ;-)
- If I can assure that it runs on US carriers, I might strongly consider that!
Ah, I did not consider that one :-D

Also, if you'd allow a question: Why /e/? Why not CalyxOS (which I know for a fact runs on Fairphones). I didn't look into the issue much, being a GrapheneOS user, but I never really understood the eOS.
/e/OS and CalyxOS are fairly similar. See https://eylenburg.github.io/android_comparison.htm which we linked elsewhere in the thread. /e/OS is directly based on LineageOS and CalyxOS heavily uses code from LineageOS so they're not that much different in that regard. Both use privileged microG integration, have similar apps and services bundled, etc.

Fairphones don't meet our most basic hardware security requirements which is why we don't and won't support them unless they ever do that which is unlikely.