github.com/GrapheneOS/har… was initially released in August 2018. I developed it to replace the port of OpenBSD malloc to Linux and Android that I made in 2014.
Copperhead was founded in late 2015 and split from my open source Android hardening project in June 2018.
My open source Android hardening project had already been renamed to the Android Hardening project when hardened_malloc was developed and released.
The hardened_malloc license requires attribution. License and copyright header needs to be included by anything using the code.
Copperhead is misrepresenting my allocator hardening work throughout the years as their own. They're fraudulently misrepresenting my open source work throughout the years as their own and by not complying with the licensing. This is a particularly egregious case of it though.
I have never been an employee of Copperhead. There was never any employment agreement or salary. They made retroactive changes claiming I was an employee in 2017 and early 2018 before pushing me out. Even if that was true (it's not), this work was not done in that time period...
Copperhead also fraudulently claims to have upstreamed code in AOSP, which is not the case. I landed changes in AOSP as an individual. I explicitly signed the CLA with Google as an individual. They also falsely claim credit for work done entirely by Google with no coordination.
Similarly, they've tried to imply that they have involvement in the Seedvault project which is not the case. They've made no contributions to Seedvault. It was created by Steve Soltys and @calyxinstitute has done the bulk of recent development. Copperhead has no involvement.
My involvement in Seedvault was coming up with the concept and inspiring the author to create it. Calyx stepped up to help get it past the finish line to a stable release and is continuing to make substantial improvements. This is a team effort, not involving Copperhead at all.
Copperhead continues to claim credit for work done by others. They also falsely claimed that Calyx and many other organizations were their partners when it wasn't the case. They've removed those claims, but they continue to make these kinds of false claims. The fraud never ends.
Copperhead has never included a one-time permission grant feature. That was developed by Google for Android 11.
This was the downstream background access feature:
Android 11 just changes the permission request interface to inform users of the restrictions. The changes were all done by Google. It was never "upstreamed".
It has always been the case that developers working on the project own their own code. There has never been any kind of copyright assignment, and it has been explicitly communicated throughout the years that this is the case. It was no different when Copperhead was sponsoring it.
It's quite sad that a company can get away with fraudulently taking credit for the work of others and earn substantial revenue from selling it as a branded closed source product. They don't have an understanding of what they've taken and are shipping a broken, insecure product.
CopperheadOS is a closed source with tracking for license enforcement. It masquerades as hardened and they take credit for the work of the developers they're trying to wipe out. They take our work while trying to destroy our project with baseless lawsuits and misinformation.
Copperhead filed a baseless lawsuit against us based on their false claims. We've filed counterclaims against them and we're filing our own lawsuit against them based on their fraud. You can read our initial legal response here:
CopperheadOS at the time that Copperhead split from the project was almost entirely created by me and all my work was attributed to me as the author and owner. This was always agreed upon. Nothing was assigned to Copperhead. Nothing in the code was ever attributed to the company.
They even try to claim ownership over my open source work done before the company existed and after they stopped sponsoring the project. It's simply ridiculous. They sell an very expensive product that's just a poor imitation ripping off the real thing. It's incredibly pathetic.
Meanwhile, while they're spreading misinformation, threatening open source developers and filing a baseless lawsuit they claim that we're "bullies" for defending ourselves and talking about what really happened and is happening. That's some seriously screwed up projection...
The CEO of Copperhead, James Donaldson, is a narcissistic psychopath. He pretended to be my friend while manipulating and gaslighting me for years. He completely betrayed me and went back on all our agreements. He has tried to retroactively rewrite history, but it won't work.
We have records proving these falsehoods along with witnesses who experienced these things publicly and internally. If you want to help us, get in touch with me or help cover the expensive legal fees (grapheneos.org/donate). Legal fees for September alone were just under $5000.
I'm still co-owner of the company with 50% of the voting shares. It doesn't belong to James Donaldson. The lawsuit we're filing ourselves is focused on fraudulent claims by the company about the authorship and ownership of the code. We may need to file other lawsuits beyond that.
Stealing over $100k of donations from the project in violation of our agreements and what was promised to donors is one of the particularly egregious actions.
He has abused his the position as director and has a total disregard for his obligations to me as a 50% shareholder too.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
We need help building a more complete historical archive of the GrapheneOS code. Please get in touch with me if you have clones of the Git repositories from 2015 or earlier. The repositories on GitHub were the ones created for the CopperheadOS Beta but don't have older tags, etc.
There was an earlier generation of repositories for the CopperheadOS Alpha and earlier when the project was based on CyanogenMod, including before it was branded as CopperheadOS. It would be ideal to obtain an archive of this code. Obtaining this would make a big difference.
The network graphs like github.com/GrapheneOS/pla… and github.com/GrapheneOS/pla… show some of the forks of the project from the CopperheadOS Beta era. There were also forks in the earlier Alpha era and earlier. Ideally, we can get a full archive of it, not just specific repositories.
@mamushi_io@intimitatem@Fonta1n3@GrapheneOS You're just selling a proprietary project forked from our code in violation of the licenses. You're supporting a company that's anti-open-source and is waging a nasty war against the open source project they depend on. It's hard to take a proprietary ripoff seriously.
@mamushi_io@intimitatem@Fonta1n3@GrapheneOS CopperheadOS is a fork of our legacy codebase in violation of the licenses with DRM and tracking added to the Updater app. It is primarily just AOSP with a custom boot animation and wallpaper, since they have not meaningfully maintained or developed real privacy/security work.
@mamushi_io@intimitatem@Fonta1n3@GrapheneOS You're selling people a very expensive product that's making them less private and secure. The original open source project is available for free with far more privacy and security, and without tracking. People are far better off with iPhones than yet another 'secure' phone scam.
The public Android security bulletins are not nearly as useful as they used to be since so much information was stripped out of them. Need to figure out even basic details entirely from the commit message and changes to the code. Internal bulletins still have more information.
This makes it difficult to figure out when a bug was fixed with only the details of the bug including the impacted subsystem but not a CVE ID. threatpost.com/bluetooth-spoo… says the issue is unpatched on Android but that seems based on the researchers testing a device without updates.
It's highly likely that android.googlesource.com/platform/syste… is the fix for this issue since it's a fix for a security bug in pairing tied to authentication of a device that was previously paired. I'm not entirely sure it's the same bug since there aren't enough details available for the fix.
Android 11 disables usage of stable "privacy" addresses for networks where MAC randomization is being used. We'll no longer need to disable this feature. The other issues we've discovered and put initial work into addressing are still problems though.
Disabling IPv6 would certainly be an easy way to address multiple issues in the Linux kernel implementation providing a way to track users across networks. Linux kernel's take on "privacy" addresses regresses privacy in some very serious ways.
Linux reuses "privacy" addresses across networks. This leaks that it's the same device connecting from a different network. It does this even when randomizing the MAC address. It also uses a very long lifetime for these addresses by default. It's a pretty bad implementation.
Unfortunately, some users upgrading from this cancelled beta release may encounter a broken upgrade path to the next beta release where the device forces you to do a factory reset. This is caused by downgrading the kernel, but we're unsure exactly why.
Our suspicion is that the backport of f2fs made changes to the on-disk format that are not backwards compatible with the previous version. It's seemingly only an issue on a subset of users on the Pixel 3a and Pixel 3a XL. This does not impact people that aren't beta testing.
We always test the future upgrade path before pushing out a release to the beta channel. However, in this case the upgrade path is being broken by reverting a large set of changes that proved to be too problematic for us to ship rather than waiting for Android 11 as a whole.
When you decode media with hardware decoding, you're depending on the security of the media decoding firmware / hardware and again IOMMU isolation to provide any kind of sandbox. You depend on the security of the CPU. When you go browse the web, running untrusted JavaScript code,
you are assuming that the CPU is actually capable of safely running that code without it gaining control over everything else. You're relying on the firmware / microcode / hardware security. A best case scenario is they designed it to update as much as possible after the fact.
Otherwise, a hardware vulnerability is found, and they are often found, and you're just screwed. We live in an time where serious game over bugs exploitable by JavaScript code are being published and fixed via microcode / firmware updates for CPUs and GPUs on a regular basis.