For contrast, Signal is a very secure messenger which also wants to be user friendly so as to get the largest user base they can, which leads to all kinds of compromises - everything that’s come out that looks like a vulnerability in Signal originates in some feature or capability added to make the product more user friendly. Graphene will not make those trades.
Neither approach is de facto right - they spring from fundamentally different philosophies on how to maximize user safety, and both have been extremely successful in their missions, but you’ve gotta recognize what you’re looking at when you look at Graphene.
It's worth actually reading the linked post. Relevant segment:
In 2018, matters between Micay and Donaldson came to a head over Donaldson’s desire to pursue business deals with criminal organizations, and his attempts to compromise the security of CopperheadOS, including by proposing license enforcement and remote updating systems that would allow third-parties to have access to users’ phones. As part of this process, Donaldson began to demand that Micay provide Donaldson with the “signing keys” - i.e. the credentials required to verify the authenticity of releases of CopperheadOS. Donaldson advised that, in order to secure certain new business, potential customers required access to the Keys.
The keys had been in continuous use by Micay, in his personal capacity, since before the incorporation of Copperhead. However, more importantly, any party with the keys could mark malicious software as “authentic”, and thereby infiltrate devices using CopperheadOS.
Micay was unwilling to participate in that kind of security breach. Since Donaldson had control over certain infrastructure for the open source project, he would be able to incorporate (or hire others to incorporate) the privacy-damaging features described above for all future releases of CopperheadOS. Micay therefore deleted the keys permanently and severed ties with Copperhead and Donaldson.
Me? I was a CopperheadOS user from the 2021 rebuild era before GrapheneOS existed in its state. All I've seen from GrapheneOS and Micay are claims without evidence and over-moderation of points they don't agree with.
These things are not mutually exclusive:
You can make a great technical product while being friendly. You can make a great technical product while not being friendly.
You can make a compromised or flawed technical product while being friendly. You can make a compromised or flawed technical product while being unfriendly.
This comes up pretty often in other HN threads, unrelated to Graphene. There's this weird personality type who insists that they aren't legally obligated to be friendly or nice or pleasant, therefore it's fine for them to be unfriendly or jerks or unpleasant.
Going it alone is that nineties libertarian romanticism, a persistent self-destructive tendency that in present market conditions is unsustainable
Their allies seem securely in place.
Their popularity and project support have never been stronger…
and they’re partnering with a (popular!) hardware manufacturer.
https://motorolanews.com/motorola-three-new-b2b-solutions-at...
Respectfully, what are you talking about?
GrapheneOS has multiple people helping out. Many developers as well as people who help out with non-development work. It's a big claim to say that the whole team is unstable.
I'd suggest reading the article again. Considering the situation, the party about deleting the keys should be a good sign for anyone reading it. It shows that the project's leadership cares about doing things the right way. Members of the team are similarly dedicated to helping build and support an OS that improves people's privacy and device security, not to scam users by making a flashy product and rake in cash. Or, in Donaldson's case, work with shady companies and even possibly criminals.
Privacy and security projects like GrapheneOS are important considering the political landscape these days. People really need to stop repeating inaccurate claims about us, like that we're criminals, unstable, crazy, etc.
I didn’t claim the whole team was unstable.
> only works in favor of people or organizations that don't like us or want to damage GrapheneOS.
Then I’d suggest stop shooting yourselves in the foot with personal rants published as public communications. If you genuinely feel you’re doing important work, then why wouldn’t you take your public communications seriously and behave maturely, as an organization?
As another comment in this thread put it:
> It's not about friendliness, it's about trust.
Still a user though.
It may be the case that Daniel and the project are so under siege that they need to take a hostile attitude toward some of the people they interact with as a matter of self preservation. They may have no other option. But taking this posture while also being fair to all of the people around them (i.e. some people who aren't actually attacking them) may be difficult or even impossible. I can see this behavior in myself sometimes. I just don't have the energy to be fair. "F U".
I wouldn't want to see friendly corporate slop either. I appreciate how down to nuts and bolts the communiques are on Mastodon and how deadly serious they take everything. That part of the communication style makes me trust them more.
I think a good step in the right direction might be acknowledging that being defensive necessarily leads to erring on the side of assuming bad faith rather than good, which leads to some mis-judgements. So far you said that GrapheneOS is open to all criticisms, which (though I haven't followed the space very recently so my memory on specifics is hazy) just does not seem to match my interpretation. I think that if we were having this conversation on Twitter or Mastodon, Daniel would have blocked me by now (if he hadn't already blocked me years ago).
Take your reply as an example, the GrapheneOS accounts are managed by multiple people, so the fixation on one specific project member may not even be accurate to the discussion. Having ones character attacked is immensely harmful on its own, but being attacked for something one may not even be doing is also immensely harmful.
The unfortunate reality is that people tend to believe the first thing they read, and without something countering it, will roll with it, intentionally or otherwise. So countering misinfo efficiently and quickly is vital.
There's many examples of people being unfriendly and still coming across as someone of character, Linus Torvalds comes to mind.
Sometimes they aren't even factually correct and get a bit upset about it when called out.
Anyways, I have gotten the same impression and these seem like red flags to me as well.
Which is why I'd take everything in that response with a mountain of salt (and I'd pay attention to what they're not saying).
Hardware kill switches need to be correctly implemented. A kill switch cutting off mics and not sensors or speakers is incomplete and privacy theater.
Not to mention kill switches assume the device is already compromised, at which point everything on it is likely compromised as well.
I never mentioned Pinephones, although I do believe that the attack on them is still too harsh. Their security is about as good as the one for Linux. And it's not exactly "atrocious". Especially if you only use software from the official repositories. Let's agree that it should be improved though. (I prefer Qubes OS myself.)
> Hardware kill switches need to be correctly implemented.
Are you saying they aren't for Librem 5?
> A kill switch cutting off mics and not sensors or speakers is incomplete and privacy theater.
I explained in the link above that cutting all sensors is exactly what happens if you choose it.
> Not to mention kill switches assume the device is already compromised
This is not accurate. Kill switches imply that even if the device is compromised (which you can never 100% verify, even on GrapheneOS), your location etc is still private, when you need it.
Hardware kill switches are nice-to-have, but they are significantly less important than the OS actually protecting the mic. With your Librem/PinePhone, you cannot even reasonably expect your calls with end-to-end encrypted apps like Signal and Element to be protected. Any app with access to the PulseAudio socket (which happens to be anything that you want to have audio playback with) can snoop on your mic at any moment in time. This does not even require an OS compromise.
This has been pointed out to you repeatedly and yet you choose to ignore it, and instead you just do character assassination whenever a post regarding GrapheneOS or Daniel Micay shows up because what Micay says goes against your favorite ideological products...
I said multiple times that I exclusively run trusted apps on the phone. I use Qubes for untrusted staff. Do you understand that threat models can vary?
> Hardware kill switches are nice-to-have, but they are significantly less important than the OS actually protecting the mic.
I never said they were more important. I only said they could reliably protect in sensitive cases.
> instead you just do character assassination
I choose to dispute false information. I don't care about any personalities. And I would be happy to be proven wrong, too.
By that logic, you might as well just not have the killswitch at all. Everything is magically "trusted", right?
Yes, I do understand that threat models can vary. Please give an example of a threat model where it makes more sense to use a phone which cannot protect any private calls over a functioning phone that has real protection.
If you are going to say "oh, when you never talk on the phone at all" then you might as well just remove the mic. It's not hard.
As usual, there is nothing that GrapheneOS or Micay says regarding the Librem or Pinephone that is inaccurate. You are just saying stuff that doesn't even remotely make any sense. Perhaps you are being deliberately disingenuous. Perhaps you are just so blinded by an ideology that you cannot see that what you say is just nonsense. I wouldn't know.
> I choose to dispute false information. I don't care about any personalities.
Doesn't seem to be what you are doing here.
This is completely false:
> Their microphone kill switch also doesn't prevent audio recording
It doesn't prevent audio recording in the super paranoid "oh, the whole phone has been compromised" scenario because it is bypassable via the sensors.
In fact, it doesn't even protect the phone in normal operation, because apps with device=all can access the sensors without the whole phone being compromised.
It doesn't prevent audio recording with any normal usage either because the OS is incapable of protecting private conversations thanks to the PulseAudio socket. "Exploiting" this is significantly easier than any of the stuff involving the sensors.
Did you even look in my link, which we are discussing? My quote from there:
> Sensors are also switched off on Librem 5 by the three kill switches: https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-h...
Does that really sound like a functioning "killswitch"?
On a long enough timeline he'll probably cite this comment chain as proof you were unable to respond to his concerns, like everyone else who's ever tried.
Unfortunately he will just ignore every single counter argument ever made and blindly believe these companies because their marketing material has "freedom" and "FOSS" in it.
I did reply to them plenty of times. Here you go doing the exact same thing again - ignoring 100% of what's being said, then claiming "no one can respond".
> You only talk about the lack of security of Pureboot and never showed the code breaking it.
If you think a piece of code is needed to understand why it's a joke, then I don't even understand what is wrong with you. LMAO. The whole thing is conceptually botched, and they pretty much admitted as much.
1. Boot block performs measurements of itself, its settings and everything down the chain for attestation.
2. There's nothing protecting the boot block.
3. A malicious boot block can lie about measurements.
4. If the goal is to defend against an attacker who tampers with the BIOS chip - then it fails at doing so miserably because an attacker can just use a boot block that lies about the measurements.
Seriously, what good is showing you the code if you don't even conceptually understand how the thing works?
You know, there is a famous saying: A farmer does not need to know how to lay eggs to know whether an egg is good or bad. In our case, the egg is already rotten from the get-go. This is not a "Ohhh something has such bad code I can attack it using XYZ method, wait and see!" situation. This is a situation where "Your logic doesn't even make any sense to begin with."
Perhaps, just perhaps, you can benefit from just spending 5 minutes thinking a bit about how the whole thing actually works at a very high level and read what I said above.
As I pointed before @TommyTran732 and to anyone thinking compromising measured boot is trivial, I layed down the tooling for anyone wanting to further protection / prove measured boot not enough to understand and break it once and for all under WiP: introspection - replicate TPM PCRs measurements directly from measured content (TCPA/TPM Event log) by tlaurion · Pull Request #1568 · linuxboot/heads · GitHub
Just use it for the bad to faster the development of something good/better.
Until then, it was proven non trivial.
The actual admission (requires a login): https://forum.qubes-os.org/t/how-exactly-is-heads-pureboot-s...
His words, not mine:
> The goal of Heads is to bring reasonably trustworthy firmware on reasonably open platforms to boot reasonably secure OS, enforcing best effort user controlled atteststion, compartmentalization and prevention. Never is it written anywhere that the firmware is tampering resistant or tampering proof: we lack open source implementation in hardware to have root of trust in hardware. Heads is best approach on what is available, the anchor of trust being in the bootblock, not in hardware. The chain of trust lies there. Of course an evil maid could craft a firmware that would lie about its measurements in the bootblock, raminit, romstage and the payload. But as today, no PoC has even been made public, showing it being actoinnable, and by nature of TPM extend operations is nothing easy to realize, while possible.
I am just gonna highlight the critical part here one more time, since I sent you the same thing before and you didn't read:
> *Of course an evil maid could craft a firmware that would lie about its measurements in the bootblock, raminit, romstage and the payload.*
Yeah, I wouldn't call heads "best approach on what is available" and I do think Boot Guard is better, but at least he is honest about the actual mechanism and the very obvious attack vector.
But as you consistently slide any adjacent topic you can into a discussion about the Librem 5 (no matter how tortured a segue), let's go with that and revisit it.
I looked at your puri.sm link, and it mostly served to lower my estimation of the Librem 5's kill switch system. You can't disable the sensors in a trustworthy way without disengaging every kill switch at the same time, entering it into their Lockdown Mode. At that point it's just a still insufficiently air-gapped, highly underpowered Linux device which remains poorly secured against other side-channel attacks. The speaker which, by everything I could find, is still functional, the OS remains poorly secured against software attacks, it lacks proper hardware security, and so on.
It fails in terms of human factors, too. Joe Consumer thinks flipping off the mic switch prevents audio recording, but it doesn't in multiple regards. Even putting it into Lockdown Mode doesn't disable the speaker, which can be used to record audio despite your insistence that the device is fully secured when all switches off. Speakers can also be used to exfil data over short distances, demonstrated to work through walls.
Poor misinformed Joe Consumer is also still left with the same issues the other commenter has already identified in terms of the difficulty of securing any Linux computer.
But that's okay, because you only run trusted software. Until one of those trusted pieces of software include a compromised library, which happens often. You are, at that point, relying on the OS and its relationship to its hardware, which, flawed switch system aside, is highly insufficient. The device offers very little protection at that point. You know all this because you run Qubes OS, but hand-wave that away by appealing to trusted software as soon as the Librem 5 becomes the subject.
If I was modeling threats around protecting sensitive files on the device, not falling victim to attacks that could record audio and/or exfil data or otherwise leak, I'd still go with GrapheneOS on a Pixel 8 or later.
The Librem 5 wins for anyone who just wants a phone which runs Linux (which is a great thing and I wish we had more options which did that), but the security theater of that device is just goofy from top to bottom, as are its more vocal and less reasoned supporters. If one's threat model is, one sometimes wants to be able to turn off all radios and sensors, leaving the speaker functioning, with an otherwise poorly secured device, then, great. It's the device for you. But it's a threat model which will be practically beneficial to very few people, if any.
If your holy grail is having the radios off without other hardware or software considerations, great, you've found the phone for you. It's a brilliantly marketed device for well meaning but poorly informed people with underdeveloped threat models, and, I guess, for someone in your situation who's happy to make all of the above compromises to be able to physically disconnect radios.
Do you always enter Lockdown Mode before typing anything sensitive, due to the attack vector they highlighted about deriving typed data via sensor data? ('No, because I only run trusted software.' See above.) You literally can't disable the sensors without disabling all radios. They acknowledge that sensors are an attack vector worth addressing, yet don't put sensors on a discrete circuit. Like I said, great marketing. Otherwise pretty goofy.
Would I complain if the upcoming Motorola GrapheneOS phone had physical hardware switches? Sure, I'd take an additional layer of containment if all of the fundamentals are addressed properly.
But your argument is like bolting the world's best seat belts onto a motorcycle, and never missing an opportunity to tell the world about your belts, wonderful though they truly are.
Everything else is pretty much the argument though - who buys a phone with a microphone killswitch so good that for it to actually function you must also flip the other killswitches to kill both wifi and cellular connection? A microphone killswitch so impeccable that in order for you to not be snooped on you also have to give up texting and browsing the internet. Truely impressive stuff.
strcat said the opposite.
We can't be both right. According to the docs and schematics, I'm right. You now need a really good prove for the opposite.
I don't even feel like arguing against the absurdity of your arguments anymore. This is my last attempt at dumping it down a notch:
A "microphone killswitch" is supposed to protect the user against having their convos being snooped on when it's toggled and still be able to use the phone in a meaningful manner. A "microphone killswitch" that doesn't really function on its own and requires turning the entire device into a brick is non-fuctional for all practical purposes.
I might as well just invent a "microphone killswitch" that requires people to pull out the battery to make sure that they are not snooped on at that point.
LOL, it's hard to imagine a more ridiculous and self-contradicting statement than this.
1. It's just physically impossible to defend from tracking, when the phone has networking connections on. Not even on all-mighty GrapheneOS.
2. I am using a phone with the kill switches off in a meaningful manner all the time. It is a full computer running a desktop OS and can run any apps, including listening to music from a microSD card, reading saved text/pdf files, showing presentations with original LibreOffice, programming in any language with standard tools, and so on.
3. Even though the phone in the lockdown mode (with all three kill switches off) has no connections, if I'm ever in emergency and need some help, I can turn the phone functionality back on and call for the help I need. Obviously, privacy in such case would be secondary after health.
4. Unlike for GrapheneOS, there is no way to hack my kill switches for any money. I can be 100% certain that they work as intended, even if a state actor is against me. Yes, everything else might be compromised in such case but not the tracking and listening to me when I need true location and microphone privacy.
I can use GrapheneOS with the global mic toggled off and sensors toggled off/denied to apps. I can still text, browse the internet, and check my emails while talking to my friends. I can go about my day, receive notifications, be a productive member of society while being reasonably sure that no apps on my phone is snooping on my convos.
This is what most people expect of a "microphone killswitch". Unfortunately, the hardware killswitches on the Librem cannot provide even remotely the same level of assurances as even a software killswitch.
The Librem 5 is either fully offline or something can snoop on the convos while internet is on. How is that a sensible implementation?
> I am using a phone with the kill switches off in a meaningful manner all the time. It is a full computer running a desktop OS and can run any apps, including listening to music from a microSD card, reading saved text/pdf files, showing presentations with original LibreOffice, programming in any language with standard tools, and so on.
Yeah, I am sure this is what a sane person expects a functioning phone with a "microphone killswitch" to be - an offline pocket sized computer instead of a device for communication 99% of the time.
> Even though the phone in the lockdown mode (with all three kill switches off) has no connections, if I'm ever in emergency and need some help, I can turn the phone functionality back on and call for the help I need. Obviously, privacy in such case would be secondary after health.
Yes, I am sure the purpose of the phone is to make a call instead of being used for texting/receiving notifications when you are out and about.
> Unlike for GrapheneOS, there is no way to hack my kill switches for any money. I can be 100% certain that they work as intended, even if a state actor is against me. Yes, everything else might be compromised in such case but not the tracking and listening to me when I need true location and microphone privacy.
Ever considered that maybe, just maybe, a valid use case for most people is not necessarily to hide their location from the carriers 24/7 but to not have their private conversation snooped on?
Or perhaps, another valid use case that some people might want is the ability to be connected to the internet via Wifi while not having their location tracked by the carrier or their private conversations snooped on? I can give you another detailed explanation as to how standard Android has a location toggle that works while your desktop-Linux-in-a-phone can easily have the location tracked when Wifi is on (and without an OS compromise) if you'd like ;)
You can only do that, if you are sure your software isn't compromised. You can never prove that, if your adversary is sufficiently big.
>> Their microphone kill switch also doesn't prevent audio recording
More dangerous advice. The microphone kill switch prevents audio recording via the mic, not via the sensors or speaker. A Librem 5 user needing to secure against audio attacks would need to switch all kill switches off, not just the mic one (by Librem 5's own estimation), but would still be vulnerable to the speaker.
The effect of your participation in threads about projects you claim to care about is harmful. You're becoming the guy in the meme disagreeing with everyone, and clearly they're all in the wrong. Please do better.
This is indeed a misunderstanding, again. Reliable protection is possible - this is all I wanted to say. Not everybody means "all sensors" when they say "microphone". I took the phrase literally.
However your example is unrelated. Their arguments were rather reasonable and informative in the discussion you linked to. So I don't complain about that anymore.
You are very much saying that OP is an attack post.
Or at least implying the point that it is tonally dissonant to claim otherwise.
If you didn't believe it was wrong you would comment on the post but you are explicitly avoiding doing that.
Daniel Micay has a history of absolutely unhinged behavior online to the point that 2.5 years ago community backlash to his public behavior basically forced him to step down from leading the project.
Great project. It's hard for me to say if things have gotten better or worse since the change, but at the very least things had been quiet and drama-free for a few years. Finally.
Until today that is.
not enough people talk about how software projects also offer up a similar kind of atmosphere: you're suddenly hyperconnected with a whole bunch of humans you don't know and are receiving feedback from people outside of your immediate community. "hackers" for all the interesting ways they've contributed to computer science over the decades also have branches spawned from the original chronically-online, highly-opinionated and sort of antisocial and poorly adjusted sects of civilization. being the face of a project is like pouring rocket fuel on whatever predispositions you might have, and on more than one occasion we've seen people go from occasionally unhinged person to seriously unhinged.
this comes with a lot of bad outcomes for quite a few people, primarily it always has some serious amplification qualities to egos and narcissism. and for genuinely good and kind people who are just trying to share their value/contributions and are suddenly jettisoned into spotlights, we often see them suddenly step back and discontinue work on a project entirely.
we often see these departures and think solely "must be burn out" and don't put much more thought into what that means. but we don't do enough to frame how software projects just elevate people into a position that most people don't do a good job in mentally and socially, and how it deteriorates the pieces of them that make them feel like they're valuable members of a community/tribe. some have luck making their project communities their tribe, but that's obviously a risky step to take. for many who have a successful project, sometimes it starts as the most validation they've ever received and then they don't know how to reconcile with the exponentially-widened audience when negative reception starts pouring in.
daniel micay is just one of like.. many in these sorts of projects i've seen who are simply unfit for the role. for many reasons, i don't think he's a pleasant person at all. i don't have any answers here. i also see this in homebrew scenes for gaming, it's like my least-favorite human petri dish of software development enjoyers. lot of oddball developers in that space and quite a lot of incredibly dramatic fallouts and theatrics that seem to come with the anonymous nature of not tacking your real name / identity to a project, and a consuming audience that has zero idea what goes into development so the negative feedback/demands that come in are in their own way unhinged.
We have all of the parasocial behavior from bystanders as well. Cult mentalities and hero-worship. It's quite a strange phenomenon.
None of their behavior is unhinged, thats a horrible thing to say.
And no, it has not been quiet for years, attacks have still been ongoing.
I ask because I'd be pretty disappointed in GrapheneOS over that kind of thing and it'd probably at least partially change my opinion of them, but it's better to validate these types of serious accusations and get the full context.
He made it sound like Daniel was going crazy on him for no apparent reason over a single comment he posted on the Techlore video when for one, we were wary of him already due to past disagreements and, more importantly, that very video is responsible for the swatting attacks that were aimed at getting Daniel killed by law enforcement. The swatting attacks were carried out by someone who loved the Techlore video a little too much. Do you see where I'm going? Rossmann had voiced his support for the very video that is responsible for the attempted murder on Daniel's life, I reckon you will understand that Daniel was upset over this.
Not much time had passed since these attacks took place so Daniel messaged Rossmann to figure this out and explain to him what this was all about. In private mind you, whereas Rossmann decided this was peak content and live streamed it while the chat was still taking place. Any human being with a basic sense of empathy and decency would have not done this since it was obvious that Daniel was in a bad headspace.
Yet he did so anyway. I guess that's not all too surprising given it was an excellent catch for his following on Kiwi Farms which he caters to.
Per the video the chat exchange became about Micay claiming Rossmann was complicit in swatting just by leaving a comment on a video that was critiquing Micay's written communication, due to an alleged fan of that channel swatting them.
I looked up the tweet that Micay cited in that chat as being an example of harassment and it was an exchange with an F-Droid dev, where the full context linked was about Micay being so frustrated with how F-Droid's displays app permissions that he threatened to display a warning for all GrapheneOS users when the F-Droid app was launched explaining Micay's point-of-view about this, unless F-Droid changed it. It was that which prompted the dev to blow their lid.
Another F-Droid contributor then deleted both that dev and various of Micay's follow-up posts for the ticket for both being off-topic and against their conduct policies, so hard to judge anything further. Micay from that first tweet also cited another tweet that F-Droid devs were organizing raids on their issue tracker but the screenshot didn't show evidence of such coordination. If there was I can't tell from that tweet at least.
Like, the impression I get from all this as a third-party observer is of someone with strong opinions about how things should be done and funneled that energy into GrapheneOS, which by all accounts is a robust OS, security-wise, which is great. From HN anecdotes and other impressions I've read about exchanges though they predate the swatting attempt (judging by the date in this thread's article) and various pushback is said to get framed only as harassment (including a HN user who was labeled a troll).
More context is useful though and I'm not adverse to links/screenshots that provide more clarity.
Edit: I just noticed someone flagged my initial comment in the time between replies.
(But, if you ignore the rants, that's a fantastic OS.)
https://grapheneos.social/@GrapheneOS/116442796907613215
https://grapheneos.social/@GrapheneOS/116442754144530576
https://grapheneos.social/@GrapheneOS/116439834987996043
https://grapheneos.social/@GrapheneOS/116439798112845463
https://grapheneos.social/@GrapheneOS/116439747793648606
(the linked post in Mastodon is the one displayed with a bigger font, not necessarily the first at the top of the page.)
#2 on the other hand sounds unhinged, though no source is provided. Threatening legal action for broad criticism of project management is wild.
Other organizations having the resources to continue despite the damage does not mean GrapheneOS can or should deal with the damage it causes. That makes no sense and its excusing horrible behaviour from attackers. They arent rants, the truth just often requires more words than a lie, such is the nature of computer science.
As for part 2, Im really not sure what you expected to happen when you made a loaded statement erroneously accusing them of attacking others?
I like the product, and even recommend GOS to those who want a hardened phone OS. But goddamn, their social media gives me major red flags and I hate remembering that they exist.
I genuinely think that the information in this post is accurate, and at the same time, I think that it is painted in a way that feels off. Like the data is correct, but there are aspects that are clearly emotionally manipulative and combative.
I also have had some less than great interactions with GrapheneOS devs, when I was not seeking out interaction from them on social media (they came to my post and were combative) and played victim that I bullied them and was in league with the harassment campaign when I just asked them to leave me alone.
Overall, I just think that GrapheneOS is a good product, but unless you want to join their cult, just never talk about it neutrally or negatively unless you are ready for weird interactions.
I would go on a stretch to say that people that express themselves naturally, without detour, are maybe more trustful than the usual silver-tongued corpo.
1- GrapheneOS has a long history of long rants attacking people and projects. The leads will tell you that they're just correcting falsehoods etc, but a lot of companies/brands are target of falsehoods and don't bother to respond. I don't claim that GrapheneOS is wrong on anything they say, I'm just saying that these rants are a choice, and I see them as a red flag.
2- I once interacted with GrapheneOS on mastodon and I said something like the above. Something along the lines of "you know regardless of whether or not you're factually correct, these public attacks on other people companies are really bad for your image". Within 2 or 3 exchanged tweets they were threatening me with legal action. To me being a litigious project/person is an even bigger red flag than above. I have never in my life met someone who both lightly threatens legal action AND is an upstanding person.
Just my opinion, don't get upset over it.
EDIT: I just want to spell it out AGAIN - I don't claim that anything on their post is factually wrong, I have no idea.