I've used Lineage without MicroG, as a comparison, and that's becoming more-and-more unusable every day some lousy Android developer tethers their company's app to some feature exclusive to Play Services.
Also, why would Google bother backdooring their special HW when 99.999% of its users are anyway gonna be running a totally Google-controlled proprietary SW stack?
Ummm. Was this sarcasm that went over my head? Because if not, I have a hard time thinking of anything that requires as much trust as your private key storage.
Doesn't the existence of FHE downgrade that to just "complete practical trust" at least? Not that I know of it being employed, but that it could be, and that it may be worth shouting out exactly cause of how niche and impractical it is.
Going down the rabbit hole of secure hardware leads you down a slippery slope of eventually needing to create your own chips. And that's basically impossible these days for anybody smaller than Google or Samsung. So you do some research, pick the best you can, and hope for the best.
Perfect is the enemy of good.
Google Pixel hardware provides nested virtualization, enabling a Debian Arm "Linux Terminal" in pKVM/AVF VM, with use of Debian package repos.
Instead, I installed CalyxOS and have been using it over a year now and I'm very happy with it. Check it out.
I would recommend checking out https://eylenburg.github.io/android_comparison.htm for a third-party comparison of these projects. They're not really similar.
CalyxOS downgrades security compared to the Android Open Source Project, often falls significantly behind on standard Android privacy and security patches as is the case right now (they still haven't ported to Android 16 which is required to have the latest patches) and doesn't provide similar privacy or security features.
Features like Contact Scopes, Storage Scopes and our Sensors permission toggle are some of the privacy features includes in GrapheneOS.
Privacy necessitates security. The security provided by GrapheneOS is in order to be able to protect privacy.
Depending on where you are in the world, there might be other NFC payment options for you.
In the EEA and UK, Curve pay works. Paypal made their own solution and is rolling it out, starting with Germany. Both work with GrapheneOS. Many banks also have their own solutions.
Rossman lied about stopping using GrapheneOS and has continued using it after that point.
The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
He has done similar things to others, labeling them as insane and delusional.
There are some corrections that we have contacted the author about regarding the history of the project. They initially e-mailed us to ask a few questions but seems to have maybe misunderstood something.
For clarity, GrapheneOS is the continuation of CopperheadOS, not a new project that spun off from it.
As an example, it can be seen that our repositories and legacy bugtrackers are ours:
-https://github.com/GrapheneOS/platform_manifest/forks?includ...
-https://github.com/GrapheneOS/platform_bionic/forks?include=...
-https://github.com/GrapheneOS-Archive/legacy_bugtracker/issu...
It's a direct continuation, but was renamed to GrapheneOS post the failed takeover attempt. GrapheneOS has persevered and is all the stronger for it. Over a decade now. :)
However, we're currently working with another OEM and are hoping to have a device of theirs meet our requirements that can be launched in 2026 or 2027. Nothing set in stone, but we're optimistic thus far.
The unfortunate thing is that they make security promises which aren't upheld in practice (such as shipping security updates on time), so it doesn't inspire confidence as an OEM you could trust to properly support a device for multiple years.
We're hoping that there will be people who will enjoy a device from the OEM we're in talks with - we know that there are many people who for various reasons don't want a device from Google, so this will at least offer an option for people who want to use GrapheneOS on a non-Google device.
Much like you don't hear the sound of a busy city until you go somewhere truly quiet, you don't remember owning your own brain until you evict all of the entities who have been living rent free in it.
Keep doing the great work you're doing: it's making people's lives better in dramatically more significant ways than most software.
I do some watersports and always take my phone with me, so letting emergency services see my location is good for my safety in case I ever got into trouble on the water. I also have a PLB, but I like to have two devices for redundancy, as is best practice.
> Hardware memory tagging
I had to Google this. Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag? Or are you only interested in the memory safety benefits? Regardless, why target requirements that even most desktop computers don't meet?
https://discuss.grapheneos.org/d/8439-mte-support-status-for...
> Hardware memory tagging is going to provide a massive increase to protection against remote exploitation for GrapheneOS users. It's the biggest security feature we'll be shipping since we started in 2014.
Open source software is everywhere. Do you think Microsoft or Redhat going to be held to account if they accidentally added some backdoored OSS code? Moreover all of the development happens in the open and you can build it yourself. I'm not sure what the alternative is. Just trust Apple has their shit together with iOS?
At least hidden profiles would be good enough for basic protection.
They have this which wipes your device, but you can get killed under duress. https://discuss.grapheneos.org/d/14722-using-duress-password...
At the risk of doing their work for them, that seems like a near ideal partnership opportunity for graphene, so it’s extra sad to see.
It's important to note that GrapheneOS is not some niche barely-used project. It has existed since 2014 and is used by multiple hundreds of thousands of people at this point. There are also many eyes on the project through people forking it to make their own products, people maintaining their own builds etc. GrapheneOS is also reproducible in addition being open source.
On our side, we are very particular about accepting outside contributions if they don't need meet our standards, and code is heavily reviewed within our team before being merged.
I'd also recommend giving https://grapheneos.org/faq#audit a read through.
All in all, your concern, while valid, isn't something that's likely to happen precisely because we're very aware of situations where it has (see xz) and are therefore very vigilant. The kind of thing you're worried about isn't likely to come from a big project like GrapheneOS that has many eyes on it, but rather something small that's used everywhere and barely has a couple of devs working on it, if that (again, see xz).
I rather have this hidden profile that would stop 99% of criminals than what they have now.
I think their approach to this project is to deliver real security at the cost of features.
We think there's a good chance a motivated adversary is going to be familiar with GrapheneOS and its features, and the more mainstream it becomes, the more this can mean "your abusive significant other" rather than someone at the border.
The moment people know this feature exists, it can become dangerous even if you don't use it. You can be threatened to unlock, and even if you do, the adversary can choose to not believe you since they can think you're just hiding it. That puts you in a dangerous situation where they think you can provide something that's literally not there.
It's a very difficult problem to solve, and we don't think that proposal can solve it.
It provides the ability to tag 16 byte granules of memory with 4-bit tags where only pointers with the correct tag can access the memory. This provides an approximation of memory safety very useful for security.
As an example of how it gets used, our implementation of the system allocators via hardened_malloc tags each allocation with a randomly generated tag excluding the adjacent random tag values and previous random tag value for the slot. It has the standard setup of a single statically reserved tag (zero) used for free memory but adds 3 more dynamic exclusions. This provides deterministic detection of small overflows, linear overflows, many forms of use-after-free and fallback to probabilistic detection of other spatial (bounds) or temporal (use-after-free) memory safety issues. We use a lightly modified variant of the standard MTE integration for PartitionAlloc in our Vanadium browser, but we plan to improve it to match hardened_malloc. We use the standard Linux kernel implementation for the internal Linux kernel allocators which needs a lot of improvement.
> why target requirements that even most desktop computers don't meet?
Desktop computers are far less secure than an iPhone or a Pixel with the stock OS. GrapheneOS exists to provide a higher level of privacy and security than those. GrapheneOS is primarily aimed at mobile devices which are almost entirely 64-bit ARM. Hardware memory tagging (MTE) is a standard ARMv8.5 / ARMv9 feature provided by every standard ARMv9 Cortex core. MTE is only missing with custom CPU cores or cache while cutting this corner.
Pixels are not the only devices providing MTE. Exynos and MediaTek have provided it and Snapdragon should be providing MTE starting at the end of this year. The only reason Snapdragon is late to the party is due to their custom cores/cache.
We're currently working with a major Android OEM towards multiple of their future devices meeting all of our requirements and providing official GrapheneOS support. They view all of our officially listed requirements as completely reasonable and a target they can meet for their next generation of devices.
The purpose of GrapheneOS is providing a high level of privacy and security, not making security less bad for devices people already have. Hardware and firmware security matters quite a lot and software security depends heavily on hardware-based security features including MTE. Nearly all GrapheneOS users buy a device to use GrapheneOS and that would still be the case if we supported several other devices. The vast majority of Android devices lack proper security patches for drivers/firmware, are missing important hardware-based security features and don't provide serious support for using another OS where the security features can be kept intact. Samsung's flagships are closest to meeting our requirements after Pixels but do not allow another OS to use verified boot, important secure element features and more. Samsung permanently cripples their devices if they're unlocked and voids the warranty, unlike Pixels.
The reason we're working with an Android OEM is because existing non-Pixel devices don't provide a base we can use to provide what GrapheneOS offers. It would be missing huge parts of the core features elsewhere and would be worse in significant ways than the stock OS. It would go against what we're trying to achieve to have people buy devices we can't properly secure. Long term support for drivers and firmware is also important because people use devices more than 3 years from launch in practice. Pixels get 7 years of proper support from launch, which is unique. A couple OEMs market their devices as having similarly long support but the updates are significantly delayed and far less complete.
We've had numerous opportunities to work with OEMs where they weren't able to provide our requirements. We simply aren't interested in having a far less secure device with GrapheneOS as the stock OS. We expect our requirements to be met, and we think the OEM we're currently working with is fully capable of providing what we need. It will hopefully be available in 2026 or 2027. The initial goal is not doing better than Pixels, just providing a competitive alternative for people who want to use GrapheneOS on another brand of device.
Let’s say someone have you at gunpoint, you can just give your mains profile pass.
If they don’t even know there is a secret profile you’re good to go.
You’re right, they might assume you’re hiding, but I’d say 99% won’t know what’s even graphene and from those who know I’d say they might force you and you can have 3 sets of bank accounts:
Main profile: 100 Secondary: 1000 Terriary: $$$
Also if you hide all traces of grapheneos would be safer too. Nobody even knows is graphene, so they can’t even check what features you have. Again we are talking about 99% of the criminals, not the tech savvy 1%.
I’d prefer plausible deniability like Vera crypt than what we have now.
From what I have observed, nobody is held to account when there is a software issue, commercial or open source.
I think the main problem is that people can be affected that aren't even using it, which is why it is such a big problem. You can't really hide it's GrapheneOS either, even just by virtue of the features available on the device, you'll be able to deduce what it is.
I understand the idea behind it but it simply isn't realistic to provide and can put people in danger - the very thing it's meant to prevent.
Google provided resources for the Linux kernel to extent LTS support for 6 years for their 5 year guarantee with the Pixel 6. It ended up not being needed since Pixels began moving to newer Linux LTS branches. The official Linux kernel LTS support is back down to 2 years. The 6 years was meant to benefit all Android devices but it proved to be too difficult to do well and it makes more sense to invest a far smaller amount of resources moving to new LTS branches.
Fairphone presents providing an Android OS release 3 years after it was released as providing 3 more years of extra support compared to an OEM releasing it in the month it was launched as their final update. That doesn't make sense.
They've repeatedly had blatant security flaws such as using publicly available private keys for signing the OS on the Fairphone 4. These issues are downplayed rather than being acknowledged.
There are important security features missing, but the main issues are the lack of proper updates and their approach to security flaws being reported and discussed.
Many Android OEMs are a better fit for a partnership with us and we're working with one.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a better thread about this than the one you linked.
When I say hide, again for 99% of the people. Splash screen, setting spoofing. Sometimes good enough is better than perfect.
And even if the attacker can see the other profile you can just say was your friend’s profile and it’s lost.
Or better, not sure if possible: export the profile in a file like veracrypt. Then when you need the profile import from this file and would restore the secret profile.
At the same time, we're in communication with an OEM to have some of their devices have official GrapheneOS support, so we're moving towards redundancy.
Cops say criminals use a Google Pixel with GrapheneOS – I say that's freedom
Cops in [Spain] think everyone using a Google Pixel must be a drug dealer
ICEBlock, an iOS Exclusive
https://github.com/GrapheneOS/os-issue-tracker/issues/1174
GrapheneOS supports E911 and has our own network location implementation you can enable which gets used by it. Unlike Google's implementation, our network location is based on location position estimation similarly to iOS. Unlike iOS, we'll be providing full offline support for it.
you got it wrong way around
the CONSUMER criteria is "we want better independent security ON DEVICES WE ALREADY OWN"
complaints like in this thread are symptoms of unfullfilled demand - and they can't be solved by saying "oh gosh, what a stupid demand that doesn't agree with our supply"
I didn't bring this up when it was a news story last month because there was a lot of cynicism in the thread, but I am genuinely curious. I am really grateful for both GrapheneOS and Google for creating a phone platform that Just Works for the essential stuff and that I can reasonably recommend to non-technical people!
[0]: >>44259921
If the threat model is hiding from random people, I think a hidden profile works very well.
Now let's talk about motivated adversary as you put it. Hidden profile and wiping are not either-or, they can coexist. If one is really targeted by a motivated adversary, it should be apparent in most cases, and the targeted person can choose to enter the wiping PIN instead of the secondary profile PIN.
Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
[1] https://9to5google.com/2023/11/20/lineageos-number-of-device...
Reading some comments here regarding hidden profile, security through obscurity doesn't and will never work. Add to that the fact that GOS is well known now, those people think that if they were forced to give their phone away, they won't have to disclose the hidden profile??? Newbies!!
I don't wonder why GOS team never bothered to prioritise this.
I have been using GOS for a few years now, it is perfect, full control over everything, the teams support is like no other and full transparency about everything, the release notes are like no other.
I really hope this project will never die.
Unfortunately, Rossmann turned out to be very dishonest, which in retrospect makes sense, seeing as he has no issues with using Kiwi Farms. He's verified account there is named "larossmann". I suggest you look into it.
It's not just something he's done with GrapheneOS and the founder of the project. There are many videos, such as the one he did on Linus from Linus Tech Tips where he similarly misrepresented things and ascribed mental health labels on them.
Regarding CalyxOS, I would recommend people check out https://eylenburg.github.io/android_comparison.htm as a third-party comparison for various projects, including GrapheneOS and CalyxOS. They're not similar projects.
We're of the opinion that there's a growing portion of the population that is becoming more security and privacy conscious, and that's reflected in our userbase, which has been growing consistently over the last few years.
We're not saying we're going to have iPhone's marketshare, but we're constantly growing.
>Now if one is targeted by a really motivated and threatening adversary, I don't think wiping PIN is any better than secondary profile PIN. The moment one chooses to wipe the phone, the adversary could be triggered by the action and harm the victim anyway.
Yes, but at that point, the data is irreversibly rendered inaccessible. There are situations where the data itself is the most important factor, and where the owner of the device being hurt doesn't benefit the adversary now that the data is gone. Of course, as with everything, it depends on one's situation, but the duress PIN feature doesn't involve trickery. It's a way to reliably and quickly do a very specific thing.
GrapheneOS typically ports to new yearly Android releases in a couple days and tends to have it reach the Stable channel in under 2 weeks. We completed our initial port to Android 16 in a similar time period after the release on 2025-06-10. However, we then had to reimplement device support in a similar way to how we would support a non-Pixel device. Our initial production release based on Android 16 was published on June 30th. As usual, we had to spend around a week making a series of releases fixing regressions reported by users. It reached our Stable channel on July 8th.
Since our port to Android 16 took significantly longer than usual, we backported most of the Android 16 firmware, all of the kernel drivers and parts of the userspace device support to our now obsolete Android 15 QPR2 branch and did a few more releases based on Android 15 QPR2 where we were able to provide the full 2025-06-05 patch level which also turned out to be the full 2025-07-05 patch level due to no vulnerability fixes in the July 2025 Android Security Bulletin or Pixel Update Bulletin. This was an unusual approach and not generally a reasonable way of doing things. We were able to do it successfully.
It won't be nearly as much of an issue going forward since we dealt with building the new automation we needed. Our port to Android 16 QPR1, Android 16 QPR2, Android 16 QPR3, Android 17, etc. shouldn't be nearly as difficult and we should get back to our typical porting time for major releases.
The older I get the more examples I've come across of a person destroying their reputation by either self-over-exposure (social media) or just basic exposure via news of some outrageous or illegal behavior.
I don't have a problem with whatever line you choose to not cross, and I was once much more self-righteous, but I've more recently pretty much made the conscious decision to separate product from producer, art from artist, etc.
Theo Lengyel was recently arrested for murdering his girlfriend, and yet I will still listen to and enjoy Mr. Bungle's music.
Gary Glitter... I still like the song Rock n Roll Part Two.
J.K. Rowling has some controversial views on transsexual women, but that doesn't mean that the Harry Potter series is any less worthwhile reading than it was before.
ReiserFS
I still buy Nestle Quik occasionally
Steve Jobs, Bill Gates, Mark Zuckerberg, name almost any tech bro... (but not Steve Wozniak, he's a treasure)
Sports stars.
Musicians.
I wonder how many other things are worthy of protest if we knew all the facts about all the people who were involved in it's creation.
(I'm attempting to respond to the general concept of "he/she/they bad = it bad", not commenting on GrapheneOS vs CalyxOS or anyone's personal choice over where / what they choose to apply "he/she/they bad = it bad" to, other than saying that it should be a conscious decision not a reflexive reaction)
Currently you can only keep it on the main profile or any other secondary, which are easily visible.
With my approach you can minimise 99% of the risks for most users.
And even so, you can have 2 hidden profiles. So you can always show the decoy hidden profile.
Android and Chrome are potentially going to be split from Google:
https://www.nytimes.com/2024/11/20/technology/google-search-... (https://archive.ph/egRL4)
Pixels are no longer the Android reference devices. An Android company ending up with the OS, Google Play and Google's OEM partners wouldn't need Pixels. That's a possible reason for the change. However, the simplest explanation is that they're continuing to take cost cutting to an extreme where it negatively impacts their long term revenue far more than the money it saves. A lot of Pixels were sold due to first class support for using other operating systems including it not voiding the warranty.
I bought a second hand Pixel 7a for my recent migration. Battery isn't great, but it's good enough to get me through a day.
I see some core team on this thread, so just wanted to say THANK YOU! Awesome job! Keep fighting for the users!
I'm totally the wrong person to offer recommendations on mobile, but so far it works very well for me, but then, I use almost no third party apps, and none of them are Play store only. My only complaint is the hardware (outside of their control).
I think of two things, the Solar Winds build corruption, and putty's mishandling of e521 keys.
What is your vulnerability to a similar disaster, exploited or not?
So Graphene is actually not limited to the developed/western world. As for not supporting other devices, I believe the reason could be the team size and the fact that the fragmented Android world is known for unique shenanigans of every OEM. Besides Google's update/upgrade cycle is another reason it is an appropriate choice.
Oh god, yes. Please! I can't wait to leave the walled fruit garden, but can't tolerate Google sniffing everything I do or do not do on my phone either.
PS. I just hope it's an OEM that sells devices to a lot of countries including developing ones and not something like Fairphone.
For a corporate using an OS in work phones. The threat model is state/corp-sponsored actors. Trade secret leak is unacceptable. When in doubt, data should be wiped. Now wiping PIN makes total sense and is the only sensible option.
An ordinary person, on the other hand, often deals with non tech-savvy ordinary people. The threat model is different. Most likely plausible deniability is enough. The threat level is low. Those users may accept to trade some data security for a more friendly feature.
The ultimate question is whether Graphene envisions itself an opinionated OS that always follows the "best practice" or a generic OS that allows users to define their own threat models.
The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
I wonder if Google actually has an internal version of Android that's more security-focussed. Given that critical engineers' personal devices being hacked should be a security threat that's on Google's radar, it's possible.
The only technical limitation I have encountered using these ROMs is related to GPS: my position is often lost and I need at least multiple minutes to gain it back (or sometimes it never comes back, depending on where I am). This is likely related to not using Google's location services, even though I have turned on all settings like using WiFi / bluetooth to improve the location accuracy. I tried every advice I found online, without luck. Somehow the issue is a bit worse on Graphene, as my position is lost every time I close the Maps app, but it may be related to the phone and not the OS.
[1] https://discuss.grapheneos.org/d/475-wallet-google-pay/4
If the only thing protecting you from getting shot to death is a bulletproof vest, clearly a lot has already gone very wrong, and you're likely to die today anyway. But that kind of thinking is exactly what leads to a failure to defend in depth.
The Google Pixel requirement also makes me sad. I understand that they have solid reasons why. The problem is Google is incapable of selling their phones worldwide. It's really embarrassing for Google and unfortunate for me.
At least graphene wouldn't be expected to shield the perpetrator.
With SEV-SNP and Intel TDX I think it's possible to build a hardware platform that doesn't require the user to trust the OEM although they still need to trust at least one large American tech company that controls the root of trust.
But I don't think this is ever gonna happen for consumer devices. AFAIK it's only sorta kinda happened for any real-world platforms at all (but maybe someone can correct me).
Ultimately if your threat model includes Google as a potential adversary, and you are not in control of nuclear weapons, you are gonna have to make some serious sacrifices to achieve security IMO. Smartphones are out. (Actually, I guess if you trust China you have a way forward).
vendor: not possible
you: unfulfilled demand
me: the way I see it, you get a product for free if you fulfill certain conditions. If not, you buy these conditions.
I recommend putting proprietary Play Store apps grabbed with Aurora Store in the work profile with Shelter[5].
[1] https://obtainium.imranr.dev/
[3] https://f-droid.org/packages/com.aurora.store/
[4] https://f-droid.org/packages/de.marmaro.krt.ffupdater/
So then what's the point of having a Play Store without Google Play services?
Also "private space" is now available with Android 15 and can provide the same separation within a single user profile.
Aurora Store - Anonymized frontend for Playstore
F-Droid - Open Source App Store
Obtainium - App Store for other sources (e.g. github)
Organic Maps - Open Source navigation (not as good as proprietary ones though)
SherpaTTS - Text to speech for Organic Maps
PDF Doc Scanner - Little Trickster, Open Source document scanner
Binary Eye - Barcode reader
K9 Mail / FairMail - Mail client
LocalSend - Cross Platform File Transfer
Syncthing Fork - Catfriend1 Syncthing fork to sync files
VLC Media Player - media player
KOReader - ebook reader
Voice - Paul Woitaschek, local audiobook player
AudioBookShelf - Remote audiobook player
Immich - image backup
Fossify File Manager - file manager
Substreamer / DSub - Audio streamer for navidrome self hosted server
OpenCamera - Open Source camera app
In any case, thank you for all the work so far!
You have to be aware that you give that person root when you use Graphene. All possible technical improvements aside this is a very big risk. He claimed he would step back after the video released, then called that a lie and continued with everything.
Calyx seems to be the best alternative right now without such a risk factor.
Signal brings its own notifications, so they work perfectly.
The only app which was broken to the point of unusability was Too Good To Go, which demands that you pick locations on a map which relies on Play Services; the manual city entry is broken.
I use Google Maps only in Firefox Focus, but I've heard that builds of Google Maps up to about a year or so ago didn't rely on Play Services, and with Aurora Store you can manually enter a build number to install.
tl;dr: 10/10, fabulous experience.
Pixel 8 works amazingly with Graphene's new network location feature. Position fixes are SO MUCH FASTER. It is truly a gamechanger. First it was Wi-Fi only, but they just released cellular location as well. They provide a proxy to Apple's location services.
Install Droidify, enable the repos, and install "microG Services" and "microG Companion".
Why lie about something so easy to disprove by a bit of research? There were a bunch of articles about this back then, even wikipedia states it clearly.
https://grapheneos.org/faq#future-devices
As a large company, they are probably targeted through their devices and since they have the means, it does make sense that the Pixel devices have high security standards compared to other OEMs.
Is there any chance that you fabulous guys could lobby for a smaller <5 inch phone with that OEM? (reference >>44586723 )
Can you clarify what can one expect from legacy extended support. Will old devices get any more updates? how long, how often, is it just security patches etc..
Thanks for you hard work!
GrapheneOS can attest to the device's security. The question is whether the app developers will trust such an attestation. Will they put money, time and effort into evaluating and trusting GrapheneOS? Of course not. They will just decide to trust nobody except Google and Apple.
This is the future. We'll be discriminated against. Can't even log into an account from an "unauthorized device". Their servers will just refuse to talk to our phones if they can't cryptographically verify that we have not "tampered with" them. We'll be refused service straight up unless our computers are straight up owned by corporations.
This so called "integrity checking" is meant to protect the corporations from us, not the other way around. It's so we can't do things like hack our way around their "policies".
But there is still no way to reset/spoof android device ids, and the apps can reliably identify the user after reinstalls.
I am personally more than okay with using the official, proprietary GP services from time to time if they abide by the same rules, especially that I can make these rules as strict as I want.
You just don't know what will happen is what I'm saying.
The "he has root" is also a reference to ubuntus shuttleworth.
There is an option though: Heliboard with a custom swipe configuration applied (which is apparently sourced from Google, I'm not sure how "grey" that is).
It definitely works as a swipe keyboard, but it's just not as good as GBoard. I will persist, however. I hope that it's learning at least...
While I don't think the developers necessarily hallucinates being attacked (i.e. given the nature of the project, I would expect them to be persons of interest, be it from surveillance agencies, or even state actors), the main issue with Rossmann is their claim that he is either personally directing harassment against GOS, or colluding with and encouraging other communities to harass (mainly Kiwifarms, Techlore, CalyxOS, and other Android related FOSS projects). This claim seems to originate then cascade from Rossmann leaving the comment "Informative, but unfortunate" on TechLore's video criticizing GOS's leadership. This is taken as explicit support of TechLore community's / KiwiFarms alleged harrassement on the lead GOS developer, and this has somehow been cascaded and blown out of proportions, and considered by GOS developers as evidence of Rossmann's wrong doing against them.
As mentioned somewhere else, I am using GrapheneOS since 2 or 3 years now, based on Rossmann recommendations. The software is very good, pretty much native Android experience, but without the extra alleged Google snooping / root access. Rossmann himself seemed to have stopped using it as his main device because of fear of retaliation given that the GOS devs could potentially target him. Better safe than sorry. I still use it because I am not that high profile of a person, and generally will use throwaway when it comes to discussing anything GOS related at this point. The overall leadership however, based on Rossmann's and later my personal interactions with them however, did leave a bad after taste.
At the time, Rossmann was mainly using GOS, but due to what he perceived as hostile behavior from GOS toward him through their communication, he opted to stop using GOS (at least on his main device, as he claims).
His rationale was that the behavior of said lead developer was not "rational" and "scary", and since the developer has not only edit access to GOS code but also update publishing infrastructure, Rossmann's data or himself could be targeted through malicious code pushed via an update, for example. While GOS is opensource and malicious code or exploits could be detected by the community, he himself did not have confidence to audit the source code to make sure it was safe, hence his decision to stop using.
By risk factor, I think the grandparent suggests that something similar could happen to someone else using GOS, the risk factor being essentially at the mercy of GOS developer, would they wish to harm said user.
In fact, a core aspect of security is having access to a feature in the very first place.
A forum, being hosted on the web has absolutely no reason to stay away from the de facto scripting language of the platform. What would be your threat model for that forum? A zero day that would break the whole world?
You can have the best alarm system in the word, if you leave the back door open and anyone can just walk in from the street.
Fossify is a FOSS project with a handful of volunteers and they do take donations:
if (user is rossmann) {
// do bad things
makes me think who is paranoid here.
Beyond that, the GraheneOS team still controls a single signing keychain for all phones in the wild, which we have to assume is still controlled by Daniel Micay (strcat) as it has not rotated as far as I can tell since he mostly stepped away from public view.
He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness. Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I can't recommend GrapheneOS for any high risk use cases until:
1. they are able to find a device they can run 100% open source code on with no binary blobs
2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly
4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
Over and again people on HN make the following argument: "Google is a company that makes most of its revenue from ads and surveillance. Therefore, you should always assume that Google is spying on you". But somehow when it comes to Pixel people give it a pass?
Prediction: If Pixel isn't already hardwired to phone home and report on your activities, it will slowly become so over time, as Google realizes its interest. You know, as it happened with Android, Chrome, and everything else that Google touches.
Note that a community fork done by some core contributors was just spawned: CoMaps [1]
> K9 Mail / FairMail - Mail client
And now there's Thunderbird, which is branded version of K9 Mail IIUC (I don't know if there's any reason to switch from K9 Mail to Thunderbird for existing users)
It's not about criminals. It's about the police, government spy agencies, and other knowledgeable threat actors.
I wish that were true, but if you delete the 100s of binary blobs (many with effectively root access) copied from a stock donor vendor partition the phone won't function at all.
There is no such thing as a fully open source and user controlled Android device today.
Check if yours is on the list.
As for the personal aspect, the lead developer is definitely not the best representative of the project from a communication perspective as he might not have that kind of social skills (based on his posts). [1]
But he (Micay) is an excellent security researcher, and has an excellent track record when it comes to prioritizing his users. There was a sponsorship in the beginning, where the legal entity, CopperheadOS tried to hijack the whole project. But Micay rather kill the project, than let the users' security suffer and revoked the signing keys. And I'm sure such a betrayal would cause anyone to lose a lot of faith in others' actions.
> Give that person root
Complete bullshit, what root?! And if anything, you are the one who are trying to discredit a project here, by sharing some dumb clickbait video.
[1] I see that there is now a project manager doing most of the communication, which is an excellent solution!
I'm not an expert, but baking telemetry into the hardware (or at least the kind of telemetry that I assume Google is interested in) seems like skipping a few levels of abstraction, and thus more trouble than it's worth.
They write about their reasoning and criteria for device support here, for example: https://grapheneos.org/faq#future-device.
You mean who tried to hijack the project in a very questionable direction, harming their users, he rather lighted the project on fire then let the users' security be compromised?
If anything, that is the greatest compliment you could give him.
Also, this is fud that he can push any kind of code, like you can easily check any part of the pipeline.
They hear their favorite influencer spout something, and they parrot it everywhere. Google bad, hurr durr.
Your CopperheadOS description is one perspective, one that does not look all that believable now after his mental illness became clear.
I did not share the video, but I would and it is not clickbait.
I will not further respond to you, I don't think this would lead to a fruitful discussion. Kindly think about what kind of trust is necessary to trust in the proper functioning of a device as personal as a modern phone, and think about attack scenarios that could occur when the main developer of your OS is not trustworthy in the slightest.
After opening the application, it complains about being installed through an "insecure method", and bails. Reinstalling through Google Play magically fixes that.
These "security checks" are spreading like measles, so expect to see this sooner or later.
I am alright with things that allow for improvement, at least in theory
> we're currently working with an OEM to have their devices have official GrapheneOS support.
Depends on your threat model. If Google, low-effort scam apps or being profiled by apps are your only adversary, then that's true. If random threats on Internet or APTs pwning your phone, or being forensic-proof are part of your threat model, then Calyx is strictly worse than stock.
Rossmann himself has no confidence to audit the code, so why take the risk ? Good enough reason to be "paranoid", or at least feel uneasy about it if you ask me.
On one hand, sure it can be a compliment. On the other hand, it only increases the perception that he is could enact significant harm if he ever comes after you.
> Also, this is fud that he can push any kind of code, like you can easily check any part of the pipeline.
Who is "you" ? Neither Rossmann, neither me (software dev albeit not in cybersecurity), and even less so the average GOS user, and I would venture to guess that neither you can audit GOS code with enough confidence to declare that the risk of an exploit or backdoor being introduced is zero. Open-source is not a guarantee that code or software is secure (for e.g. CVE in xz utils and many such cases).
Edit: some clarifications.
Even more FOSS friendly graphics vendors like AMD and Intel rely on binary firmware.
I did do about three weeks of research, as I worried that maybe a number of apps wouldn't run on it or needed some form of deep attestation. Didn't find much, OpsGenie and other work apps are happy with the GOS level of attestation provided.
Great to have Google kicked off the phone. So nice to shut off the network permission for any apps that only require an internet connection to serve ads.
One tip from me, if you came from stock Pixel: You can download the default Pixel sounds and set them up like it was. Have a look for "Your New Adventure" online, the message sound is "Eureka".
And if your whole business is a secure OS, it's a very risky proposition: you get caught doing this once, and your reputation is gone forever.
> It doesn't matter that the app is trustworthy, because F-Droid are extremely incompetent with security and the apps you install from F-Droid are signed by F-Droid rather than the developer.
https://discuss.grapheneos.org/d/20212-f-droid-security-in-s... https://discuss.grapheneos.org/d/18731-f-droid-vulnerability...
They also say, if you use F-Droid, at least use F-Droid Basic:
> Dont use the main F-Droid client. Android is pretty strict about SDK versions and as F-Droid targets legacy devices, it is very outdated.
https://discuss.grapheneos.org/d/11439-f-droid-vsor-droid-if...
> If the app is only available on F-Droid / third party F-Droid repo, use F-Droid Basic and use the third party repo rather than the main repo if available. > > If the app is available on Github then install the APK first from Github then auto-update it using Obtanium. Be sure to check the hash using AppVerifier which can be installed from Accrescent (available on the GrapheneOS app store).
https://discuss.grapheneos.org/d/16589-obtainium-f-droid-bas...
By the way, while GrapheneOS recommends Accrescent, I don't use it anymore because they can't even add apps like CoMaps, while some of the apps they actually added are proprietary.
Different use cases. User profiles are only active when you manually switch to them, while work profiles are active _alongside_ your main profile.
So for untrusted apps that you only use occasionally and on-demand (like the myriads of travel / shopping / random services apps), user profiles are great. For apps that you want to keep in the background, such as the proprietary messaging apps that all your friends use, a work profile is much nicer.
The only problems you might run into would be some features might require privileged access, things like Now Playing. Makes sense because normal apps cannot have unrestricted access to the microphone like that. Google Wallet works, but you cannot make payments because the app refuses to work on alternate OSes.
Besides that kind of stuff, though, I've used all sorts of Google apps without issues.
I bought a Pixel 9 Pro Xl specifically to use with GrapheneOS. Unfortunately, its OLED and my eyes were incompatible. The PWM on the screen was terrible and I had to return it after some headaches.
Of course, none of that was the fault of GrapheneOS. I absolutely loved using it and think your project is vital.
Not "pixel compact", but the size of an iPhone mini.
What about Graphene ? Can I get 5 years of updates without needing to wipe the phone ?
For those of us who aren't ready to cut the umbilical cord to the mothership, you can also root/firewall on normal android to stop this. In fact I choose to not be able to use banking apps in order to cut out the crappy ads.
https://grapheneos.org/faq#baseband-isolation
Sure, it's not perfect, but it's still really, really good. Even with the binary blobs that are on it, Graphene phones have been impossible to unlock via commercial cracking tools since 2022.
https://osservatorionessuno.org/blog/2025/03/a-deep-dive-int...
I do not use banking apps (I only use banks that allow me to log in via browser using a 2FA which is not a proprietary app, like a FIDO key or other physical dongle), but do I get it right that Revolut would allow me to pay via NFC in this case? Is this something geo-dependent?
But I'm still left a bit confused about the future devices GraphaneOS will support:
Because you said discussion are being done with an OEM, will GraphaneOS switch from pixels to a different device?
You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?
Thanks again!
> extremely hostile and threatened Rossman
At the time, he was very upset. You know, because he was swatted multiple times. Of course he was upset when Rossmann showed his true colors and was trying to talk to him. Rossmann saw this as an opportunity and recorded it as it was happening. He tries to portray Daniel as crazy and people who attack the project and his friends on Kiwi Farms lap that stuff up.
It's not true that he stopped using GrapheneOS, though. He continued using GrapheneOS for months after that video, which you can see by watching his later videos.
> hallucinates
Repeating baseless claims that he's crazy.
> You have to be aware that you give that person root when you use Graphene.
What? This is a very strange way to say it. Either way, it's literally impossible for someone on the GrapheneOS team to target someone like what was claimed in the video. GrapheneOS devices don't send identifiers when they contact the update server. The update servers also only host static files.
> Calyx seems to be the best alternative right now without such a risk factor.
The "risk factor" is completely false. It's all made up to attack GrapheneOS, making the founder look like a crazy person, then people are scared of using the OS. CalyxOS is not a hardened OS and rolls back security in some ways. It's not the next best alternative for people who care about these things.
But he didn't. It's clear in his later videos that he was still using GrapheneOS, I believe even for months after the video.
> Better safe than sorry.
People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files. If Rossmann was really that worried, all he'd have to do is use a VPN. But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
https://grapheneos.org/articles/attestation-compatibility-gu...
> Of course he was upset when Rossmann showed his true colors
I saw the chats. You lie. Showing his true colors = not accepting that there is an evil conspiracy and asking for proof. You are completely brainwashed and I will not continue this discussion.
If Calyx is not the next best alternative be invited to link to what you think is the best alternative. I still think it's Calyx.
That doesn't seem like a con if you take into account the context: F-droid is not shipping pre-build binaries from the developper, it asks for a buildable project from the developper.
If the source repo of the upstream dev are compromised, so will be hid own binaries anyway.
That's because apps that aren't published just on the Play Store but also on other stores or for direct sideloads (for users running Huawei for example which doesn't have Play Store) need to be able to detect the installation method to do updates on their own if there is no backing store.
Here you are again in yet another comment repeating these baseless claims about mental illness.
> think about attack scenarios that could occur when the main developer of your OS is not trustworthy in the slightest.
First of all, he's not the main developer. There are multiple developers. The other developers do most of the development work these days.
But to say that the OS is untrustworthy is completely false. You say GrapheneOS's founder has a mental illness based on watching a video where someone turned malicious toward the project recorded a conversation where the founder was extremely upset after being swatted multiple times.
The update client doesn't send identifiers when checking for updates, and the update servers only have static files saved to them. You're making stuff up here, and clearly trying to turn people off of using GrapheneOS by repeating baseless claims that the founder is crazy and fake worries of being targeted by them.
Not to get too deep, but contemporary philosophy posits that our phones have become extensions of our brains (not only theoretically, but literally! See e.g. Andy Clark and David Chalmers, “The Extended Mind,” 1998). Our devices have access to profound parts of our lives— our habits, friends, desires, notes, thoughts… With something this fundamental, it’s vital to have privacy.
Thank you, Graphene team, for all the hard work you do.
This isn't even possible given how updates on GrapheneOS work. The update client doesn't send identifiers to the update server, and the update server only hosts static files.
Rossmann either doesn't understand this, or he made it up to get more views, or possibly to entertain fellow Kiwi Farms members.
To be honest, I don't think that he didn't understand that he couldn't be targeted. He continued using GrapheneOS for months after the video. As I understand it, it was clear in a few videos months after the initial video was published.
GOS doesn't use an account, so the code would have to perform very targeted heuristics in order to verify this is Luis' phone. It would have to compare his sim number against a known one, or dig into application data to find his logins and compare them against known emails. So the only way to not write `if (user is rossmann)` would be to send various diagnostics over the wire, to a service that contains these identifiers and perform the comparison onlinr, meaning he would introduce an imense security whole into everyone's phone, and everyone would see there is a home calling.
So it's either a patch of if user == rossmann, or a home calling patch.
It comes with some minor usability issues with captive Wifi portals sometimes, but the trade-off of not having ads in app or while browsing is way worth it IMHO.
Unfortunately my home server, which I was using for backups, was flooded and before I replaced it my phone died and I lost a lot of data...
Are you sure that you are not just misinterpreting the upgrade instructions?
For the S10 a mandatory wipe-on-upgrade has last been the case when upgrading from versions _older than LineageOS 21.0_.
During the time where LineageOS 20 was the current version there was no requirement to wipe listed at all, so presumably it didn't exist then.
> Well, he can do everything to your phone, software and data by pushing software updates.
Other developers are doing the bulk of development work these days, so this is nonsense.
> Paranoia could result in just making the system more secure, but why not add a backdoor to find the spies in your userbases that communicate with the black suited men that secretly run our government?
Again with the baseless claims that he's crazy. Your argument here is that "he is crazy, so maybe this happens too." It's nonsense. There are no backdoors, and if there ever were any backdoors, they would be found. GrapheneOS isn't some small project that nobody knows about. It's famous for being very secure, even famous people have said publicly that they use it or others should use it. Cellebrite cannot even hack into it. Backdoors wouldn't go unnoticed. This is also nonsense.
You provided exactly 0 sources in all of the comments I've seen posted by you so far.
> Showing his true colors = not accepting that there is an evil conspiracy and asking for proof.
"Evil conspiracy"? You say that someone else is paranoid and yet you are saying things like this? It's kind of ironic.
> You are completely brainwashed
Okay. If you say so.
This does not make sense at all.
But that would be incorrect. It's not possible for anyone from the GrapheneOS project to target a GrapheneOS user that way. Look into how updates and the update servers work.
> neither you can audit GOS code with enough confidence to declare that the risk of an exploit or backdoor being introduced is zero.
The updater app is pretty easy to read through. I think a software developer would be able to understand it. The update servers' setups are also very easy to understand. It doesn't take a software developer genius to figure these things out.
Apart from migrations concerns, which are not GrapheneOS' fault, the main shortcoming I see is the lack of proper backup/restore, e.g. when switching phones. There is Seedvault, but I've found it unreliable.
I have an old Pixel 5 which I stopped using because Google dropped Google Pay (tap to pay) on it. I moved to a new device (Pixel 9) for daily usage but still have the 5 laying around (due to low resale value).
At the time I moved, Pixel 5 was about 1.5 years (November 2023) beyond Android security updates. I still love the form factor (more than the bigger 9 I use now) and it has much more life left in it. I'd quite like to use this as a backup device for basic utility (camera, phone, SMS, basic read-only web use) and to take with me for runs and travelling.
Would installing GrapheneOS on this device likely make it more secure? Do Graphene releases work the same on all devices, or is it sort of device-by-device basis?
SuperCards: stores shop loyalty card barcodes
KeePassDX: password manager
ReadEra: eBook reader
Magic Earth: another maps app
Vivaldi: power-user's browser
JuiceSSH: SSH client
Termux: like running a Linux term
AntennaPod: podcasts
Regarding NFC payments, the apps themselves refuse to run on non-vanilla OSes due to spurious security concerns and Google's maneuvers behind the scenes, but there are reports that Curve Pay works, at least in the UK.
Having recently gone through the F-Droid release process, I learned that this is not necessarily the case anymore.
F-Droid implements the reproducible builds concept. They re-build the developer's app, compare the resulting binary sans signature block, and if it matches they distribute the developer-signed binary instead of their re-built binary.
This is opt-in for developers so not all apps do it this way. I'd sure like to know how common this is, I wonder if there are any statistics.
This isn't really a practical way of doing it. Google Play and Google Play Services having privileged access is more than sufficient.
I'll give it an install tonight. I'm curious to play around with it anyway and if I make minimal use of it, it should be pretty secure by it's use case.
> Fuzion24 / platform_manifest Created 10 years ago Updated 10 years ago
My point is that from Rossmann's perspective, being target of the lead GOS software dev hostile behavior as per his "Why I deleted Graphene OS" induces Rossmann's --> perception <-- that the GOS could go after him if he really wanted to. First, everyone is busy and has their life, suggesting that his spend hours going through code and documentation he is not familiar with to make sure he is not target is moot. Most people don't read TOS, and same goes for Licences and docs of OSS. Between doing that and stop using it as it's main device OS, the easier choice is the latter. As a software dev myself, your expectation of layman being able to navigate something like a code review, or even an investigating an exploit is hardly reasonable.
So it is not "incorrect". I am not even saying Rossmann could be targeted. I cannot even make this claim as I have not gone through the docs nor understand the build and update pipeline, which is kind of my point: I can't be bothered neither for GOS, nor for the most of the FOSS software I use. The majority of OSS user rely on the vague concept that motivated and honest people audit the code, but hardly anyone is going deep dive into how an arbitrary piece of software works.
The main issue is the attitude of that GOS developer, whether they like it or not, taints the confidence in the project. it does not matter if Rossmann can or cannot be targeted technically.
The issue here is not technical but a reputation issue.
> The updater app is pretty easy to read through. I think a software developer would be able to understand it. The update servers' setups are also very easy to understand. It doesn't take a software developer genius to figure these things out.
Even then, it could be argued that the rules in place could be changed to introduce malicious exploit if the lead dev(s) were motivated enough. Especially given GOS relatively top-down structure, relying essentially on a benevolent dictator. Even if I made the effort, then ascertain there was no vector attack, now I have to stay on alert every commit / release version and spend as much time looking for a targeted exploit ? etc... Update server setup might be clean, but an admin could SSH or gain access in some way or another and do rogue changes, were they determined enough. The probability is not zero.
Again, the problem is eroding the trust of the specific user (Rossmann in this case).
I don't have to elaborate techniques. If a determined (and potentially mentally unstable) developer decides to leverage their full control over the OS to make it happen can. I don't have to elaborate on the techniques which might or might not exist yet. Stuxnet only targeted specific Iranian systems, a needle in a hay stack, was spread did not harm random devices across the globe, and stayed mostly undetected. And this was done without "developer access" to the software itself. Is it hard ? Yes. Is it likely (especially given the knowledge of how GOS works) ? Perhaps not. Is it impossible ? Definitely not.
When the lead dev of the OS you use daily threatens to "publicly expose you" as a user, I won't blame said user to stop using the software. And even less, to provide such data point regarding the behavior of that developer.
What kind of issues did you have? I think it does require google play services (which can be installed easily).
I have used GOS on a pixel 6 for the past two years with no issues. The phone finally died on me last weekend, so I'm in the market for a new pixel which will be getting GOS right away.
> Rossmann either doesn't understand this, or he made it up to get more views, or possibly to entertain fellow Kiwi Farms members.
Expecting a layman to know that is not reasonable. The argument is not about the GOS updates work in practice. It is about the "perpection", from Rossmann's perspective that the lead dev of the OS is hostile against him. Humans are not purely rational machines, and given the choice of either 1) spend hours auditing source code and updates pipelines (every release ?) and 2) stop using it for critical purpose, the latter is the easier choice, especially for a busy person like him.
> To be honest, I don't think that he didn't understand that he couldn't be targeted. He continued using GrapheneOS for months after the video. As I understand it, it was clear in a few videos months after the initial video was published.
For all we know, he is using it on his secondary device where he has removed what he deems critical. Again, Rossmann NEVER said "don't use Graphene OS", or "Graphene OS lack security" or anything of the sort. If anything, even after that video, he kept recommending GOS whenever he talked about privacy.
His argument is that he did not feel safe knowing using software from a hostile developer; and that he can't be bothered / not qualified to audit the code well enough to make it worth it (which is reasonable if you ask me, and I dare say most people).
Edit: > Rossmann either doesn't understand this Again, I agree with you here. He does not understand. He trusted the developer(s) to know what they are doing, but they broke that trust by being unreasonable, to say the least. He is under no obligation to understand. As for what you stated after that, I won't comment on it as I don't read minds, and pretty sure neither do you.
I only mentioned NFC because you mentioned Google Pay.
Emphasis on "seemed to have stopped using it as his main device". For all we know, he kept it as secondary device (its just that good) after removing anything he deemed critical. Again, he never said "don't use GOS", or "GOS is not secure". He said he was did not feel safe enough because of the hostility from the lead dev.
> People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files. If Rossmann was really that worried, all he'd have to do is use a VPN. But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Does it matter ? Rossmann is a layman when it comes to software. What he perceives is that "lead GOS dev is hostile against me and has essentially full control over the project". First, he is under no obligation to spend hours learning how GOS updates work and audit the code every release, whether or not some identifier is being tracked or not (and by the way, you can still get identified and tracked even if you use a VPN). The damage was done once that lead GOS dev persist in toxic behavior, for the lack of a better word.
> But that was all just a huge dramatic act so his video would get more views, and possibly to entertain his fellow Kiwi Farms members.
Unsubstantiated claims. We cannot read his mind, and I have yet to see any evidence that would support these.
> Graphene's new network location feature
I believe it uses https://beacondb.net/, which is starting to have fairly decent coverage, at least in large parts of Europe. You can contribute to BeaconDB even if you have an ordinary Google phone by installing https://github.com/mjaakko/NeoStumbler.
I use LineageOS myself (because Graphene no longer supports my Pixel 5), and unfortunately it doesn't do network location out of the box. You can get network location on LineageOS by installing MicroG, but it's currently somewhat flaky.
As opposed to "being free in all senses of the word", which is what the comment was talking about.
All I said is sourced.
So just give me that alarm system for my tent, please. It will do fine for my case.
> People who are familiar with how GrapheneOS updates work wouldn't agree. No identifiers are sent to the update server, so targeted updates aren't possible that way. Also, update servers only host static files...
We are literally talking about an OS here. It has an almost total control over your phone - what does it matter if the updates can be targeted? The GOS could snoop on their users and turn into malware only if it figures out that this is Rossmann's phone.
This is what is keeping me from installing GOS too. Interaction from the developers seems very aggressive towards the competing OSs, which doesn't inspire much trust. Who is reviewing the GOS changes? Are they really all benign? In the end you need to trust someone, but I'm not sure GOS is more trustworthy than LineageOS (which has a bigger community, more developers and /e/os building on top of them).
Happy to be convinced otherwise.
Chromium still is the superior browser in terms of security and Firefox is way behind. Adding an extension so you _might_ have less security exploits in the foundation is a wrong tactic and should be avoided.
It all seems like a security theater with the consequence that, ooops, we just vendor locked in all our customers to run a less secure OS by a company whose business it is to collect personal data and show ads that people don't want to see.
Lol. I hope you like working with geese, but be careful, they can't be trusted!
Also, you are pretty much factually wrong on a bunch of items on your list. GrapheneOS still has room for improvement of course, but they are very ahead of anything else on every aspect. And where you are not factually wrong, you are just unrealistic. There is no 100% open-source hardware, period. This is complete "what color you want your dragon to be" category.
During a call, drag your buttons and they will scroll. The call recorder is the 7th button.
Moral of the story: Different contexts allow for different solutions. It is a sign of false privilege to make assumptions, and not let the user decide. An argument can be made in terms of priority of implementation, but not in terms of "pointlessness". The often used argument of "false security" can be addressed by warnings; yes, some people may not understand the implications, but you do not need to make their own (bad/good) choices for them; that's paternalism, not care.
In the real world, where thanks to my political work I am in contact with many people who had to endure real-world security checks, police raids, investigations, and so on, in all the cases no proper (imaginary) forensic analysis was performed. People make mistakes and remain uneducated -- on both sides. The "But NSA!" argument brought forward typically by white techbros kills a lot of useful technology before it even exists, which is unfortunate for those that would actually benefit from it, and when asked would tell you so. It's also not either/or in reality: In many situations, it will buy you time (while e.g. your lawyer may try to get you and your devices out of the situation), and even if they find out you were trying to fool them, they may give you another chance, and then you can still opt for the wipe code. It makes a huge psychological difference to have multiple options and feel in control.
It looks like there's an app on F-Droid called "Rethink" that promises to do both firewalling, DNS blocking, and offers a WireGuard VPN. That seems promising, though I must add that I haven't tested it myself.
And now you're running a two year old phone and it's effectively obsolete.
If they would just upstream their firmware into the Linux kernel, you could upgrade these phones for years and years. Until the hardware is actually physically incapable of running the latest features.
Some vendors, like Google, promise to provide updates for a long time. But it's just that - a promise. There's no technical guarantee or mechanism for this, it's purely based on trust.
- Adding your card to Google Wallet. - Using a banking app which actually implements payments via NFC.
Many banks used to implement the latter, but dropped it in favour of "just use Google Wallet". In the Netherlands, it seems to be all of them. This varies a lot per region.
I believe that the "just use Google Wallet" banks are the ones that don't work.
Also (as others have mentioned): many banks perform integrity checks, to ensure that you're using a software chain signed by Google.
It's the responsible thing to do. Apple has done it a few times.
The only real option for privacy and security which isn't swiss cheese.
You might want to try:
- writing the city name at the beginning
- putting the street number at the end
Note that OSM might not have the street number. If it doesn't, searching for it will fail for sure.
You should probably file an issue: https://codeberg.org/comaps/comaps/issues
See note at the bottom here: https://github.com/microg/GmsCore/wiki/Installation
Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
Has anyone else done the same?
Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
all of the privacy and security parts of the UX are good, though.
It's a catch 22. Support other devices, the software won't work as well or reliably or maybe buggy - users get pissed off.
Spent the time to make it not buggy on other devices = now you're doing mor dev work than even Google.
Yes.
> Do you think we wouldn't see it in our network logs?
If it's done on the baseband processor, no.
I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
But yes - your phone has a separate SOC, with its own operating system you can't access, which communicates with cellular networks. We don't know what, exactly, it's used for or what, exactly, is being transmitted. We do know it's used for location tracking because this is utilized by law enforcement somewhat regularly. But cellular triangulation isn't too accurate, not like precise location services.
With the right hardware choices running blob-free linux is pretty straightforward.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
> Has anyone else done the same?
I did end up going for a Pixel + GOS. Although it is conterintuitive to use a Google device to get away from Google, according to GOS developers themselves, the Pixel series were the only devices that met their strict requirements for security.
From personal experience, been using it for almost 3 years now, and it gives you 95% of the benefits of Android while giving you back control over your phone, and being generally more secure.
Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
On the other hand, the functionality is top notch. Easily the best integration of consumer level DNS + firewall blocking in any application on any platform. Just block everything of an application by default and then watch the connection logs for the app and start unblocking stuff via ips, domains or wildcards until the app starts working again.
I run a b2b tech company in Silicon Valley and have not carried a smartphone in 5 years or had an LTE subscription in 6. I have a family and hang out with friends, mostly tech workers, at least once a week. I am online when I am at my desk or one of my family PCs, otherwise I am offline. It has been a massive productivity boost, attention span boost, and social improvement in every way.
I don't miss hours of doom scrolling a day and missing out on being present with friends and family. Took a few weeks to rewire my dopamine engine so the FOMO went away.
Phones -are- optional and if you think otherwise you might be an addict.
> CalyxOS, which not only suffers from the same "problems" you criticize in GrapheneOS, but is also inferior in every way when it comes to security and privacy?
It is better in one way: a reasonably stable person holds the keys to the kingdom. Personally I do not like having -any- central person controlling my devices, so I just opt out of Android entirely until that situation changes.
I am a supply chain security researcher and founded a Linux distro where no single computer or maintainer is trusted, so trust decentralization, freedom, and control in software are very important to me.
Geese? That is offensive. I raise chickens.
I also run a successful tech company, and have a full EE lab, several full server racks, and more tech in my home than anyone I have ever met.
Phones are completely optional in modern society. We have just convinced ourselves we need them because doom scrolling and constant notifications are addictive.
Print your boarding pass, ask for paper menus, pay with cash, and arrange times and places to meet people and then actually be there on time. The rare times you really need to do online work on the go, bring an actual computer with a real keyboard. Free wifi is everywhere.
Works just fine, and as a bonus your time away from home becomes mostly invisible to marketing firms.
That is the most disingeneous take on the video. The claim this kind of commenters that freely carry water for the toxic GOS (ex-?) lead developer is the exact reason why Rossmann made the video. The evidence is all there for the public to see. Daniel does not get to essentially harass people he disagrees with after they have been asked to not contact them, threaten them to "publicly expose them" and get away scott free.
Being a genius at cyber security or autistic does not give one a free pass to treat other like garbage.
> The video was made to direct harassment towards the project and founder after the project refused to work with Rossman.
The video was made to expose the harassment of the project founder toward Rossmann, when the former contacted him out of the blue with frivolous accusations after they parted way a year earlier due to un-reconciliable disagreements.
> He has done similar things to others, labeling them as insane and delusional.
No evidence provided, as usual.
The Precursor is promising, but software is not there yet.
I sit down at my desktop computer and send emails and type messages like this one. Then I get up from my desk and spend time with my family offline and present. It's pretty great.
PassAndroid: to open apple/android wallet files (airplane/cinema tickets etc.)
Find My Device (FMD) on F-Droid: replacement for the google version, works via sms commands or a self-hosted app
AntennaPod: Podcast App
Breezy Weather: with multiple weather sources, great uiFor more context, there was a Google Drive link that is unfortunately not available anymore, but I found and uploaded it here: <https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>
It has they initial conversation and disagreement in September 2022, after the GOS developer in question accuses Rossmann of being complicit with harassment campaigns again said dev., because he also gave the same 40K USD FUTO grant to other similar project and had some interview with their developers.
The second set of files are the text messages that feature in the video, after said GOS developer contacted Rossmann umprompted on May 2023 with the same type of accusation.
Feel free to peruse and make you own opinion.
It has they initial conversation and disagreement in September 2022, after the GOS developer in question accuses Rossmann of being complicit with harassment campaigns again said dev., because he also gave the same 40K USD FUTO grant to other similar project and had some interview with their developers.
The second set of files are the text messages that feature in the video, after said GOS developer contacted Rossmann umprompted on May 2023 with the same type of accusation.
Feel free to peruse and make you own opinion.
For example, installing an app on Google Play works like F-Droid. Once the download finishes, you have to open the Play store app to trigger a system dialog to accept the installation. On other Android devices, GPlay can install apps without your approval.
Is the camera with GrapheneOS as good as the stock android one? I get to use my wife's iPhone camera sometimes and it frequently shocks me how good and responsive it is. But I'm coming from a OnePlus 8 Pro, which never had a great camera in the first place.
There was a youtuber who got kidnapped in Haiti a while back, and his kidnappers demanded to search the photo gallery on his phone for something. So what he did was delete the pictures, but not empty the trash, hoping they wouldn't know about that feature. They didnt, and he got away with it. Did Apple envision a kidnapping scenario when they were designing that feature? Probably not. Is there a design lesson that can be taken from that situation? Also probably not, because it just as easily could have gone the other way.
"AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google." [0]
Emphasis on independent of any particular hardware.
Current speculation/inference suggests it is because of the antitrust case against them, preparing for the possibility that they may be divested of Android (or at least to decouple in meaningful ways [1]).
[0]: https://www.androidauthority.com/google-not-killing-aosp-356...
[1]: https://www.bloomberg.com/news/articles/2024-11-18/doj-will-...
https://grapheneos.org/faq#device-support:~:text=The%20follo....
Ahaha, don't get your hopes up, friend. The possibility of an adequate, degoogled Android with picky requirements as GOS on good, ultramobile hardware (matte DCI-P3 IPS, 3.5 mm audio, USB-C 3.2 or better, dedicated, ideally quick-access mSD card slot, IP68 rating, good cameras, EMR pen compatibility, changeable battery, non-plastic case) is virtually nil. That would essentially be a modern hybrid between a Samsung XCover Pro 6 and one of the older Samsung Note phones, e. g. the Note 9. Days long gone... :(
And even if you install Google play on your graphene phone, it is still more isolated by default. Add that to the concept of storage scopes and more permissions control (apps have to ask for access to the network) and you have a more secure platform.
I think the Pixel Tablet was a matter of a week or two.
There seems to be two challenges though that popped their nasty head lately. Some developer being temporarily unaivalable due to personal issue, and something about Android Open Source Project (GOS is built upon it, to put it simply) not necessarily support upcoming Pixels.
But the team seems resilient and motiviated to keep the project going.
JuiceSSH is still under development?
I stand corrected. Do you have plans to switch to BeaconDB when the coverage in the USA improves?
Sure, but that requires additional data about the user, which the GrapheneOS update server doesn't get. Both the update client and the update server are open source, so you can verify any of what I'm saying. The server only sees the user's IP address, which device model they're requesting an update for, and which update channel (alpha/beta/stable) they are using. The HTTP headers, etc. for the request would be identical across any GrapheneOS device, as they use the exact same updater app.
https://github.com/GrapheneOS/releases.grapheneos.org https://github.com/GrapheneOS/platform_packages_apps_Updater
> First, he is under no obligation to spend hours learning how GOS updates
That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.
That sums it up perfectly
The docs for compilation are neat so I'm running my own build with my own signatures and my own repository of their AppStore for my third party apps that I also build from source.
I run only those apps on the main profile and then keep a private space (set to autokill on lock) for proprietary apps that require Play Services.
Both the update client and the backend are open source, just like the rest of the system: https://github.com/GrapheneOS/platform_packages_apps_Updater https://github.com/GrapheneOS/releases.grapheneos.org
Our requirements are not at all exotic or outlandish, the fact that most OEMs don't meet them says more about how far behind most OEMs are, rather than our standards being unrealistic. We've also been told that they're not unrealistic in practice from numerous OEMs who want to build a device that meets our requirements.
It is also important to note for Pixels specifically that since the 8th gen Pixels, they receive 7 years of support. Additionally, they partner with iFixIt to provide official replacement parts for the duration of the device's life. I'd say that's pretty sustainable, especially when you consider that the Fairphone doesn't actually provide proper support for the amount of years they claim, since they have consistent delays in providing patches.
Which Nvidia card do you have, and at which clock speed does your GPU run?
> With the right hardware choices running blob-free linux is pretty straightforward.
Unfortunately no. Features like SSE are pretty amazing and have made CPUs really fast and efficient, but they're unfortunately also large attack vectors, so vulnerabilities like Spectre or Meltdown occur. You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
Again, that is beyond the point. The developer going rogue (for arbitrary reason) and turning the code malicious is not impossible.
> That literally takes a few minutes to look up, it's all really well documented on the official website. https://grapheneos.org/faq#default-connections
All of you who keep commenting "But it's so easy, just look it up" are lacking consideration and empathy. Other people don't think like you, they don't have to think like you. Just the documentation you have linked has so many technical terms, someone not familiar with networking and system design will barely make any sense of it.
It is a also a matter of trust. After the developer express their hostility multiple time, even if someone was willing to go through it, what if the documentation is not forth coming ? It is within the devs control after all. How does one even make sure that the software does what the documentation says it does ? etc...
> But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.
What "absurd" claim did he put out exactly ? His issue was never about the technical aspects of GOS. It was about the broken trust and the perception that using software from a hostile developer was a risk factor, hence his stopping using it (at least on his devices with sensitive info).
You should watch Rossmann's video on Linus - he has a habit of doing these hit pieces.
A collaboration with an OEM doesn't mean we'll stop providing existing or future Pixels if they continue to meet our requirements.
You can use Google apps and apps depending on them on GrapheneOS via sandboxed Google Play. The vast majority of Android apps can be used. You don't need to stop using Google apps/services or other mainstream apps to use GrapheneOS. It's likely nearly all the apps you use or even all of them work on GrapheneOS. There's a per-app exploit protection compatibility mode toggle (and finer-grained toggles) to work around buggy apps with memory corruption bugs. We avoid turning on features breaking non-buggy apps by default and hardware memory tagging is temporarily opt-in for user installed apps not marked as compatible due to how many memory corruption bugs it finds.
A small number of apps are unavailable due to checking for a Google certified device/OS via the Play Integrity API. These are mostly banking apps, but most banking apps do work on GrapheneOS. There are tap-to-pay implementations which can be used on GrapheneOS in the UK and European Economic Area. Several banking apps recently explicitly added support for GrapheneOS via hardware-based attestation as an alternative to the Play Integrity API. We're pushing for more apps to do this and for regulation disallowing Google from providing an API to app developers for enforcing devices licensing Google Mobile Services. Play Integrity API often portrayed as a security feature but Google chooses not to enforce a security patch level. They're permitting devices with years of missing important privacy and security patches but not a much more private and secure OS. Only their strong integrity level has a patch level check, but the check is only done for recent Android versions and only requires they aren't more than 12 months behind on patches which serves no real purpose.
> you can also root/firewall on normal android
This is different from our Network permission which not only blocks direct access but also indirect access via APIs requiring Android's low-level INTERNET permission. Our Network permission also pretends the network is down through many of the APIs. For example, scheduled jobs set to depend on internet access won't run.
Some apps require Google's FCM for push notifications. You need to install Sandboxed Google Play services from the GrapheneOS App Store and grant them unrestricted battery access (so they can run in the background, which is required for maintaining a network connection to FCM and delivering notifications). https://grapheneos.org/faq#notifications
Other apps like Signal use their own background connections, for example WebSockets, to deliver push notifications, but keeping a connection open for each app consumes more battery life than just having one background network connection. Also, not every app supports this.
For Signal specifically, the GrapheneOS project recommends either using FCM via Sandboxed Google Play, or installing Molly (https://molly.im/), a fork of the Signal client for Android, which makes some changes to reduce battery consumption when using WebSocket-based notifications. It also allows you to use UnifiedPush (https://unifiedpush.org/) for notifications instead, but that requires an application called mollysocket (https://github.com/mollyim/mollysocket) running on a server.
We also expect Google's Play Integrity API to inevitably be ruled as anti-competitive, which it is.
He never called Linus "insane" or "delusional" as the parent post claims, hence the request for evidence.
He (rightfully IMO) criticized some of his business practices (Honey, BilletLabs, "Trust me bro"), and quite a few more controversies which LTT was embroilled in.
He criticized Linus' behavior and lack of accountability based on his personal interaction with him, as well as publicly available evidence. At worst, called him a narcissit. If anything, he is vindicated by all the LTT apologies videos (one of which Linus and other staff even make puns and sponsor placements ...) that follow up each controversies.
Any more specific evidence you think show that "Rossmann has the habit of calling random people insane and delusional". I am willing to bet you have none.
Our recommended devices can be found here:
In Sweden we typically use Swish, which again works great.
"Tap to pay" things are problematic though but it's not something I personally use (even before I migrated away from stock Android).
Ah, that might be it. My current version is 21.
> If your device is running LineageOS version older than 21.0, wipe your data partition (this is usually named “Wipe”, “Format”, or “Factory reset”) .
https://wiki.lineageos.org/devices/beyond0lte/upgrade/
Yes ! Thank you, I can upgrade to 22 without wiping.
It's fairly pointless for apps to check for Mock Location being active without also verifying the OS via the Play Integrity API or hardware attestation API. Most apps checking for it are using or in the process of adopting the Play Integrity API. Apps enforcing the Play Integrity API basic/strong integrity level won't work on GrapheneOS unless they explicitly allow it. A growing number of apps doing this are explicitly allowing GrapheneOS. It would be counterproductive if our Location Scopes API didn't provide a way for apps to check if since those apps simply wouldn't permit GrapheneOS. However, it doesn't need to be the existing Mock Location API. It can be our own API which would only be used by apps explicitly choosing to permit GrapheneOS. This would allow apps like Pokemon Go and Ingress to permit GrapheneOS even if they insist on not allowing directly spoofing location.
SailfishOS is not open source itself. It's far less open source than Android which has the Android Open Source Project with the whole base OS.
However one must note also that for now not even Snapdragon fulfills GOS requirements. If/when that changes, Snapdragon devices may have more open-source community momentum than Google's Tensor. Plus all the economy of scale, etc..
In terms of security, Microtek is even more far behind Snapdragon.
Again, not an Android dev here, take the text above with a grain of salt, YMMV, etc..
>Vivaldi: power-user's browser
Propietary. Get Fennec with FDroid with Ublock Origin and some addons.
It's basically only useful for debugging.
Subscribe to comp.mobile.android. Sadly there's no libre client yet, but Mozilla might release a Thunderbird version with NNTP support.
GrapheneOS supports having a Private Space in secondary users instead of only a single one in Owner. Supporting multiple Private Spaces per user is a planned feature at which point work profiles will be fully obsolete. The remaining use case for work profiles is to have both a Private Space and work profile in the Owner user.
The process adds a significant delay for updates but it does not actually protect users from developers in any meaningful way. This real world example with WireGuard demonstrates that.
The Precursor is the only pocket computer platform that is maximally open hardware, software, and firmware but you revert back to the 90s in terms of power as a consequence with alpha quality software today. If Bunnie is successful with his IRIS approach and making custom home-user-inspectable ASICS then maybe a middle ground path can be forged in the next few years.
For now the only modern computing experience with fully open hardware and software I am aware of are the ppc64le based devices by Raptor Engineering, but at a very high cost due to low demand, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
For those that want this story to get better, please buy and promote the products of the few people trying to break us out of dependence on proprietary platforms.
Sadly this was, to your usual points, at the major expense of security making those devices purely research projects at best and not something anyone should ever actually use.
When you are stuck on a platform that requires closed firmware you are kind of stuck blindly accepting updates from the vendor to patch security bugs, stuck hoping they are not actually introducing new backdoors.
This is why I reject platforms that require closed firmware in the first place to the fullest extent I can.
GrapheneOS does not include sandboxed Google Play but rather includes an open source compatibility layer providing support for installing Google Play as regular sandboxed apps. They can't do or access anything more than other apps including the Google Play code running inside apps using Google Play which is the reason for choosing this design. It simply uses the same app sandbox and permission model which are both greatly improved by GrapheneOS for supporting running the rest of Google Play not bundled with apps using it.
Worth noting apps don't need Google Play services to use Google services and many Google libraries like Ads and Analytics work without it. FCM requires Google Play services but many of their libraries do. There are Lite variants of Ads and Analytics for keeping apps smaller which lose the ability work without Google Play services. The general reason for the design is they don't want to have huge apps and want to be able to update the clients for their services without app developers doing it and shipping an app update. FCM is one of the special cases requiring the central design for efficiency. UnifiedPush is an alternative with choice of implementation / provider.
Pixels will be supported until end-of-life. Future Pixels will be supported if they continue meeting our requirements.
> You also said that not having the device tree won't be a major hurdle in building GraphaneOS for the future, does that mean we can expect the pixel 10 to have GraphaneOS or it's too early to know ?
We expect 10th gen Pixels to meet our requirements and we should be able to add support for them. It's not going to happen in 12 to 48 hours from the official launch of the devices as we did for around the Pixel 6a and later. It will be more work. We've automated most of the device support for existing Pixels now and have removed nearly all of the Android 15 QPR2 device trees rather than manually updating them. We're continuing to automate more and will use that approach for supporting new Pixels.
The devices with an OEM partner are further in the future than the Pixel 10. We need Qualcomm's new SoC with hardware memory tagging support to launch because a flagship Snapdragon is the best fit other than the current lack of hardware memory tagging. Some things need to be addressed by the OEM including licensing extra things like Qualcomm and filling in some missing features. There needs to be a clear, workable plan for updates including Linux kernel LTS branches.
That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
If you are going to call me misinformed, please take the time to prove it so I can stop sharing information I otherwise have no reason to believe is incorrect.
> There is no 100% open-source hardware, period.
Multiple fully or mostly open hardware computers exist. They just cannot run android.
MNT Reform, Precursor, and Talos II are the top three that come to mind.
Those are lightyears ahead in openess and auditability compared to anything Google produces.
The table shows CalyxOS has substantial delays for important privacy and security patches. It currently doesn't provide the 2025-06-05 patch level. It's better than LineageOS and /e/OS in that regard but still reduces privacy and security through significantly delayed patches. CalyxOS also weakens parts of the privacy and security model through the privileged functionality that's added, which simply isn't covered by the comparison table.
> The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
On Pixels, CalyxOS is missing current Android privacy/security patches. GrapheneOS doesn't support those other devices due to lack of a reasonable level of security. Each of those extra devices has significantly delayed privacy/security patches and lacks important hardware-based security features. Despite all the marketing about long term support, Fairphone 5 uses Linux 5.4 which is end-of-life in December 2025 with no plans on their part to move to a supported kernel branch afterwards. Earlier Fairphones are stuck on older end-of-life kernel branches. Those devices are missing basic updates and security protections. Those don't provide proper long term support, so if someone does have one it won't be long before it's time to buy another device.
The issue is apps banning using a device not licensing Google Mobile Services or a non-stock OS via the Play Integrity API. Google Pay does this and a lot of banks outsource tap-to-pay to Google Pay instead of providing their own like many European banks. GrapheneOS users in Europe have multiple options. Users in the US often use a smartwatch for this purpose which includes the option of Garmin Pay rather than only Apple Pay and Google Pay.
The choices depend on the region. It would be nice if the Play Integrity API was forced to permit GrapheneOS via hardware attestation verification by regulators. We're pushing for it in Europe.
I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation. I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion. It's objectively clear though, that this is a very low quality video full of baseless speculation, and severely lacking any technical understanding and knowledge.
> What "absurd" claim did he put out exactly ?
His speculation about targeted malware in the OS.
This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
- it’s a lie
- not even a white lie, they know perfectly well, that they can do way more
- most of the security “features” are completely useless
- they also know this
However, it’s very difficult to prove these, and laymen don’t and won’t understand the details.
[0] https://grapheneos.org/features#vanadium
[1] https://github.com/gorhill/uBlock?tab=readme-ov-file#ublock-...
GrapheneOS is working with a major Android OEM towards their future devices providing the expected hardware-based security features and updates, unlike their current devices. The purpose of GrapheneOS is not specifically avoiding Google but if you want hardware from another large tech company to use with GrapheneOS, you'll have that option. The initial goal for these devices is providing a similar level of security and long term support to what we already have with Pixels. In the longer term, we want to have add hardware-based security features unavailable on Pixels or iPhones along with hardening below the OS layer.
For now, Pixels are the only viable option for us to use. We're actively working on changing that but we're not going to simply greatly lower our standards and support devices where we can't adequately protect users. There's no evidence of any backdoor and it's contradicted by how exploits are developed and used. There is plenty of evidence that other devices lack comparable security.
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... shows an example where only the Pixel 6 and later / iPhone 12 and later have brute force protection which holds up against the most sophisticated company developing forensic data extraction tools. We have access to more recent documentation showing the same thing.
Why do governments buy exploit tools from NSO, Cellebrite, etc. and develop their own if they supposedly have backdoors in devices? Why would using a device from Samsung or Sony protect against it if they did?
"Baseless" could not be further away from the truth. You literally have the GOS developer messages coming in live while he rehashes frivolous accusations and threatening to exposing him. To claim objectivity, when you seem to cherry pick the parts of the video that would (loosely) fit your narrative. Where is your evidence that Rossmann is in anyway associated to harassment campaign against the project ?
> This is exactly the same as going to a restaurant, having an argument with the owner, and then claiming that they might be putting poison in the food, even though there's absolutely zero evidence or anything that might indicate that, solely because you had a disagreement with someone and now want to harm their reputation.
Damn, so close, you were almost there. A more accurate analogy you could have come up with, had you actually critically listened to Rossmann's argument in his video. Yes, it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you. At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code. It might be unlikely given what we know about software dev, but it is not impossible, and for Rossmann, that is the only thing that matters at the end of the day.
Moreover, the GOS dev himself clearly stated he would "publicly expose him" (At 2:14 in https://youtu.be/4To-F6W1NT0?t=134 "and there will be information published about your (Rossmann) attacks on me in support of an abusive person). Why the double standard ? That GOS dev can go around dishing out "reputational harm" but his targets doing the same is not fair game ?
At this point, Rossmann did him a service by publishing everything himself. As far as any reputational harm is concerned, the GOS developer essentially brought it on himself. Could have dropped back when they had the fallout in September 2022, as per the chat logs (<https://www.swisstransfer.com/d/d75ff782-4a7d-4497-b04e-edd1...>) ...
> I would go further and say that it was his intention of harming the project's reputation, but that's just my personal opinion.
Sure, "harm the reputation of the project" when he was proactively giving them no string attached grants, spreading the word, and giving them an opportunities to tell their side of the story ...
> I'm quite certain that there are more people than just me, who think that someone with close to two million subscribers on YouTube should fulfill due diligence by doing some basic research and at least read the extensive official documentation that's provided, before putting out a video with serious allegations and a very high potential of harming someone's reputation.
Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
Linking is fine, as you did here: >>44686876 .
The baseband firmware is not obfuscated and people can/do analyze the cellular protocol and how it functions. Which devices receive more privacy/security research than Pixels do? Which devices avoid trusting multiple companies making the hardware? Nothing. Similar things could be said about any hardware we supported, but all the other available options supporting using another OS would be far less secure and unable to provide what GrapheneOS offers. Core features would be missing elsewhere.
We're working with an OEM to have their future devices meet our requirements and provide official GrapheneOS support, but how would that change anything? It's another big tech company making devices. What do you think is special about Google and what reason is there to think they would be putting a backdoor but other companies wouldn't?
> I believe grapheneos has some sort of band band processor isolation, but I'm not sure exactly how it works.
Isolation for the radios is a standard security practice on most modern smartphones. GrapheneOS improves the security of the isolation through hardening the drivers and services against exploitation after exploiting the radio firmware.
> But yes - your phone has a separate SOC, with its own operating system you can't access, which communicates with cellular networks. We don't know what, exactly, it's used for or what, exactly, is being transmitted. We do know it's used for location tracking because this is utilized by law enforcement somewhat regularly. But cellular triangulation isn't too accurate, not like precise location services.
The CPU, GPU and many other components in laptops, desktops, tablets and smartphones are closed source hardware with closed source firmware. Wi-Fi and Bluetooth are implemented with a separate processor and operating system. There's nothing about that specific to cellular and it's a misconception that it's different from other components in this regard. Modern computers have a bunch of processors and little operating systems across a bunch of components. Many people have the wrong idea that it's somehow specific to a few things like AMD PSP, Intel ME or cellular radios when in reality that's just how things are at a hardware level across many components. Cellular radios are normally an isolated component.
Cellular can be used to detect location, but so can Wi-Fi and Bluetooth. Wi-Fi is the main way network-based location works. Most Wi-Fi networks are from ISP routers and some even have an official way for other subscribers to use it.
Cellular doesn't need to be left enabled all the time. There's airplane mode. Using cellular is an option. GrapheneOS runs on portable computers with support for Wi-Fi, USB ethernet, etc. too not onlyg cellular.
If you are not running games (which you should not on a system you need to be able to trust) maximum clock speed from a modern GPU is not needed for most workstation applications.
I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
> You need proprietary microcode blobs to fix those security vulnerabilities in your CPU.
Really? Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation which has a fully open hardware motherboard and open CPU architecture?
I make different tradeoffs on different hardware to be sure depending on the threat model of the task I am working on. x86_64 is a bit of a shit show, but you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else.
Corrections/elaborations on some points : https://lwn.net/Articles/1031454/
Source: https://grapheneos.social/@GrapheneOS/114914602970489632
> Our community manager has provided a response to the recent LWN article on GrapheneOS with important corrections and context. The article had significant inaccuracies about the history of GrapheneOS, our organization and the details of what we provide. [.................]
Using GrapheneOS on it would be more secure than the stock OS but it's going to be quite insecure regardless of the OS so we'd recommend just not using it. The intention of our extended support prior to Android 15 and then legacy ex trended support following Android 15 was harm reduction for people unable to afford a new device yet. That's essentially over now. We just didn't remove it from the site yet to avoid complaints. It informs people that it's an insecure device at boot so it's better than people getting misled into believing the alternate OS they've put on it keeps them safe when it doesn't.
You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones
Most OEMs do the bare minimum for security. The security features they provide are the ones provided for them by AOSP, the SoC vendor, etc. They provide delayed and quite incomplete security patches.
Android downplays the fact that it has OS releases every month. There's a new monthly, quarterly or yearly release each month. The monthly Android Security Bulletin patches are a separate thing providing backports of a subset of the security patches (most High and Critical severity AOSP patches) to older initial yearly releases (the initial releases of Android 13, 14, 15 and 16). There are also a huge amount of SoC and other hardware-related security patches with a small subset included in the Android Security Bulletin. Most OEMs struggle to provide these backports and vendor patches on time for a reasonable time period. Non-Pixel OEMs eventually update to a new initial yearly release, usually quite late, then rely on the backports to it for a year or more. Full Android security patches mean shipping the latest stable releases, which have been through significant public testing beforehand for quarterly/yearly releases and are not actually bleeding edge. Quarterly releases are as large as yearly ones but awareness of them existing is low. Android 16 QPR1 currently in Beta has more user-facing changes than Android 16.
We're working with a major Android OEM towards some of their future devices meeting our requirements and providing official GrapheneOS support. It will be their regular devices but meeting our requirements currently only Pixels do. Hopefully available in 2026 or 2027. There's no reason other devices can't provide comparable or better security than Pixels, but it's not easy or cheap.
Fairphones lack proper security patches and OS updates from day one. /e/OS makes this substantially worse compared to Fairphone's own OS. Fairphone tends to lag 1-2 months behind on Android's standard partial security backports and a year or more behind on yearly OS updates. They skip the monthly and quarterly releases. Fairphone 5 uses the Linux 5.4 LTS branch which will be end-of-life in December 2025 with no plan to move away. Older Fairphones use end-of-life kernel branches.
Here's information from the author of the divested projects about /e/OS including data on updates from 2021 up until late 2024:
Issues with /e/OS: https://codeberg.org/divested-mobile/divestos-website/raw/co...
ASB update history: https://web.archive.org/web/20241231003546/https://divestos....
Chromium update history: https://web.archive.org/web/20250119212018/https://divestos....
Chromium update summary: https://infosec.exchange/@divested/112815308307602739
For the Chromium update summary from July 2024, note 128/135 was shipping each update on a given update path. /e/OS only shipped 12/135. They did not ship most Chromium security updates and skipped most releases. They're still skipping many releases and have significant delays for the ones they do ship.
Here's an article from another privacy/security researcher on /e/OS covering some of these issues:
https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...
As documented there, /e/OS has their own invasive services including user tracking in the update client. https://community.e.foundation/t/voice-to-text-feature-using... is another example where /e/OS sends user data to OpenAI without consent for speech-to-text compared to Apple doing it locally by default and Google at least supporting doing it locally and encouraging enabling it.
There's a third party comparison table at https://eylenburg.github.io/android_comparison.htm with a privacy and security focus. It doesn't currently cover invasive services added by operating systems or privacy/security regressions beyond patch delays though. It covers what is done with most of the standard AOSP services and how Google service compatibility is handled.
> Is waiting for the new pixel and then putting grapheneOS on it a good way forward? Seems weird to pick a google device to get away from that company.
The purpose of GrapheneOS is providing a high level of privacy and security. This requires secure hardware/firmware with important hardware-based security features and driver/firmware patches. Using a Fairphone with /e/OS is nearly the direct opposite of GrapheneOS.
> Alternatively, there is the iPhone but I do like fdroid and the more open nature of android.
An iPhone would be a far better choice for privacy and security than anything with /e/OS.
> Although it is conterintuitive to use a Google device to get away from Google
The purpose of GrapheneOS is privacy and security, not specifically avoiding Google, which is not what privacy is about overall. Many companies including Android OEMs have worse privacy practices.
> Just stay out of the radar of the leadership, they can be a bit abrasive, for the lack of a better expression.
There are a lot of ongoing attacks on the GrapheneOS project and our team including through fabricated stories and spin. People should look into the actual verifiable facts and look at who is being targeted with harassment and bullying. We defend ourselves from this including debunking inaccurate claims about the project and our team.
Android has a standard system back navigation gesture based on the previous system back button. Apps integrate support for it. Chromium disables their back/forward gestures when using the modern gesture navigation in the OS. It would have made sense to have a forward gesture but Android never had that as something apps had to implement so it would only work in a small subset of apps and would be generally unavailable, which would be confusing.
Phone app has a button for ending the call. It's our fork of AOSP Dialer with minor changes including UI improvements. Calculator, Clock, Contacts, Gallery, Keyboard, Messaging and Phone are AOSP apps which we need to overhaul or replace. These look and function the same way Google's apps used to but are outdated. They're the open source projects which were abandoned beyond security patches after they forked them off into their own proprietary Google apps. Gallery and Keyboard will likely be replaced while the rest will be overhauled. We know these apps have a bad UI but our focus has been on the core OS instead of apps people can replace. We're beginning to do more work overhauling these.
Do you count binary firmware as 'open' or not? If not, AMD is not 'open' either. If you do, Nvidia now also has open kernel drivers. Mesa developers are exploring ways to get the new Mesa Nvidia Vulkan driver (NVK) to run on top of the open Nvidia kernel driver, which should eventually make Nvidia drivers as open as AMD.
It does not inherently require any closed source code or hardware. Real world hardware is closed source and requires tons of closed source firmware. Not updating the firmware doesn't make it not exist. It would mean it was outdated and missing important security patches. Lots of firmware is updated by GrapheneOS. All of the kernel drivers are open source. Replacing closed source libraries such as the Mali GPU library to use hardware components is something relevant to GrapheneOS and any other OS targeting the same hardware. It's best for the SoC vendor and OEM to be involved in that rather than spending many years gradually assembling it downstream where by the time things work, the device is end-of-life. The hardware/firmware would still be just as closed source after doing all of that.
Ignoring all of our hardware requirements would not result in there being a single device we could support without nearly entirely closed source hardware and firmware.
> He is without question a brilliant security engineer, but we can't ignore his very public Terry-Davis-esqe history of mental illness.
There's no basis for these repeated claims that I'm insane, delusional or schizophrenic. Defending myself from frequent attacks by many people doing exactly what you're doing doesn't make me crazy or an aggressor towards the people doing it. You're demonstrating the ongoing libel, harassment and bullying directed towards me. There's no point in claiming it's a delusional when you've repeatedly engaged in it. Engaging in this in plain sight and pretending it's imagined is ridiculous.
> Making -anyone- a single point of failure for a ROM frequently recommended for journalists and dissidents is a bad plan, and especially not someone very prone to believing wild conspiracy theories.
I do not believe any wild conspiracy theories. It's a baseless and dishonest claim. I'm not the one pushing unsubstantiated claims about backdoors and a clearly non-working approach to preventing them. Not having the Mali GPU driver library and similar closed source userspace libraries would not change that the hardware and firmware is closed source and also far more complex.
> 1. they are able to find a device they can run 100% open source code on with no binary blobs
There's no laptop, desktop, tablet or smartphone which is not filled with closed source hardware and firmware. Having some closed source libraries for a Mali GPU driver, etc. which are not obfuscated, generally have debug symbols and can be thoroughly inspected/audited if you want to do that is insignificant compared to the vast complexity of the closed source hardware/firmware.
A device avoiding having a few dozen closed source vendor libraries would be nice but it's still going to be closed source hardware and firmware. It would allow us to cover it with our added compiler-based hardening and much more easily fix or work around bugs we find with our hardening features such as memory tagging. It's something we want and can eventually be a requirement, but not yet. Tensor Pixels greatly reduced how much of this there is compared to Snapdragon Pixels but didn't keep going in that direction especially with Android 16 throwing away a lot of progress.
> 2. The ROM can be full source bootstrapped to mitigate trusting trust attacks.
It's an operating system, not a ROM. Having a standard toolchain build is for reproducible builds and all parts of the toolchain itself can be built from the source tree.
> 3. The ROM builds 100% deterministically and is reproduced and signed by multiple team members publicly > 4. Threshold signing or a quorum managed enclave issues the final signature only if multiple team members give it signed approvals of a hash to sign.
GrapheneOS has reproducible builds. There's a community member regularly testing it and publicly reporting any issues which come up in our public development room. A recent example is that Android 16 split up the kernels into 3 groups which we found hard to explain and make sensible for people building it, which they ran into. There are sometimes regressions in AOSP which cause minor reproducibility issues. This community member looks into those to determine what's wrong. There are not currently any known build reproducibility issues which occur regularly. There's no strong commitment from the Linux kernel, AOSP, Chromium, etc. to keeping builds fully reproducible and blocking security updates based on this wouldn't make much sense, particularly with a strict interpretation of it rather than investigating the actual differences and determining if it's even an actual code difference.
We can't risk introducing a very a fragile system which could result in substantially delayed updates. Our plan for reproducible builds is to provide an opt-in feature where people can select which additional parties they trust to reproduce builds without falling behind significantly. This would solely be for the OS update client and App Store updates. It would not be for other uses of signing such as verified boot which are not designed to handle this. It would a system to verify that signed hashes from other parties have been published for an update. The meaning of that can be defined by these parties reproducing builds, such as how they'll investigate a mismatch and the way they'll determine if it's an issue.
In practice, this would be based on tools we publish for others to use for building and comparing. Similar to the rest, people are trusting the source code and the people who wrote it. Source code is not inherently trustworthy and provides no magical privacy or security properties. Reading the sources does not mean you will find all the vulnerabilities, particularly subtle ones or hidden ones. It clearly doesn't provide that even for extensive audits/review. Why does the Linux kernel have so many serious vulnerabilities being found on a regular basis including ones which are years and even decades old if this approach works?
If you truly believe that I'm insane, why do you think it's reasonable to use code that I wrote or supervise writing as long as the build matches the sources?
> Until at least those points are covered, the centralized trust model of GrapheneOS is a liability and the central keyholder is at high risk of being targeted for manipulation or coercion.
You use many open source projects with far fewer review. GrapheneOS itself is based on AOSP which uses a huge number of open source projects from a huge number of people. The Linux kernel alone has a massive number of contributors and most code has little review. It's filled with vulnerabilities which are found regularly. https://lore.kernel.org/linux-cve-announce/ provides a very flawed overview of this based on what is backported. These devices are compromised in the real world by exploiting vulnerabilities like many of these. Reproducible builds and checking that others have reproduced builds is not actually going to stop a software supply chain attack in practice, which would work within the constraints and use source code. If one of the projects used by AOSP has a backdoor added to the sources, how do reproducible builds help? We'd just be building the code and the backdoor would be reproducible.
> Honestly there is no good solution to these problems right now, and as a security and privacy researcher my best advice today to potentially targeted individuals is don't carry a phone at all, or if you must carry one, keep it in airplane mode whenever possible and do not do anything sensitive on it. Consider QubesOS or AirgapOS for such things.
Computers have closed source hardware and firmware in general. A few small closed source libraries are not significant compared to the overall complexity of the closed source hardware and firmware. Those libraries are easy enough to review. Pixels have debug symbols enabled for them. Reviewing firmware is a larger scale and much harder undertaking. How do you review the hardware itself? Even if the hardware design was fully open source for the SoC including the CPUs, GPUs, MMU and everything else along with the radios and other peripherals, how would you verify that what a chip manufacturer like TSMC produced matches the hardware design?
> If you are fine with centralized control of a phone, and fine with binary blobs controlled by random corpos having God access to your device, but would prefer to eliminate as much proprietary corpotech bullshit as possible, then I would suggest considering CalyxOS which is at least run by a former LineageOS maintainer with a great reputation.
The lead developer of CalyxOS is a former Copperhead employee directly involved in the takeover attempt on GrapheneOS in 2018. You're talking about someone who was a direct participant in doing shady things for Copperhead's CEO going against the ethics of the open source project the company was meant to be supporting including participating in the takeover attempt and then leaving following it.
He was involved in subsequent attacks on GrapheneOS including similar harassment to what you participate in yourself. CalyxOS does not have current Android privacy/security patches. It's still missing the June 2025 patches for Pixel drivers/firmware. It isn't a hardened OS like GrapheneOS with similar privacy or security improvements, and it doesn't maintain all of the standard security model due to the privileged code they add to the OS.
CalyxOS lacks the current driver/firmware patches and isn't a hardened OS with similar privacy and security patches. There are plenty of worse options but people are better off using an iPhone.
Hardware and firmware is closed source in general and the complexity of that dwarfs a few dozen closed source driver libraries used on top of open source kernel drivers. Pixels have those libraries built with debug symbols and they're not hard to review. It's not obfuscated code and you're given the function names, etc.
Those few dozen mostly quite small libraries being open source instead of closed source with debug symbols would be nice and is something we want. With an OEM partnership, we can have access to the sources and build them with hardening even without those being open source yet. We can likely include debug symbols just as Google did for the most part on Snapdragon Pixels. Convincing a company like Qualcomm to open source those would be ideal, but it's far from being at the top of a rational list of privacy and security improvements which could be made.
> This does not make sense at all.
You can see he's once again making a baseless claim that I'm schizophrenic, delusional, etc. in his post here as he has done many times before. There's also the baseless claim that I believe wild conspiracy theories. It's not me making unsubstantiated claims about backdoors and proposing approaches to prevent it which disregard the hardware and firmware to focus on the OS having reproducible builds, which would not stop malicious changes hidden at a source code level. I don't think Hacker News should permit baselessly claiming someone is schizophrenic. It's not reasonable discourse, and neither is linking what's clearly harassment content from a Kiwi Farms as happens here regularly. I've never claimed GrapheneOS prevents hypothetical backdoors and certainly wouldn't claim reproducible builds (which we have) can somehow we used to prevent it for the OS.
We can make more use of the reproducible builds but enforcing anything based on it requires early access and more resources to fix reproducibility issues early to avoid delaying security updates. It will not avoid trust in the OS developers and the projects it uses itself. It can only reduce trust in the build infrastructure and people involved. Open source does not prevent backdoors. The small amount of closed source library code for supporting a modern smartphone SoC, etc. is also quite insignificant compared to the overall hardware and firmware complexity. Reviewing those libraries is also quite doable. Open source is not a hard requirement to review something, particularly with debug builds for most of it and no obfuscation. When we find bugs in this code with MTE, we get nice tracebacks with the function names due to the debug symbols. It's hard for us to make our own fixes for it, but not impossible. We would prefer if they were open source, but it's FAR from the most pressing issue and is something SoC vendors could quickly solve if convinced to do so.
For spam, install their sandboxed Google Play, and then install Google's Phone and Speech Recognition & Synthesis apps. For SMS/MMS/RCS spam, you'd use an app supporting blocking (e.g., Google Messages).
I imagine that Hold For Me works if you also install the Google app and whatever other dependencies.
No, not really, and there's no reason those can't run AOSP.
> MNT Reform
It has a typical closed source ARM SoC and other components. The chassis and board being open doesn't make all the components open. CPU, GPU, MMU, USB, etc. are provided by the SoC and are closed source as usual. It has closed source hardware and firmware for the SoC along with other closed source hardware and firmware. Not having to load firmware from the OS does not mean it's open hardware and firmware. It's barely more open than other computers for the most complex parts of it.
How is something fully open hardware if the vast majority of the complexity is in closed source components providing most of the functionality? The SoC is just the most complex of these by far.
Why couldn't AOSP be run on a regular ARM SoC used in devices which run AOSP? AOSP works fine on top of the mainline Linux kernel and drivers.
> Talos II
A mostly open source motherboard where you drop in a closed source CPU is not really an open source platform. It's not fully open source itself and the CPUs used with it are not open source. IBM took steps towards open sourcing PowerPC as an ISA and relatively primitive open source cores OpenPOWER core designs exist. However, what's actually available and used with it are closed source CPUs. In theory, there can be open design CPUs for use with it. As a motherboard, it's pretty close to fully open hardware. As a functioning computer, it's mostly not because a motherboard is not a whole computer and is far less complex than the CPU even with a more traditional desktop design with less functionality moved into an SoC.
> Precursor
It has a closed source FPGA as the primary processor and other closed source components. It's far closer to being open source, but it isn't fully open hardware. This is the only one you listed which is anywhere close to mostly open source. It is very far from a powerful modern smartphone device though.
> Those are lightyears ahead in openess and auditability compared to anything Google produces.
The primary SoC in each is closed source. Precursor programs their CPU on top of that closed source FPGA so the CPU is open source in that sense and much closer to being mostly open. It's not the only closed source part of it.
The other 2 examples have a closed source SoC. One uses a regular closed source ARM SoC incorporating far more than a CPU and GPU into the closed source chip. The other depends on a more traditional desktop style closed source CPU from IBM outsourcing more to the motherboard.
Yeah, that's completely how security works...
GrapheneOS users tend to avoid using Google services when possible and this has a battery life cost when using apps like Signal with their own push systems. In the case of Signal, Molly is a fork with UnifiedPush support that's more efficient but it requires running a server to convert FCM to UnifiedPush since Signal doesn't support it.
I like being able to reach across the keyboard one-handed (to shift, etc) and I can't do that on modern, larger phones.
Well at that point buying a GPU is definitely not worth your money. You're better off using a CPU's integrated graphics unit.
> I generally choose AMD GPUs for the best experience with open drivers these days on systems I need high GPU performance from.
Yeah I agree on that, I also purchase AMD cards exclusively now.
> Which blobs do I need on RISC-V FPGA enclaves or my PPC64le Talos II workstation
I assumed we were only talking about x86. But I also believe that POWER9 CPUs don't have SSE, prove me wrong. I guess you're running Linux? I'd be very interested in looking at the output of lscpu from one of these machines.
> x86_64 is a bit of a shit show
I fully agree there
Smartphones are small portable computers. You're using a similar computer to make posts on social media platforms including Hacker News.
> It is better in one way: a reasonably stable person holds the keys to the kingdom.
Repeatedly claiming that I'm insane, schizophrenic, delusional, etc. is not a reasonable criticism of GrapheneOS. I'm clearly none of those things. I've been targeted with attacks including harassment and tons of fabricated stories for years beginning with my former business partner and his associates. You thoroughly discredit yourself by going as far as baselessly claiming that I'm schizophrenic because you don't like the way I've tried to defend myself from these attacks.
The lead developer of CalyxOS (cdesai) was a Copperhead employee directly involved in the 2018 takeover attempt on GrapheneOS. CalyxOS itself directly originates from the takeover attempt on GrapheneOS. The people involved demonstrated their lack of ethics through their participation in the attacks on GrapheneOS and partnerships with people involved in it. You've been attacking us for years alongside them. CalyxOS exists because of this takeover attempt. It's a non-hardened OS which was created by heavily using GrapheneOS source code and documentation without most of our privacy and security features.
StreetComplete: help update CoMaps and OpenStreetMap
Catima: for loyalty cards
It would be nice if the firmware itself was free software so that it could be shipped alongside the Linux kernel, maintained indefinitely and we could customize it however we want. The hardware is supposed to do what we want it to do, not what the manufacturer lets us do.
I don't like the fact every single device out there has entirely separate computers inside them running unknown proprietary software. It feels like our operating systems aren't operating the system anymore, it's like they're just some user app sandboxed away from the real system. This presentation explains what I mean:
It's an imperfect reality. Security by isolation of devices via IOMMU addresses real concerns such as devices being able to access RAM via DMA. It's great that GrapheneOS is doing this.
> We also expect Google's Play Integrity API to inevitably be ruled as anti-competitive, which it is.
I certainly hope so.
I generally only run gaming graphics cards on dedicated gaming machines, not on workstations I need to be able to trust. You can't use accelerated graphics in qubes anyway, specifically because graphics cards are hard to trust.
My requirements from a workstation are:
1. MUST have 100% open source code loaded in system memory
2. SHOULD have open source software in the boot trust path (coreboot/tpm2 secure boot, etc)
3. SHOULD have open hardware to the furthest extent possible that meets my use case
4. SHOULD be fully auditable and tamper evident using at-home tools and methods (like the Precursor)
The people you've had respond to you in this thread, who likely have more intimate knowledge of what actually happened, have done a better job of breaking down this stuff - so I'll just defer to them.
Yeah I only use dead simple workstation cards or integrated graphics on my workstations, and AMD GPUs on my gaming systems which I don't trust at all (but still prefer to support companies that use open drivers)
> But I also believe that POWER9 CPUs don't have SSE, prove me wrong.
POWER9 has its own SIMD system (AltiVec/VMX/VSX) instead of SSE which is entirely its own thing. I have no idea of the performance tradeoffs here though for various use cases, as freedom is biggest factor for me.
> I'd be very interested in looking at the output of lscpu from one of these machines.
Here is an lscpu from an 8 core Blackbird though it will probably render poorly on HN.
Architecture: ppc64le Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Model name: POWER9, altivec supported Model: 2.3 (pvr 004e 1203) Thread(s) per core: 4 Core(s) per socket: 8 Socket(s): 1 Frequency boost: enabled CPU(s) scaling MHz: 58% CPU max MHz: 3800.0000 CPU min MHz: 2166.0000 Caches (sum of all): L1d: 256 KiB (8 instances) L1i: 256 KiB (8 instances) L2: 4 MiB (8 instances) L3: 80 MiB (8 instances) NUMA: NUMA node(s): 1 NUMA node0 CPU(s): 0-31 Vulnerabilities: Gather data sampling: Not affected Itlb multihit: Not affected L1tf: Mitigation; RFI Flush, L1D private per thread Mds: Not affected Meltdown: Mitigation; RFI Flush, L1D private per thread Mmio stale data: Not affected Reg file data sampling: Not affected Retbleed: Not affected Spec rstack overflow: Not affected Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation b arrier enabled Spectre v2: Mitigation; Software count cache flush (hardware accelerated ), Software link stack flush Srbds: Not affected Tsx async abort: Not affected
https://old.reddit.com/r/StallmanWasRight/comments/1l8rhon/a...
The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals. Otherwise I actually normally agree GrapheneOS has made the best effort defense calls it can in a very broken and proprietary ecosystem. Use open stuff where you can and where you can't try to put up IOMMU walls. I get and respect the pragmatism here. I do similar in AirgapOS and other projects.
I however absolutely can never recommend trusting centralized/proprietary software supply chains in areas where dramatically more open and accountable solutions already exist, which is why I do not actually use or recommend CalyxOS or GrapheneOS for high risk use cases and instead full source bootstrapped a Linux distribution from scratch that avoids any trust in me as the founder by design.
For low risk use cases where users simply don't trust Google or the stock phone malware, LineageOS or CalyxOS is just fine as they remove this, and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing, and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality that is normally very receptive to criticism, and is never hostile to anyone that forks their code for use in other projects as you have a history of doing, but ultimately again, I don't actually use or recommend CalyxOS or GrapheneOS for most people for most use cases.
If forced to use a mobile device again I would probably fork GrapheneOS, remove all the proprietary bits I can, LTE, bluetooth, etc be damned, and sign it myself only for my own use, until I could develop an quorum enclave controlled signing scheme and then offer that.
If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.
If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.
I could get dementia tomorrow and I am confident the StageX project would continue without me with signatures by other maintainers by design. The team already has made several releases without needing signatures from my key already. This is a proven strategy now, not just a theory I parrot to try to win arguments.
GrapheneOS, for all its high risk users, deserves to be protected from the failing of any one human or build machine.
I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.
MNT Reform has a regular closed source ARM SoC as the main component along with a bunch of other closed source components. The chassis, board and boot chain being open doesn't make a device mostly open hardware. Anything simply using an ARM or x86_64 SoC at the core is not truly mostly open. It's a closed source system (the SoC) with open source components between it and other closed source components like radios, a display controller, SSD, etc. The same applies to other ARM and x86_64 laptops. They're built around closed source components even if the board many components go in and the boot chain is open source.
Having an open source boot chain and not requiring loading proprietary firmware from there or from the OS doesn't mean the device has open firmware. It's conflating not needing to load firmware with the firmware not existing or being open, which isn't the case.
> The Precursor is the only pocket computer platform that is maximally open hardware, software, and firmware but you revert back to the 90s in terms of power as a consequence with alpha quality software today. If Bunnie is successful with his IRIS approach and making custom home-user-inspectable ASICS then maybe a middle ground path can be forged in the next few years.
This is far closer to being how you're describing other platforms. However, it does have closed source components including the FPGA and Wi-Fi. It's as close as it gets to being open hardware and that has a huge cost. Platforms simply using a closed source ARM SoC and many other closed source components are not anywhere close to being open. This is what it takes to get close, and it's not fully there.
> For now the only modern computing experience with fully open hardware and software I am aware of are the ppc64le based devices by Raptor Engineering, but at a very high cost due to low demand, with huge form factor and no power management. I still own one anyway because we have to start somewhere.
It's the motherboard that's open source. The IBM CPUs used with it are not open hardware.
> For those that want this story to get better, please buy and promote the products of the few people trying to break us out of dependence on proprietary platforms.
Laptops with a nearly completely closed source SoC / CPU are not a fully open platform, especially when it's an SoC providing most of the functionality. Talos II has a lot of functionality on their open motherboard vs. an ARM SoC with most of it on the SoC, but either way the CPU being closed source is still the most core component being closed source.
Following this, we posted multiple threads correcting inaccurate claims about what we had said about this and made it clear GrapheneOS was continuing. GrapheneOS was fully ported to Android 16 before the end of June, which took longer than usual due to the changes but was still completed.
Snapdragon uses a fork of the open source EDK2 as their bootloader prior to the OS and publishes the source code. It doesn't mean Snapdragon is open source.
Most of the firmware has nothing to do with the boot chain leading up to the OS on the SoC.
Typical Android devices have fully open source kernel drivers. There are usually dozens of closed source libraries in userspace such as the well known Mali GPU driver library. Closed source libraries can still be reviewed. Open source doesn't make something secure and trustworthy. It also isn't a hard requirement to review a library. Auditing a low-level C library doesn't imply finding all the vulnerabilities, particularly something hidden. Widely used open source code still has many vulnerabilities lasting for long periods of time after many people have reviewed it. It does not solve security or trust.
> That said, to your point, both are misrepresented as fully open frequently which is just not true, and obscures efforts by teams that are working on fully open hardware solutions the hard way.
A closed source SoC with open source hardware built around it and other closed source components including radios is not a fully open source computer either.
The ISA is open source, not the whole CPU architecture and design. There are older open core designs from IBM but that's a different thing from the more modern and powerful Power9 and Power10 CPUs.
> you still only have to trust your CPU vendor even there, as it is possible to have FOSS firmware/software for everything else
A device with assorted closed source components including as part of the motherboard itself is hardly open beyond the CPU. Open source also doesn't mean you aren't trusting those vendors. With a fully open hardware design CPU, you're still trusting that it matches the open source design and you're trusting the open source design. The manufacturing process is also generally going to be proprietary.
Except the default browser is Chromium with some changes
This reminds me of a recent HN comment I saw that suggested using Firefox was "kicking Google where it hurts" or something like that
Like Firefox, this project depends on Google. For the hardware, the web browser and who knows what else
It even offers a sandboxed Google Play Store
It tries to copy Google paternalism
It swaps a Google mothership for a Graphene mothership
What if the computer owner does not want a mothership
Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
Even Netguard which works on any hardware and does not require root makes unnecessary connections to ipinfo.io servers effectively giving them a list of almost every domain the user's phone trying to access
If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
Most apps but not all will try to connect to the internet at some point, even if you never use them
The user-hostile design of Android is that apps keep running in the background after they are "closed"
(There are crude apps one can use to automate manually killing each process with "Force stop" but no one uses them. This doesn't prevent apps from trying to access the internet on some preset schedule)
Netguard will show when apps try to connect and block the connections. It provides DNS logs and PCAPs.
One does not even need Netguard to see this subversive activity
Try this at home
Enable IP forwarding on a computer you can control, i.e., one that is running an OS you can compile yourself such as Linux or BSD
Put the phone on the same network as this computer
Set the phone's gateway address to the address of the computer
Run tcpdump on the computer and filter for the phone's IP address
You should stop calling be insane, delusional, etc. It's quite easy to stop.
> yet also you seem stuck in a revisionist history narrative that people were trying to rip off or steal from GrapheneOS
No, I'm not doing that. The fact that they built on our code while trying to undermine us with misinformation and numerous forms of attacks is what makes it wrong. Calyx knowingly spread and supported misinformation about GrapheneOS and myself. They welcomed, tolerated and worked with people involved in harassment along with frequently participating in it. You do it yourself as you've demonstrated here so of course you don't see it for what it is or think it's wrong.
> but the constant citing of conspiracies and sock-puppet campaigns that never happened
The harassment and their involvement in it happened and continues to happen. Your involvement in it is real and continues too. There's no conspiracy. It's plain for all to see you repeatedly calling me insane, delusional, schizophrenic, etc. and personally targeting me in similar ways over and over. You're just one of many people doing it. That is the harassment, which clearly does exist and you participate in it including in this thread. Calyx and their community are heavily involved in it.
> your hostility to CalyxOS, F-Droid and others who are good community actors
CalyxOS and F-Droid both have multiple people who were involved in the takeover attempt and supported their attacks on us, including the lead developers of both projects.
> a lot of people including me felt you lost the plot and were not being rational
It's factual information, and it's you not being rational about it.
> The "takeover attempt" narrative never happened and every time you say it did without evidence you hurt your credibility
It is exactly what happened. My former business partner tried to take over my open source project against the terms of our agreements. The project was started prior to the company existing in late 2015 and was very clearly separate from it. This has been confirmed by other people involved and around at the time including the 3rd person involved in forming the company.
> It is an incredible conspiracy accusation that merits proof, or you will continue to be called delusional
My former business partner trying to take over my open source project is what happened and is not a conspiracy theory or delusion.
> I do always make an effort to separate these seemingly irrational views with otherwise well reasoned security engineering work.
My statements and views about this are not irrational.
> The primary thing we disagree on in a pure objective security engineering capacity is you feel it reasonable that a single person, you, can be trusted to resist coercion or manipulation to hold the signing keys that would allow pushing any code to the phones of a lot of highly targeted and vulnerable individuals.
We don't disagree on the concept that it would be nice to avoid trusting a single person with this. Where we disagree is that I do not think your proposed approaches are better or that they actually address the trust placed in many people.
> and I am more inclined to support cdesia/CalyxOS which at least attempts basic signing
Not clear how you think we do not do basic signing.
> and trust cdesia as a keyholder when someone really wants to use Android purely because of his peace-keeping personality
He was directly involved in the very real takeover attempt on the GrapheneOS project at Copperhead. He stood by as Nick repeatedly spread misinformation about GrapheneOS and personally attacked me including regularly covering it up. He has a long history of making false claims about GrapheneOS and myself himself. He's friends with many people participating in harassment towards me and clearly has no issue with it along with openly helping them do it.
> that is normally very receptive to criticism
In reality, no, and they'll quickly shut down conversations particularly involving any of this. You think they'd talk openly about this where someone raises actual things they've done and participated in? No.
> and is never hostile to anyone that forks their code for use in other projects as you have a history of doing
Calyx gained influence over Seedvault, a project written for GrapheneOS by a GrapheneOS user, and has since used that to be hostile towards our users reporting issues there and us for continuing to reluctantly use a project now hostile towards us. They've done the same with other projects. They're hostile towards our users, not only us.
A Calyx contractor recently closed a valid F-Droid bug filed by a GrapheneOS user causing it to wrongly show a warning on GrapheneOS every time it installs/updates an app. It's clearly an F-Droid bug since we use standard Android infrastructure to add our Sensors permission and their bug occurs with the POST_NOTIFICATIONS permission and multiple other past cases of added or split permissions in Android. It's a long term F-Droid bug which has existed for ages. Instead of fixing it, they're keeping incorrect code with no purpose and instead adding workarounds for specific cases found to occur with Android's added or split permissions. There's no reason for F-Droid to be checking that the requested permissions parsed from the APK by them match what the OS considers to be the requested permissions. The APK is verified before it's installed and F-Droid's understanding of permissions not matching Android's understanding is fully expected since it does not handle implementation details. It cannot properly handle it as the OS does because the OS adds and splits permissions this way in future releases, so adding all of the current ones still causes it to break in the future. This used to break automatic updates for GrapheneOS users, but at least now it only displays an incorrect warning. They may change it to break things again. Meanwhile, they falsely claimed we were avoiding doing something about this to hinder F-Droid's compatibility with GrapheneOS when they are blatantly doing that. This is one example of how they misuse their control over projects to cause harm to their own users to hurt GrapheneOS. They've done so repeatedly.
> If you were to agree to take on quorum controlled signing of reproducible builds, then there is no central trust in you, and all my primary arguments against GrapheneOS go away and GrahpheneOS would be leaps and bounds better than CalyxOS by any technical measure I am aware of.
The whole thing is a personal grudge and you hold us to a standard you don't hold other projects to based on it. A substantial amount of resources is required to simply make 1 set of builds. Blocking releases indefinitely any time there's a regression in determinism without any more resources to deal with that or early access to address issues prior to when a stable release comes out isn't going to work. When we're porting to a new release like Android 16, addressing some kind of new bug causing something to be non-deterministic cannot be our priority without early access to the release and resources to handle it. If you truly wanted us to do this then you could have helped us get what we needed to do it, make the required scripts and improve protection against non-determinism getting introduced. Instead you act as if this isn't something we want, when it is, but we aren't willing to break updates with an improper implementation.
It's not clear how you avoid trusting me or the developers doing nearly all of the actual development and code review on GrapheneOS through this though. Reproducible builds combined with checking it's reproducible from other parties does not truly accomplish that. Source code is being trusted either way.
There is someone actively reproducing each of our builds after we make releases. It's fully reproducible but AOSP and other projects do have upstream regressions for this we have to fix on a regular basis. It's not always easy to fix.
> If you put aside any dislike of me, objectively, removing trust in a single person makes you and the project and users safer, and make it much easier for people to separate your personal views from the stability of the project as a whole.
I dislike your false claims about me and your harassment towards me. Most of the few times I've interacted with you for several years have involved you making personal attacks on me and talking about us not providing a reproducible build verification feature which barely any projects provide and which is not practical for a project largely based on AOSP without early access or the resources to fix all reproducibility issues they introduce prior to stable releases.
> I'll let you have the last reply as this will go on forever otherwise. You know how to contact me if you ever want to discuss any of this privately.
I don't think we're ever going to come to an understanding. I simply want you to stop making public personal attacks on me. I'm not showing up in threads about your projects talking about what you've done towards me, but you keep showing up in discussions about GrapheneOS to claim that I'm crazy and delusional. You're doing the opposite of encouraging us to implement the signing feature you want.
As for the requirements, I will take your word for it. And I do appreciate that you put the emphasis on security as it is often overlooked. I guess what I'm saying is that having control over my phone (as opposed to BigTech or apps having the control) is for me a much higher priority goal than just security by itself. Hardware reparability is (again, for me) a close second.
Anyway, I hope you find a good partner for the phones, and I'm curious to see what you come up with!
Rossmann shouldn't be excused for making his harassment video about Daniel because he doesn't understand how things work. Anyone who bothers to think about it for a moment would understand that someone who had been swatted 3 times by a crazy person spamming community chat rooms with illegal content would be extremely upset. Someone tried to _murder him_ and was trying to destroy the project, and then this video comes out leaking a private chat, and Rossmann portrays him as crazy? Rossmann knew what was happening and then his first thought was to start recording? How is that justifiable?
You confessed you are a Rossmann fan in another comment, but even a fan should be able to see what had gone on here...
And you are defending the inaccuracy in his video saying he's afraid of being targeted when it's not even possible, and your excuse for him is that he doesn't understand. There is no excuse for his video in the first place, but to also add this falsehood that he even can be targeted is extremely damaging for a project prioritizing privacy and security. And yet even though I'm sure he knows this now, as far as I know he hasn't retracted what he said. I don't think he cares about accuracy. Among other things, he's a YouTuber and he got views and attention, so I guess he got what he wanted at the expense of someone else during an extremely trying time. I don't think that's justifiable, I think it's scummy.
Rossmann shouldn't be excused for making his harassment video about Daniel because he doesn't understand how things work. Anyone who bothers to think about it for a moment would understand that someone who had been swatted 3 times by a crazy person spamming community chat rooms with illegal content would be extremely upset. Someone tried to _murder him_ and was trying to destroy the project, and then this video comes out leaking a private chat, and Rossmann portrays him as crazy? Rossmann knew what was happening and then his first thought was to start recording? How is that justifiable?
You confessed you are a Rossmann fan in another comment, but even a fan should be able to see what had gone on here...
> Expecting a layman to know that is not reasonable.
And you are defending the inaccuracy in his video saying he's afraid of being targeted when it's not even possible, and your excuse for him is that he doesn't understand. There is no excuse for his video in the first place, but to also add this falsehood that he even can be targeted is extremely damaging for a project prioritizing privacy and security. And yet even though I'm sure he knows this now, as far as I know he hasn't retracted what he said. I don't think he cares about accuracy. Among other things, he's a YouTuber and he got views and attention, so I guess he got what he wanted at the expense of someone else during an extremely trying time. I don't think that's justifiable, I think it's scummy.
> If anything, even after that video, he kept recommending GOS whenever he talked about privacy.
Doesn't excuse what he did.
It's not appropriate for you to be saying these things.
> Stuxnet only targeted specific Iranian systems, a needle in a hay stack, was spread did not harm random devices across the globe, and stayed mostly undetected. And this was done without "developer access" to the software itself. Is it hard ? Yes. Is it likely (especially given the knowledge of how GOS works) ? Perhaps not. Is it impossible ? Definitely not.
This makes no sense. GrapheneOS is an open source project and anyone can look at the changes made by the project. Even the OS is reproducible and people do check that, apparently, so GrapheneOS would be caught if they were making changes. Like I even found this repository just now after a quick search https://github.com/lucasbeiler/reproducible-builds-grapheneo...
GrapheneOS isn't just some random OS that nobody has heard of. There are lots of eyes on it, so sneaking some backdoor into the OS would be very difficult and extremely stupid. One misstep and the project would be gone. Do you really think Rossmann is worth that? I don't.
> When the lead dev of the OS you use daily threatens to "publicly expose you" as a user, I won't blame said user to stop using the software. And even less, to provide such data point regarding the behavior of that developer.
I've already pointed out in other comments that he had no good reason to fear a targeted update. It's just not possible. He should know that by now, but as far as I know he has never retracted that part of his video.
You yourself have even admitted that while it may not be true that he can be targeted, you make excuses for Rossmann saying he's a "layman when it comes to software". So, yes, it is baseless.
> it's like going to a restaurant and having a disagreement with the cook, for the latter to explicitly threaten to harm onto you. At that point, is it that far fetched to think he might poison the food ? When you know he has full control over the kitchen ?
This is a horrible metaphor because an open source project and the resulting OS is nothing like that. Better analogy would be that all the customers can watch the chef while they work, they all share the same food, and there are even cameras there for the world to see what the chef is doing in real time.
> You can disagree with Rossmann perception of the actual threat, but you should at least admit that it is not absurd for Rossmann to think that someone who demonstrated such irrational behavior might attempt to harm in through the means at their disposal, among which introducing malicious code.
If he had any integrity, he would have retracted that part of his video _at least_ when people pointed out that it wasn't true that he could be targeted. But as far as I know, he hasn't.
> Then in the first place, perhaps the cyber security geniuses who built a privacy and security oriented OS for smartphone could do the due diligence of gathering and presenting actual evidence of Rossmann implication in the alleged harassment campaign before before posting multiple accusatory statements across their socials media "with serious allegations and a very high potential of harming someone's reputation" ?
Anyone who thinks for even a moment can see what happened here. Someone tried to murder Daniel 3 times, he was upset about that and with Rossmann, he talked to Rossmann, Rossmann _records_ it as it's happening knowing full well what he was doing (which I'd argue is quite scummy), and releases the video complete with inaccuracies about the potential of being targeted. Not to mention he has a verified Kiwi Farms account, which anyone who knows the history of that site can draw their own conclusions. It's very easy to see what's all right out there in the open.
Well, yes, but not really. What you're saying could be true if the OS wasn't open source. It's not some small OS that nobody knows about. There are forks of the OS, there are other projects that selectively copy code/commits from GrapheneOS, there are security researchers who pay attention to its development. There are also people who reproduce and verify builds. It's just not possible for that kind of code to be snuck in there.
This section of the website about whether GrapheneOS is audited is also helpful https://grapheneos.org/faq#audit
> This is what is keeping me from installing GOS too. Interaction from the developers seems very aggressive towards the competing OSs, which doesn't inspire much trust.
If you pay attention to what they're responding to, you'll find that a lot of that is in response to something they said, clarification about inaccuracies in news articles, etc. The official accounts are also followed by many of the OSes' users, so some posts are for them too if certain things are being talked about in the community.
> In the end you need to trust someone, but I'm not sure GOS is more trustworthy than LineageOS (which has a bigger community, more developers and /e/os building on top of them).
I personally prefer quality over quantity. GrapheneOS developers take a long time to develop new features, test them, rewrite them, and it goes on and on until they have a resulting feature that is very high quality. They also have to keep in mind how much they're adding/changing so features and changes can be ported quickly when there are new upstream releases. Updating quickly is very important for security. Leaving vulnerabilities unpatched for months is not acceptable for a project and users who value security. The same can't be said of LineageOS or /e/OS. They're slow to update, roll back security, etc.
I agree that GoS did a lot in order to improve privacy (scoping) and it provides unmatched security, but you shouldn't create false expectations.
> GrapheneOS Foundation was created as a non-profit organization in Canada in March 2023 to handle the intake and distribution of donations. [1]
> GrapheneOS Foundation has been incorporated as a federal non-profit organization in Canada. It will be used to receive donations to pay developers and pay for infrastructure. It will also help to shield developers from attacks through the legal systems across various countries. [2]
I've never owned a pixel, but I'm planning on getting the pixel 10 so I can use the new android 16 Linux terminal with graphical support. I hope the pixel 10 will still fit your requirements and it won't be a hurdle to port GOS without the device tree. I see no other OEM supporting the level of virtualization with kvm and vergil Google is bringing to the pixels. Good luck!
Is making a connection to our API a cause for concern? If that is the case, we welcome OSS projects to user our local IP databases, which includes our free IPinfo Lite database that we primarily designed for firewall and privacy applications.
Looks like they are doing what a small company is able to do.
If Bunnis ASIC efforts succeed, then we have auditable reasonably fast chips in the next few years and a truly 100% open device. Tropic Square is another to keep an eye on.
Fully aware of everything in your descriptions here, but you always repeat this stuff as though I am not. Probably useful for others though.
Where we always seem to disagree is you usually try to dismiss mostly open solutions as no better than mostly closed as though the effort to pursue transparency is pointless. I feel every single component with open firmware and open hardware is a huge win, making accountability and community improvement possible. Likewise every blob is an eyesore that should be reverse engineered and replaced... or switch to more transparent alternatives when they exist.
Sure, auditing never catches all bugs, but it catches a -lot- of them. There are many severe security flaws I would never have had a chance in hell of having the time to find in closed binaries, let alone fixing them.
Sure underhanded C and all sorts of sneaky bugs can exist, but an open C solution could be replaced with an open Rust solution structured for east auditing or another language that makes it harder to do many common types of sneaky in.
If a vendor will not let me look at their code, I am extra suspicious of glaring backdoors or bugdoors until proven otherwise given countless examples in the wild.
I have always agreed open source alone does not mean code can be trusted. Most open source code is shit and should -not- be trusted (I review it for a living) but I am absolutely certain open source is an prerequisite to a community maintainable trustworthy solution existing where we get both freedom and security.
They did not replace firmware with open alternatives. Not updating firmware is not replacing it.
> Sadly this was, to your usual points, at the major expense of security making those devices purely research projects at best and not something anyone should ever actually use.
They steer people to devices with severe unpatched firmware vulnerabilities and an enormous number of severe unpatched software vulnerabilities in the case of Replicant. This is covered up and people are misled about it. These projects claiming to be focused on avoiding backdoors are in fact deliberately backdoored through not patching known vulnerabilities for ideological reasons.
> When you are stuck on a platform that requires closed firmware you are kind of stuck blindly accepting updates from the vendor to patch security bugs, stuck hoping they are not actually introducing new backdoors.
You still trust the developers of open source software and firmware. Open source doesn't result in all vulnerabilities being found, including intentional ones. It's not even close to providing it.
> This is why I reject platforms that require closed firmware in the first place to the fullest extent I can.
The platforms you're describing as having fully open firmware still have closed source firmware.
The one point I will take that is fair is to stop trying to diagnose you as that is not my background or place to do. We will likely continue to have wildly different accounting of the same events and the motivations of those involved, but it is on me to not lower my communication standards when dealing with people I find to be extra difficult or extra wrong. Point taken.
I apologize for any and all assumed medical diagnosis related comments about you and I commit to stop making these as I am not qualified to make them. I will also discourage those comments in my communities as I can. We should be better than that.
What I can and will repeatedly say is that you are obsessively defensive about GrapheneOS to the point that all criticism of it or your communication style or use of your code in related projects is regarded as a coordinated attack or harassment campaign when it is simply a lot of people who have independently found your personality impossible to work with in spite of making useful code. So much so that many have taken steps to actively fork things away from you so they do not have to deal with you because your approach puts -their- mental health and desire to work on related code at risk.
This is a real shame things went this way, because so few doing hard and important security work also have strong interpersonal skills.
I am going to try to do better here, and I hope you do the same. It is unlikely we ever be friends but I hope we reach a point where we can make use of ideas or code each other might have been involved in without drama. I am even considering adding hardened_malloc as an optional package in stagex because I still feel this is great work.
I will stay out of threads on your projects unless about something I am actively working on or working with, but I will continue to share my own view of shared events and my issues with trust structures in current Android efforts, including GrapheneOS and your leadership style, when they come up organically by others in my communities.
I hope you are able to take that for the win that it is.
It's near completely closed source hardware. The SoC providing nearly the whole core system is fully closed source. An open source boot chain after the closed source early boot doesn't change this. Other components are closed source too. It's closed source with open source bits in between. Compared to the complexity of the SoC, radios, etc. the open source parts are insignificant. Open source between closed source components with most of the complexity it not mostly open source. It's simply not true.
> and the Precursor as -maximally- open
It's possible to use an open source RISC-V SoC instead of programming a CPU with a closed source FPGA. They don't use a closed source FPGA to be maximally open but rather to be closer to being able to inspect it.
> Fully aware of everything in your descriptions here, but you always repeat this stuff as though I am not. Probably useful for others though.
I don't think you're unaware of it. You must be aware the MNT Reform has a fully closed source ARM SoC with most of the core system's complexity but you still call it mostly open source.
> Where we always seem to disagree is you usually try to dismiss mostly open solutions as no better than mostly closed as though the effort to pursue transparency is pointless. I feel every single component with open firmware and open hardware is a huge win, making accountability and community improvement possible. Likewise every blob is an eyesore that should be reverse engineered and replaced... or switch to more transparent alternatives when they exist.
They are not mostly open solutions. It's false marketing. Open source does not have the properties you claim it does of heavily avoiding trust in the developers or providing much better security.
> Sure underhanded C and all sorts of sneaky bugs can exist, but an open C solution could be replaced with an open Rust solution structured for east auditing or another language that makes it harder to do many common types of sneaky in.
Memory corruption isn't required for serious subtle vulnerabilities and even safe Rust has plenty or room for memory corruption. Rust does not making auditing easy. It makes it easier than C, which is a low bar. Auditing C for deliberate vulnerabilities can easily be harder than auditing assembly code without anything that looks obfuscated.
> If a vendor will not let me look at their code, I am extra suspicious of glaring backdoors or bugdoors until proven otherwise given countless examples in the wild. > > I have always agreed open source alone does not mean code can be trusted. Most open source code is shit and should -not- be trusted (I review it for a living) but I am absolutely certain open source is an prerequisite to a community maintainable trustworthy solution existing where we get both freedom and security.
There are many glaring vulnerabilities in the most widely inspected open source projects including the Linux kernel. Many have persisted for not only years but decades. Open source does not inherently result in all these vulnerabilities being found and fixed, whether they were intentional or not. Open source can help with it but it provides no guarantee of better security.
Linux kernel is a typical collaborative open source project where performance, scalability and features trample over security. It being such an expansive and collaborative project means there's massive attack surface for intentional vulnerabilities and it doesn't have serious protections against it. Lack of prioritizing correctness and security for nearly all of it is pretty much equivalent to intentional vulnerabilities. Deciding not to deploy very useful features for finding / fixing vulnerabilities due to minor work it creates is typical, such as not marking intended overflows to have automatic overflow checks as an option. There's massive pushback against very basic things. The effort to introduce Rust for drivers has gone horribly despite lots of resources and it's face far greater resistance in the core kernel. Meanwhile, iOS has a kernel increasingly focused on security where they overhaul the whole thing for it. This is an example where one company controlling a project without collaborative is a massive win for security. There are projects like SQLite which don't take on the collaborative and open development aspects of open source. AOSP is similar to an extent, but heavily uses collaborative open source projects like Linux as core parts of it which largely don't have the same significant focus on security it grew over time. AOSP is about as security focused as iOS itself, but open source projects they use including Linux certainly aren't.
There is no cause for concern necessarily. These are design choices, nothing more.
Users have no idea what happens to the data that leaves their computers. To quote from another story currently on the HN front page: "It's incredibly easy to give information away. But once that data is out there, it's nearly impossible to take back." >>44689059
Promises made by developers are reassuring to some, but rarely if ever legally enforceable in the event something goes wrong, and the harm already caused may be beyond redress. As a proactive measure users can, among other things, seek to minimise the amount of data they send. For example, some users might want the _option_ to stop their phones from constantly trying to ping or connect to remote servers _without any explicit user intent to do so_. Maybe they do not want their phone to act like a beacon to someone else's remote server.
The point of the comment is that sometimes there are remote connections being made to servers chosen by developers that are assumed to be OK with all users, e.g., connections to Graphene servers, IPinfo servers, or myriad other examples. Meanwhile there is no option for the user to disable this behaviour. There may be some users who prefer _zero_ remote connections except the ones they themselves choose to initiate or enable. The possibility of such users often seems to be overlooked or deliberately ignored.
Like Firefox constantly sending HTTP requests to remote servers to check for "connectivity". Even when the user is not trying to connect to any server. The requests are sent in the clear. This is not optional behaviour.
But this is unnecessary if your encryption password has enough entropy in the first place, because it cannot be brute forced. This is the security model of most linux distros that use full disk encryption with LUKS. And android already lets you do this, it is just less convenient.
I use grapheneOS with a high entropy BFU password and a low entropy biometric AFU fingerprint. My linux setup works in the same way. The BFU password is the only "real" password that secures you and encrypts your data. The AFU password is a just temporary screen lock that is vulnerable to side channel attacks because the decryption keys are still in memory.
By that time the amount of money that will have been made can justify and exceed whatever fine they might expect to get in court.
You only ever read the parts of what I say and continue to argue as though I think open source code is inherently secure, and continually ignore every time I AGREE with you that most open source code is shit.
Please listen when people are largely agreeing with you instead of hitting back with walls of text as though they are not.
MNT reform is mostly open in terms of everything but the CPU. That is a -great- start as it means fewer parties you have to trust. Also they support two different CPU vendors as well as an FPGA option soon. The CPU is a swappable component in an otherwise open platform. How can you dismiss that level of flexibility and user power as anything but substantial progress over the status quo? Please give people working hard for more freedom respecting hardware their due credit. Minimizing such very hard work will not win you allies.
Also yes, the Linux kernel is a security shit show to be sure, as well as mot desktop Linux distros, but -because- it is open I can heavily patch it and customize it to reduce attack surface.
Also because it is open projects like Asterinas can reference it to make an ABI compatible modern replacement is Rust which is making rapid progress!
Transparency is step 1 to any major progress in freedom and security and that is why I am a broken record demanding more of it from all projects widely used in high risk scenarios.
vendor: "we present 100% electric car"
we: "that's cool, I always wanted to decrease petrol use. But... can you provide an option for some petrol use? It's called hybrid, iirc?"
vendor: "no, our requirements only support 100% electric car. Hybrid cars use petrol and we can't allow that"
we: "suuure, I get that. But the price of electricity here still hasn't come down, everyone already has personal petrol reserves, and your cars are only provided with batteries from congonese child labor mines. Can we pleeease have the half-way option so that I can use less petrol for e.g. small distance travel, but still using petrol for country-sized movement?"
vendor: "no, we only support 100% electric car. Everything smaller is outside our requirements"
Real economics would've provided competition to fullfill demand - but currently Graphene is the only well-known vendor, so complaints will keep coming
Par for the course with GrapheneOS. They always seem to take a good thing said about them and not be satisfied.
If the hardware is not done properly, then the whole thing is broken. E.g. you are useless with your encryption keys if your modem sucks and leaks data, or if the CPU can trivially be made to run custom code (and you just entered your encryption key into a software that just looks like the prompt you were looking for)
As far as I'm aware as an outsider, the aim is a device that is compatible with GrapheneOS like the Pixels, yes.
>If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing?
I think to pass this you need to be 'blessed by Google' which means being certified Android by their standards. GrapheneOS have mentioned that their CTS/CDD Android certification process holds back some of the privacy/security features (think things like new Sensors and Internet permissions etc.) implemented so they cannot can't target it.
Is this really that big of an issue? It's like a couple dollar fee every 4-5 years or so.
Chromium has vastly superior security compared to Firefox. https://madaidans-insecurities.github.io/firefox-chromium.ht...
> It tries to copy Google paternalism > > It swaps a Google mothership for a Graphene mothership
Nonsense claims. All network connections made by the OS are well documented on the official website: https://grapheneos.org/faq#default-connections
There are only a few services GrapheneOS devices connect to:
- a time server (securely, over HTTPS, not insecure NTP)
- the OS update server (obvious; it's just plain HTTP requests, no user identifiers other than the IP address, which can easily be masked by using Tor or a VPN)
- the GrapheneOS App repository, which provides updates for preinstalled apps like Auditor, as well as the Vanadium browser and WebView (it's critical to get security patches for your browser in a timely manner)
- network connectivity checks (required to sign in to public wifis that use captive portals; can be entirely disabled in the settings)
- SUPL and PSDS through GrapheneOS proxies for A-GNSS because there is no network location service enabled by default
> Can connections to Graphene servers be blocked, i.e., are these connections optional or mandatory
You can block all the connections. You don't even need to, since they can all be disabled in the settings. If you disable the System Updater app, you're gonna have to adb sideload your system updates https://grapheneos.org/usage#updates-sideloading.
> If the concern is apps that only require internet connection for ads, Netguard solves that problem without root
You don't need Netguard, GrapheneOS has a built in network permission toggle, which offers even better protection than a firewall, since it completely blocks access to the underlying network socket (https://grapheneos.org/features#network-permission-toggle)
> The user-hostile design of Android is that apps keep running in the background after they are "closed"
You can deny apps running in the background, even on stock Android. This isn't unique to Android btw, I'm sure you've come across the system tray in Windows before. Those are all apps running in the background. Android basically has the same thing, it's in the notification center, and you can also stop background apps from there.
GrapheneOS definitely doesn't use it. It doesn't contact any third-party APIs. Everything is well documented: https://grapheneos.org/faq#default-connections
In both cases, they could opt to download our database locally and use it through their own API system.
We sponsor the AlmaLinux Foundation through a data sponsorship for their mirroring system: https://almalinux.org/blog/2024-08-07-mirrors-1-to-400/
But since privacy is a major concern for them, they should just use our IP-to-country database and host an API themselves on top of it: https://ipinfo.io/lite
We are happy to support and be part of any software that want to use our data.
I agree that it would be a more privacy-friendly solution for them to host their own API, but that got me thinking, wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads? That's also how the Server-Status Firefox extension (https://github.com/tdulcet/Server-Status) works (but it doesn't use IPinfo). Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
I wish GrapheneOS would support non-Pixel hardware, though, specifically my Fairphone 4. I get why that probably won't ever happen, but it feels like a massive regression in terms of repairable hardware to move away from that.
> wouldn't it be possible to just let users download the IPinfo data and use it locally? Does IPinfo offer database downloads?
Of course, you can download our free IP database right now: IPinfo Lite
> Also asking for potential personal use: How does the quality of IPinfo data compare to MaxMind, DB-IP, etc?
We are miles ahead of everyone in terms of accuracy. Currently, we have 1,100+ PoPs across the world running active measurements. While traditional IP geolocation services are no much more than ASN/ISP reported data aggregation and parsing services. Our priority above all is accuracy and at this moment we are likely the industry leader for that.
If you have the time, go through some of our posts in our community and you will be surprised how good our data is right now. I will share my recent favorite one:
https://community.ipinfo.io/t/the-north-korean-gamers-on-ste...
https://www.zdnet.com/article/3-ways-to-stop-android-apps-ru...
https://www.androidpolice.com/how-to-close-android-apps/
https://www.androidauthority.com/how-to-close-apps-on-androi...
An exception would be Windows applications that can be "run as a service". This is generally not default behaviour for user-installed Windows applications. It generally requires administrative privileges and manual configuration for each application
https://en.wikipedia.org/wiki/Windows_service
https://stackoverflow.com/questions/3582108/create-windows-s...
https://www.windowscentral.com/how-start-and-stop-services-w...
Unlike Windows, Android does not present an option to close an application while the application is in view. Android applications can be "swiped off" the screen, but they are not closed. By default, _all_ Android applications continue to run in the background. Closing an application in Android requires using a separate app. For example, opening the "Settings" app, then finding the app to be closed in a list of apps, then "stopping" the app by selecting "Force stop" as describeed in the articles above. If the Android user wants to close a number of applications running in the background simultaneously, she is out of luck. They can only be closed serially, one after the other. She must find each of them via the Settings app and Force stop each one, individually. This is extremely tedious and slow and, as one would expect, results in almost all Android users allowing applications to run in the background. The tedium mandated by this design could be purely coincidental.
NFC payments are through Google pay / wallet, which is unsupported.
No thanks; I choose to forego Too Good To Go instead of that. They are the only truly broken app I have found.
- RCS chats not sending/receiving, which has caused me to not be able to receive or send messages from/to multiple group chats with friends/family (probably going to be an issue with GrapheneOS, but at least plenty of people have reported that to be possible to work; currently doing the "disable RCS and wait 10 days" dance, so we'll see how that shakes out)
- Every other reboot the speakers would fail to initialize, meaning I couldn't hear anything except through Bluetooth (massive problem for getting up in the morning if I'm relying on my phone's alarms!).
- Microphone quality was inconsistent; sometimes I'd sound fine, and other times I'd sound muddy. Also not an issue through Bluetooth; it was just the phone's built-in microphone(s).
These were probably fixable issues, but I'm lazy and I wanted to give GrapheneOS a go, anyway (and so far I'm pretty happy with it, minus RCS still being a work-in-progress).
However it does not remove Google's control, e.g., ability to pull the plug
Google controls the hardware and the source code for the default browser
Some users might want more control, less dependence on Google
"Paternalism" is a belief by developers that they "know better" than the computer owner what choices should be made for someone else's computer
For example, pre-installing software, or connections to remote servers, and enabling these choices by default
Paternalism dismisses any idea of personal autonomy
Providing a computer user with choices rather than "defaults" could mean loss of control by the developer and any associated revenue