F-Droid Board of Directors nominations 2026

To be clear no censorship occured. No app was removed or banned. Just recategorized

I still think they are planning on coming down side loading and app dev registration with newer phones

Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. Making very selective hardware comparisons while attempting to compare the relative strengths of the operating systems running on said hardware also indicates the same.

Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous.

Saying no hardware designed by Google could be trustworthy while advocating for x86 architecture and hand-waving IME (or PSP to whatever degree) as being "disabled," when no such thing is fully possible, is lazy. You don't get to care about this stuff selectively. IME when disabled to our fullest ability can still receive and apply microcode updates without the user's knowledge, making access to full unrestricted PCI lanes, DMA and USB possible. Wi-Fi certainly, at least in some specific scenarios. I'm not as concerned by IME/PSP as some, though I am much more concerned by it than some others, but the consistent selectiveness of your approach to attempting to understand that (and I'm taking it in good faith that you are) is precisely the kind of thing that makes people give up on attempting to give you additional information by which to reconsider your opinion.

Citing Joanna's research without any relevant context when you find it convenient yet ignoring it when it doesn't isn't helpful, either. You raise issues, people provide relevant research, and you ignore it while accusing broad swaths of people of doing the same. At some point it feels like projection.

I don't like even the appearance of unfairly criticizing the Qubes team publicly, because it's an important yet still-fledgling-in-resources project and they're doing amazing work nonetheless, but "the last relevant VM escape" overly relies on "relevant," and you overstate Xen's security because you're looking at it in isolation as if you can compare the relative security of operating systems while selectively comparing their hardware. The Qubes OS team has allowed significant Xen vulnerabilities to remain unpatched for weeks to months, sometimes not even capturing them in their XSA tracker. The GrapheneOS team seems fairly exemplary in pushing out important patches. I say this not to knock the Qubes OS team which does great work with very limited resources, but there are real, practical, significant differences in the two approaches and so long as you're comparing specific points in isolation of their broader context you're going to miss significant fundamentals.

Qubes OS's encryption situation out of the box is lacking in numerous ways which some Qubes OS users attempt to manually address. Consider the rigor it would take one to replicate your config vs. the rigor it would take to buy a Pixel and install Graphene OS. A journalist or dissident who is massively concerned with being in possession of data, the discovery of which could see them jailed or killed, is significantly better off storing that on a device running Graphene OS. That's not a hand-wavy thing, when you consider the full stack the advantages are numerous and concrete. There are many other practical differences between the two security models, when compared holistically. File system security of GrapheneOS is miles ahead of where Qubes OS is, and it's partly due to the OS, partly due to the differences in hardware. Brute force resistance is leagues better on GrapheneOS in part because the hardware facilitates it, and the OS does a best-of-class job at taking full advantage of that hardware.

At what point will you stop repeating your line of, "I keep asking for examples but they never answer"?

You're being disingenuous here. What is the value of accepting pull requests with no intent to approve? The rhetoric you're using here is on a I'm-just-asking-questions level.

You're not being consistent in what you're advocating. You mentioned accepting pull requests in the context of wanting to see broader device support. You want broader device support. I do too, which is the value of the Motorola announcement. Your suggestion isn't the way to achieve that. It just isn't viable for reasons you should reasonably already understand. But since you don't...

It shows yet again you just don't understand the project, how it's structured, and what its goals are. I'd say you should try running it, but you're still murky on the actual nature of the OS you use daily, so there would be no point in my suggesting that.

Assuming all you want is broader device support while magically not increasing the GrapheneOS team's overhead, but for reasons you haven't stated won't accept forking it, you're out of luck, which is right where you should be.

Still, why? If you want hardware which lacks security features to run an OS, the primary value of which is its close integration with said hardware security features, what is it you really want, then? A degoogled Android OS? That already exists. Are GrapheneOS's "software" security enhancements (as if we can say "software" in the context of security in total isolation) their quality-of-life improvements to the OS that you're after? Many of those would greatly degrade in value if you couldn't trust the hardware it's running on. You'd get storage scopes, but you'd get it without a file system you could trust. You'd get network permissions but you'd get it without baseband isolation you could trust. You'd get x, y and z, without memory tagging.

If that's what you want, you can get that elsewhere, and should.

But by the conditions you set up, you're also effectively asking for code contributions by outsiders, when the project very deliberately and by all indications very tightly manages who can contribute code, and for good reason. The history of open source is the history of malicious code injection and social engineering attacks. If you want the device to be secure you have to address security from all angles.

Unless you're really, genuinely, nonsensically proposing the project commit resources to allowing people to suggest code changes they have no intention of ever implementing. Though I suspect at that point you'd argue in favor of some code base changes, while not having addressed the fundamental implications of doing so.

You're doing a great job of arguing against yourself, here, and have highlighted a fundamental challenge with Qubes OS. As an active user on the forum I'm sure you've seen the reasoned discussions weighing the pros and cons of accepting code contributions. If your response to that is, again, 'there hasn't been a relevant Xen bug in two decades and my data has been safe this whole time,' that's a dead-end for understanding anything.

Your rhetoric in all this is very similar to the kind of thing one easily finds on normie websites about commonly divisive issues. At some point I just can't keep insisting you're either informed or sincere about all this, HN guidelines notwithstanding.

Adding: Qubes is really no better, and maybe worse in some ways, than having a discrete banking VM in your bare metal Xen hypervisor. Sure, there are some improvements such as handing input devices over to an appVM, those sorts of things one could do in Xen manually, but broadly speaking the value Qubes bring is it does an amazing job of making living out of a Type-1 hypervisor barely doable for some small subset of people. And the "barely" and "small" is increasingly shrinking with each major release.

The magic of Qubes isn't its isolation, it doesn't even provide its own isolation. Qubes is an integration layer added on top of an isolation foundation. So you have a clipboard, file transfers, window dressing, easy configuration of device pass-through rules, all that. It's great.

It's phenomenal at that. But you have to understand what it is. You have to layer on a whole bunch of additional cruft to the Type-1 hypervisor, potentially all of which introduces potential vulnerabilities to dom0 and/or relevant appVMs. (Fortunately the project moves very slowly even for its size, which gives me some reasonable degree of confidence in its third-party code contributions, if less than I have in GrapheneOS's team's contributions.)

GrapheneOS solves a lot of these practical issues in very real and excellent ways, and it does it in large part via its tight integration with the excellent hardware it runs on, "Google" notwithstanding. (Now, "Motorola." "Lenovo." "China." A poor architecture even when made in America is not a practical improvement.)

Qubes-by-way-of-Xen does it despite running on pretty horrendous architecture. Even with your labor-intensive and super geeky improvements you've made to your setup, an evil maid attack, a theft, coercion, legal and political forces, all of these factors hit a harder target in GrapheneOS than they do in any QubesOS configuration currently achievable. But, as stated, trying to contain the most dangerous software most people ever run, a web browser, from leaking into your password manager? It's great. If that's your primary threat model, it's difficult to beat. Profiles on GrapheneOS are also excellent for that, if less well-integrated and therefore usable as Qubes.

Qubes still wins in terms of virtualization, of course, and you're comparing the benefits of virtualization to all of the many other benefits GrapheneOS brings (and in many instances iOS too), but you're not comparing them meaningfully.

Type-1 style virtualization is on the GrapheneOS roadmap, and once they achieve that it will be vastly more secure than QubesOS running on any x86 concoction you can devise. Give me a ThinkPad that meets GrapheneOS's hardware requirements running a virtualization-based GrapheneOS implementation and I would have little reason to ever run Qubes OS again. That would be some kind of peak practical end-user security solution, and I'd imagine enterprise and state customers would flock to that, if the broader enterprise requirements of it all were met, too.