Graphene is not a consumer brand and they do not intend to be a consumer brand. They do one thing: make as secure a phone OS as they can. That’s it. If you’re expecting them to do anything in a friendly way, it ain’t gonna happen, that’s not who they are or what they do. That will absolutely limit their scope and reach, but it also allows them to focus on the one thing they’re trying to do without making compromises.
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.
> They do one thing: make as secure a phone OS as they can. That’s it. If you’re expecting them to do anything in a friendly way, it ain’t gonna happen, that’s not who they are or what they do.
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.
GrapheneOS needs to defend themselves. There would be more time for other types of posts other than defensive ones if they did not have to defend themselves.
As a community organizer for systems programmers: welcome to my world! I've finally made some headway after a decade, helped by the mass layoff apocalypse. (Turns out social skills help you stay solvent.)
Actually, you can't make a great product if you've alienated your allies, because all successes are intrinsically social, from the iPhone to Python to even the processor itself.
Going it alone is that nineties libertarian romanticism, a persistent self-destructive tendency that in present market conditions is unsustainable
If they were doing that one thing, they would not have posted this. It's fine not to market to consumers, but this raises additional concerns about the founder's judgement. Someone else claimed that they deleted update signing keys for copperhead devices. That's seriously concerning if true; possibly bad enough to switch away from grapheneOS.
He deleted the signing keys because it looked like the other owner of Copperhead OS wanted to make the signing keys available to government agencies and/or criminal organizations. He deleted the signing keys to protect their users against malicious updates, which is the right thing to do and should increase trust in him and the project.
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.
Is it that Donaldson wanted to pursue deals with criminals or he wanted to backdoor an OS for a defense contractor or that he was a government spy? From the article it seems like none. Claims need receipts or they are blind assertions.
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.
Ah, thanks for setting me straight. That's reassuring. I think I would still have more respect and trust for GrapheneOS if they either didn't respond, or struck a more neutral tone; but that's more subjective.
GrapheneOS has never concealed this information, it has been publicly accessible on the GrapheneOS website for years, as an article describing the projects history. https://grapheneos.org/history/
Deleting signing keys under threat of a hostile takeover is the responsible thing to do.
It's not just about being friendly. If they have a bubble around them of employees, true believers, and people just afraid of speaking out that chills free expression of criticism, the truth has trouble getting out, which hurts trust.
Maybe true, but but the flip side is that sometimes what is called an attack is actually criticism. That's how it appears to a lot of us from the outside.
GrapheneOS wants to post more positive things, rather than just defensive replies. But they have very little choice in the matter. If the inhumane levels of attacks werent happening, they would have more time to discuss future features, how they choose to approach features, etc. But ignoring the attacks only make it worse. The suggestions to ignore it, even if genuine, arent helpful.
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).
People can accidentally be spreading attacks with loaded/presumptuous statements even when their intentions are pure. Unfortunately, pure intentions can still cause harm that needs to be countered.
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.
All the stuff about members of our team not being stable is ridiculous and only works in favor of people or organizations that don't like us or want to damage GrapheneOS.
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.
> 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"
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).
Yes, I don't like when anybody spreads falsehoods about any important free software. Do you?
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 have been saying this sort of stuff on the Qubes forum and a bunch of other places for awhile now.
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...
> 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.
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.
> 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?
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.
> 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.
And what good is the phone when 3 switches are off? You think that people buy a phone with a "mic killswitch" expects to have to turn off practically everything including internet to make sure that their mics aren't snooped on?
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.
Oh he's already done that when I explained to him how stuff like PureBoot has circular logic and doesn't actually work on Qubes forum already.
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.
On Qubes forum, you had replies from far more knowledgeable people than me. You never could answer to them. You only talk about the lack of security of Pureboot and never showed the code breaking it. "Talk is cheap, show me the code".
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.
Thank you for your kind advice, but I prefer to trust a developer of Heads and many Qubes contributors instead of a loud Internet commenter criticizing everything and everyone.
The developer of Heads admitted that if someone tampers with the boot block and falsifies the measurements Heads cannot protect the device right on the Qubes forum. Why won't you listen to him then? Is he not trustworthy enough for you?
@TommyTran732, you are going to a great length to downplay everything about devices/companies promoting freedom, including Librem 5, Purism, and laptops with Heads. And you are promoting proprietary staff instead. This looks like trolling or astroturfing. For observers, here is the actual quote from the heads developer, not in the (incorrect) interpretation of TommyTran732:
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.
Yeah, why are you selectively reading? This is after he admitted what I said was true. His only contention is that he thinks it's hard to know what the PCR values should be to fake, so he calls that "security". You are being extra ordinarily disingenuous here.
> 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.
Qubes team never criticized Purism laptops for their lack of security. At least I didn't see that. They criticized other things, which may be important for some and less important for others. The phone is off-topic on the Qubes forum, so its security was never thoroughly discussed.
Everything Micay said in that linked thread was and remains correct. You again fail to address what was incorrect in his comment. Going on to later ask people "what is correct about it?" is rhetorically disingenuous at best.
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.
Not entirely sure if the chip they are using (WM8962) can be reconfigured as a mic or not... it probably can't. But yes, the speaker is still active even when the mic is toggle off.
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.
Man, if this entirely thread of people calling out how ridiculous the implementation is and the killswitch not actually working in practice isn't enough to convince you, nothing ever will.
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.
> 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
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.
> It's just physically impossible to defend from tracking, when the phone has networking connections on. Not even on all-mighty GrapheneOS.
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 ;)
>> 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. Please do better.
Librem 5 speakers cannot be used for recording, according to the developers. Yes, all kill switches protect you from the sensors.
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.
> Their entire post regarding pinephones is accurate.
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.
Why would debunking factual inaccuracies be a red flag? It's the rational action to take, actually. Big corporations often don't respond because their lawyers tell them not to. Surely you're not saying that's a green flag?
I think this is the case of a lot of successful OSS. Intrigued people of all horizons comes and interact with few people building something meaningful, mostly on their free time, and expect to be welcomed as customers by the company spokesman. Torvalds had a famous way to express himself freely and hurt some feeling on the Linux mailing list, yet Linux is still a successful OSS project.
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.
One of the main criteria to differentiate "rants" from "correcting falsehoods" is proper citing of sources. In the case of Grapheneos, unfortunately I often see very few sources in what they post online.
(But, if you ignore the rants, that's a fantastic OS.)
GrapheneOS has plenty of evidence and they post it alongside their claims. They post it carefully though, and are willing to provide it to people upon request.
At the time of writing, I scrolled 4 posts down and found one. GrapheneOS are security researchers, so they often are a first party source. As for the attacks, they have plenty of evidence for their claims. They avoid giving any attacks more publicity, but they usually provide evidence if you ask.
Please provide a link to this post you found, so I can tell which one you think is a citation to a source. If you want some examples of recent posts that should have a source but don't, here they are:
They dont have any history of attacking others. They have a history of defending themselves from attacks.
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.
Do you have a link to the mastodon interaction where they threatened you with legal action?
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.
I don't. My very vague recollection is that I was alarmed and either deleted it or blocked them. So it either no longer exists, but even if it does I have zero interest in digging it out. I'm always anonymous on social media like HN and Mastodon, but who knows what one can discover if they're the kind of unhinged person who will dedicate enough time to doxing someone...
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.
#1 imo is the fact that some orgs are resilient to libel, and some are heavily affected. If someone is lying about your security protect in order to harm your reputation, I don't find it odd to respond with some zeal.
#2 on the other hand sounds unhinged, though no source is provided. Threatening legal action for broad criticism of project management is wild.
None of this is accurate. Community backlash was not what forced them to step down. The attacks, including attempted murder, was what led them to handing the lead developer position to another trusted project member.
Attacks against GOS have not been quiet for years, attacks have still been ongoing during that time.
i think a lot of attention is rightly attributed to like, i dunno say tiktok/ig "influencing" and how that can send people who gain a lot of notoriety off the deep end. it absolutely has. but so do software projects.
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.
Speaking of trust issues, Rossmann's claim he was going to stop using GrapheneOS proved to be a lie, he was caught using it for months after. He knew it was impossible for us to target him with an individual update, that didn't stop him from including that supposed fear in his sob story though.
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.
Micay was distressed due to ongoing circumstances. Rossmann choice to publicly blast what was supposed to be a private discussion, lied to his own viewers, twisted what was happening, etc. Also note Rossmann has an identity verified kiwifarms account.
