> They "handle the business" while someone else does 99% of the actual work, then ask to split 50/50.
As a response, Micay decided to destroy the update signing keys for all the CopperheadOS devices out in the wild. Resulting in financial damages to Donaldson.
Hardly a level-headed response, even if you disagree about the financial share of something.
That is a perfectly level-headed response. Signing keys must be protected. In the event of a hostile takeover, where a malicious party seeks to compromise the privacy and security of your userbase, destroying the keys is a sensible decision. Failure to do so, and successful compromise of the keys, will let the malicious party push whatever update they want, and it will be accepted due to being signed correctly.
It was not a disagreement about shares, it was a hostile takeover. Someone who never owned the project sought to steal it.
Exactly. It was a bold and necessary move to defend the users and the project. Some users got bricked OSes, but had he handed over the keys it would have put those users at risk and would have destroyed the credibility of the project.
Also, and as from what I understood from the GOS response he was not an employee of the company and had the ownership of his OS, and CopperOS would have been able to use their own signing keys but they never did which is strange, so even legally it looks like a "level-headed" response.
> Hardly a level-headed response, even if you disagree about the financial share of something
According to the linked responses, the keys were not deleted because of disagreement over financial share, but over how the keys were to be used (in particular, in potentially dangerous security-wise ways), for which he did not want personal responsibility over (the keys belonged and used by him even before that project)
Phantom Secure is directly named as one of the parties Donaldson was dealing with, with others being suspected:
>Donaldson tried to make a deal with Phantom Secure, which ultimately didnt work out. Micay suspected other counterparties were linked to organized crime, but we cannot confirm those identities or ties on short notice. Donaldson began pursuing such deals before Micay left and continued afterward.
Stated by Micay/Graphene, who has also stated /e/ is in cahoots with the French government, CalyxOS is to thank for his swatting, F-Droid conspires against him and Rossman being a Kiwifarms supporter.
You can't believe someone who has constantly claimed things without receipts.
The claims arent vague, they are quite specific in what happened. This wasnt spiteful and this wasnt disgruntled. It was the logical choice given the circumstances.
Hey! On a quick introductory note, I'm the community manager and the person who was interviewed. Please, read questions 17, 25 and 26 and our respective answers to them in the linked forum thread. In particular the following parts that I'm pasting here for convenience:
Question 17: Did your and Donaldson values begin to diverge? Was Donaldson more concerned with making money than you were?
Answer: [...] 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.
Question 25: Did things between you and Donaldson devolve when he approached you about a compliance audit? Did he tell you that he needed to know how the signing keys were stored?
From Wired:
We understand that Daniel's recollection was not that James wanted to know more information about how the signing keys were stored, but that he wanted direct access to them.
Question 26: Did you suspect his request was tied to a deal he was brokering with a large defense contractor? Did you believe this would put the entirety of CopperheadOS’ user base at risk?
Answer: Yes and yes.
The large defense contractor in question was Raytheon. The decision to destroy the signing keys was not based on a financial disagreement, but an existential one. Every single CopperheadOS user back then would have been compromised otherwise. It's of course a big deal given the implications, but it acted as a last resort for Daniel to stop a hostile takeover attempt fueled by greed, which he ultimately took because there was no other way out.
IMO its a lovely paradox that no one can argue against such a deletion. Either the party choosing deletion is reasonable so there are grounds for deletion or unreasonable and they are the grounds for deletion.
> We understand that Daniel's recollection was not that James wanted to know more information about how the signing keys were stored, but that he wanted direct access to them.
> Did you suspect his request was tied to a deal he was brokering with a large defense contractor? Did you believe this would put the entirety of CopperheadOS’ user base at risk?
They were compromised. Greed overtook the principles on which the project was founded and put the project at risk. They agreed from the start that Micay would own the project and hold the keys. They explicitly accepted those terms. Despite this, they tried a hostile takeover anyway.
Forking and building a separate build isnt dual signing, its just forking. You can do that right now with GrapheneOS and its build guide if you want.
Im not sure what you mean by the last part, GrapheneOS has been quite upfront with all of this from the start.
From a security-minded user perspective it makes sense to destroy keys when instead of a single entity I receive updates from I get another entity that is not equivalent, and half of my previous entity thinks that the other half is sus.
It wasnt intelligence agency compromise, it was a business partner compromise, who intended to violate the privacy and security of their users. Nothing about this is done out of spite. Im not sure where youre getting that from. You just seem to be attacking peoples character for making the right choice given the circumstances.
So what? Causing someone financial damages isn't illegal. Your boss causes you financial damages when they fire you. Your competitor causes you financial damages when they offer a discount.
If Micay was a 50% owner, sounds like he didn't do anything illegal. Immature maybe, which simply puts him at parity with the other party involved.
Yeah, that’s the issue. I don’t want people who behave immaturely, impulsively, or vindictively, having a key role in something as important as my phone os. I want stability, maturity, and thoughtfulness.
That is what CopperheadOS, and now GrapheneOS, provides. Its a level of "battle tested" that most OS and app devs never have the opportunity to have. Deleting the signing keys during a hostile takeover attempt rather than submitting to pressure or greed is an amazing quality that is rare to find.
So what exactly would you have done? Risk the key being taken over by a shady entity? Does the alternative really scream "mature, stable, and thoughtful" to you?
It looks like a very mature action to me: It certainly avoided the compromission of an OS that aims to be secure after all. It is not some windows OS with encryption keys sent to the cloud, so if security is compromised I fully expect targeted devices to break.
Understandable wishes, but you might have to put something from yourself into it if this is a pressing concern. Or you will be left to your own corporate devices.
The leadership is great. Persistent, patient and friendly.
They were able to improve. I don't think many of the often negative and ad-hominem critics would be able to endure such a pressure as they had in the past.
The GOS (GrapheneOS) lead had responded to criticisms like yours that he gladly retreats inside his tech role if others would take it upon them to refute the claims from rivals. So if you are that balanced, normal person, you could take that work out of his hands. Or help fund a full time PR person.
«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.»
Micay is rightfully paranoia, just having a GOS phone makes some government agencies quite mad. There are many ways a project like GOS could die, disinformation could certainly kill it. Other projects don't help the case if they throw mud at it. Rather, they should focus on their real technical shortcomings, but such articles aren't written somehow. https://eylenburg.github.io/android_comparison.htm
EDIT
> Should I make my own fork?
You could contact him to offer your help where he falls short.
Mental health and wellness issues in high tech research and development are everywhere. I would suggest that you focus on the product and what it can/cannot do for you.
Suggest away. It’s still a factor in my decision making, because if I can’t trust the developers to behave well, i can’t trust the product to continue to do what it says it can do for me.
Destroying the signing keys in the midst of a hostile takeover is the responsible thing to do. Its for the safety of their users. Thats a commendable trait to have.
Things aren't only bad if they're illegal. There's plenty of bad things one can do that are perfectly legal, and plenty of good things one can do that are totally illegal.
Micay owns the whole project. Ownership of the project was not exchanged or divided, part of the explicit terms of the agreement were that Micay would hold the keys and ownership of the project just as they always have.
Thats a characteristic all modern OSs and modern apps have. You need to trust the key holders, always. Some people make their own builds for this reason. Depends on the threat model.
> 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.
> 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.
I find the whole OVH web control panel atrocious. It's so buggy I couldn't even have my account deleted, not even after contacting their customer support (they just told me to fix it myself using their APIs...).
> Since you can't really quantify these properties (as opposed to: the problem is either solved or not)
I think we could quantify these properties, just not entirely.
One could take a long-term project and analyze how often or which approaches resulted in a refactor. In the same way, we could also quantify designs that resulted in vulnerabilities (that we know of) the most often.
It even wouldn't be impossible to create artificial scenarios. Projects that have an increasing number of requirements, see how many code changes are required, how many bugs result from that. Again, quantifiable to some extent. Probably better than datasets totally lacking something like that.
There probably isn't a public dataset on this, but it wouldn't be impossible.
I would suspect that some of the slowdown that the author encountered does occur with even a dozen or so add-ons. Why else would Firefox bother you about resetting your profile if you haven't returned in a while?
Judging from the side it seems like there aren't a lot of developers and the current few have their favorite subsystems, those get almost all of the attention. The rest is kept as-is and does not progress. I also don't know if there's a trivial way to find how many external contributions they get from BugZilla, if they even get any?
I've tried so many while doing a bit of research into MUAs and I can't say there are any alternatives that could replace it properly. But depending on your usage or if you're not a demanding user, there might be something out there.
reply