madaidan

No, it's a publicity stunt. James has no interest in auditing CopperheadOS.

https://twitter.com/realmadaidan/status/1322225614636593158

CopperheadOS is a proprietary fork of legacy GrapheneOS code with most of the legacy hardening dropped due to lack of proper maintenance and it includes no substantial hardening. It also includes tracking in the updater to enforce their subscription fees (which is an exorbitant amount of money by the way, $150 for 3 months).

It's now a scam project focused on attacking GrapheneOS and harassing developers, as evident throughout this very thread with their usage of sockpuppet accounts.

https://grapheneos.org/#history

https://twitter.com/DanielMicay/status/1171170734380654597

https://renlord.com/posts/2020-03-25-copperheados-legal-thre...

> Daniel saying Mozilla is using 4chan posts to attack him.

And of course you don't show any context at all.

> Daniel stating he feels Brave has nefarious intentions.

The DRM is a valid issue. Brave is not impervious to all criticism.

> Daniel Micay attacking the Tor Project for considering use of his hardened allocator

That's not what happened at all. He never attacked them for that. He debunked the nonsense that Tom Ritter was posting. The Tor Project never even considered using hardened_malloc either. I suggested that Whonix use hardened_malloc and so HulaHoop (another Whonix developer) asked if this could affect web browser fingerprinting on the mailing list. No Tor Project developer made any indication that they wanted to include hardened_malloc - quite the opposite.

https://lists.torproject.org/pipermail/tor-dev/2019-August/0...

Have you even read these links or do you just want to mindlessly promote Copperhead?

> like wayland to address X security issues

The post does mention X's security issues. We are discussing switching to wayland but XFCE doesn't support it yet.

If we don't switch to wayland, I might add X sandboxing via a nested X server such as Xpra to sandbox-app-launcher. It's already on the TODO list.

> flatpak for sandoxing

Flatpak is not a good sandbox. It fully trusts the applications and the permissions are far too vague to be meaningful. For example, many applications come with "filesystem=home" which means read-write access to the entire home directory so to escape, they just need to write to .bashrc.

We're using sandbox-app-launcher instead.

> The way it's written looks more like marketing than anything else

Sorry for talking about our recent projects then?

Firejail has far too large attack surface and is suid root which has resulted in plenty of privilege escalation vulnerabilities.

https://seclists.org/oss-sec/2017/q1/25

https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

Also see this thread https://github.com/netblue30/firejail/issues/3046

Instead, we're going to use bubblewrap which is similar but with minimal attack surface. See the sandbox-app-launcher section of the post.

Qubes is just the hypervisor. The security within the VM still matters. Whonix supports being run in Qubes.

https://www.whonix.org/wiki/Qubes