One has to be careful when flying. Your flight's origin or destination might not be in China, and may not even be through Chinese airspace, but if there is an in-flight emergency, an airport in China might be the closest landing spot.
They're not being sold in Japan and based on existing laws wouldn't last long on the market if they were. As a longterm resident of Japan this is something I'm very happy about.
Good to hear, some countries already have some privacy laws protecting is from this type of products. Anyone has share more specifics about those laws, how's that they are effective in this case (unlike GDPR which is annoying and usually toothless).
It will hurt in future funding rounds if their subscriber metric is stalling or going backwards, regardless of how many of those subscriptions are profitable.
Every GrapheneOS proponent I've seen has claimed that other devices are inferior to Pixel security wise, and that's why they're not supported. That always sounded a bit odd to me and certainly seems to have a bit more nuance based on your comment. Thank you for adding some clarity here.
Graphene doesn't really try to stop you. They just don't spend their own efforts on making it possible. It is OSS so, your free to spend your efforts where you want to.
It would require a significant commitment of limited resources to broadly support insecure devices with very little upside, and to do so would constitute gross mismanagement of the project.
Meanwhile, others are completely free to fork numerous GrapheneOS improvements or benefit from their upstream improvements (as some have, including Google).
I never mentioned any commitment except accepting pull requests, did I? Qubes can do that and doesn't require a fork. Are you saying they have much more resources?
Every accepted PR for supporting insecure phones eventually becomes a maintenance burden, and potentially a security vulnerability. If they don't want to spend time on it, it's okay to decline such PRs.
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.
The problem with laptops is that UEFI is a shadow operating system that keeps running after boot, with a bunch of security vulnerabilities. Furthermore all Intel / AMD chips have a microprocessor state called SMF which if you trigger it basically gives you carte blanche to do whatever you want.
"Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain.
Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of.
So I understand why the GrapheneOS folks do what they do.
See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!)
You still need to address this part: "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of."
That's the crux of it you blow past every single time it comes up, and then disparage others as having not stuck around long enough to educate you (as if that's their responsibility).
> "Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can"
Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with.
> but cannot overcome the limitations of the platforms it builds off of
Yes, it can, if you use it correctly. Tell me your threat model, and I will explain how Qubes can protect you.
Perhaps you are right, and the hardware attestation is more reliable on a Pixel. However, doesn't it rely on proprietary hardware, unlike Heads? coreboot with Heads is not the same as Qubes AEM. Heads is updated regularly: https://github.com/linuxboot/heads/
Heads + TPM is solid but I suspect it is not at the level of Google/Apple secure enclave. And a strong secure enclave provides benefits outside of first boot to secure certain processor state and continuosly ensure integrity.
I think at cold boot as long as one doesn't store the encryption key in the TPM (external hardware key?) then one should be secure. I am not so sure about post boot however, once the system is already running.
This actually prompted me to research a bit on the scale of the security impact of SMM
It seems that coreboot is aware and supposedly for some computers can be implemented to catch calls to SMM (ideally this would prevent the attacker from triggering SMM - if they do it's game over).
I do suspect though that if the system bus is not protected from malicious calls then someone can trigger SMM and have carte blanche to one's computer.
I don't know what processes Apple / Android use but I suspect ARM chips don't have SMM and that they tie certain functions to their secure enclave. In X86 its backwards, with SMM having control over the TPM (at least in some implementations).
Though some SMM vulnerabilities are patched by now given its history I take X86 security with a grain of salt. I think the potential for a secure platform is there, but I suspect one would want to make their own boards engineered with security in mind to be certain (I hope this happens in the future - it seems to be happening in the server space already).
Versus storing the encryption key on a device requiring USB with its many vulnerabilities (even on Qubes OS), storing the key in a dedicated eSE is beneficial.
Beyond that, there have been known vulnerabilities of NitroKey's Librem Key, to say nothing of the Nitro Key App.
Nothing's perfect but I would vastly prefer something like the Titan M2's implementation over a USB key with all of the complexity and attack surface that introduces.
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.
As one who has lived out of both operating systems for years, I struggle with the way you invariably make value judgments about GrapheneOS every time it comes up in a thread, based on your (justifiable) appreciation for Qubes OS. The same thing happens in reverse on the GrapheneOS forums, by the way.
Both lines of thinking are faulty, and attempting to directly extrapolate from one project to the other (in either direction) mostly only conveys a lack of understanding of both projects, even (especially?) one's favored project.
Joanna Rutkowska herself admitted that the difficult nature of trying to contain the PC hardware stack made it ultimately feel like she lost the war. Qubes OS is inherently vastly more vulnerable than GrapheneOS, in large part precisely because of their different approaches to hardware. Some of this has been mitigated by developments made since she stepped back from the project, but some of it will always remain. How to deal with this inherent conflict is not a simple matter and the two projects have taken two distinctly different approaches.
In the cases of both projects, I think they made justifiable decisions in their approaches. I use and contribute to both projects.
If you've been using Qubes OS long enough, you'll remember a time when trying to run it on anything that wasn't essentially identical to the ThinkPads used by Qubes OS devs often presented a major challenge.
GrapheneOS is a fundamentally different project in scope, and each project has a subset of users which seem unable to do anything but evaluate the other project based on the criteria set by the one they like.
"The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware."
GrapheneOS achieves significantly more security on the hardware level than Qubes OS, in very large part specifically due to the nature of the project. It's also an infinitely simpler OS to get up and running with, on both current-gen flagship hardware and current-gen value-prop hardware available in just about any store which sells cell phones.
In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.
Securing a single device type with excellent hardware security is simply much more viable a project than securing a broad range of devices with hardware security that is, at best, pretty terrible.
Repeatedly criticizing one project without significant familiarity with both is not just pointless, it's counterproductive to aims of FOSS privacy and security.
> In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.
I critisize precisely because I don't understand what you're talking about.
The last relevant VM escape was in 2006, discovered by Rutkowska herself. Since then, nothing could access my secrets in an offline vault VM. I would appreciate a clarification, how GrapheneOS can be more secure without reliable virtualization.
AFAIK Xen security relies on 100k LoC. And this is in addition to the virtualization. How many LoC does GrapheneOS require to provide its security? How can it have less attack surface than Xen? Developers replying to me here never provided an understandable reasoning, only keep repeating that it's "very, very secure", without even mentioning any threat model.
Doesn't GrapheneOS rely on closed Google's hardware to provide its security? I would never trust Google with that. How can I not critisize such approach?
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"?
I really appreciate your detailed, good-faith responses.
> 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.
> Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous
Isn't this an important milestone, when the OS has no proprietary bits at all? This not the end, but something worth celebrating, I guess. Apart from that, doesn't Librem 5 has a lower number of blobs in general? I might be wrong of course.
> hand-waving IME (or PSP to whatever degree) as being "disabled,"
It seems you misunderstand me or didn't really read my previous posts carefully. I never considered "disabled" ME sufficiently secure. I strongly prefer "disabled and neutralized" instead, which I btw have on my laptop. It doesn't completely kill it, but it certainly makes it quite unlikely to make any harm.
> yet ignoring it when it doesn't isn't
I guess if I ignored something, I did not notice that it was relevant. Therefore I have no idea what you are talking about, i.e., which exact posts of mine you mean. If you actually want to be helpful, this is not how it's done.
> but "the last relevant VM escape" overly relies on "relevant,"
I admit that, and I specifically mentioned my threat model with passwords in relation to this. You didn't show how my threat model was wrong or not secured against.
Your other points are well articulated, although the corresponding threat model you mentioned is definitely not for everyone. Thanks again.
Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement, like seeing someone using a hammer to drive a nail and then attempting to use a hammer to drive a screw.
You also continue to shift the goalposts on things which I trust is not from malice but a hazy grasp of some basic fundamental concepts. You've already had it explained to you by people much more qualified than I how the Librem 5 has some entirely closed-source components running woefully outdated firmware, but now it's about celebrating something else entirely.
"Disabled and neutralized" IME is still IME that's highly privileged hardware running a closed-source operating system outside of your ability to monitor it. By the standards of evaluation you set in other comments baselessly criticizing Pixel hardware, you should object all the more to the x86 architecture, even with your ultimately insufficient attempts to reduce harm. The hand-wringing over the possibility that Google has embedded a still-undiscovered way to exfiltrate data from their phones even when running GrapheneOS, is misguided and unfair at best, and if nothing else you should be consistent in your application of these principles.
I trust I shouldn't need to cite every point you repetitiously make in order for you to stop complaining that I'm not limiting the scope of my reply perfectly to one particular comment of yours, as if this is some kind of contest of form.
If you kept current or really spent any time at all researching XSAs you'd know that its shared memory architecture alone has resulted in numerous XSAs, some of which could very much apply to your threat model. Hardware MTE would go a long way to mitigating that, which Pixels have. In the hypothetical scenario of Qubes OS running on more secure hardware than even your home brew situation, that would be a significant improvement over the status quo which you say you can't even imagine. You're defining your threat model overly narrowly by excluding all kinds of relevant factors and then declaring it wholly met. That's not how this stuff works.
If, after all this, you still can't imagine how Qubes could be improved upon for your particular threat model (having passwords in a vault appVM exfiltrated) after hearing just a couple hypothetical benefits of running it on more secure hardware, it's unsurprising you can't recognize the comparative advantages of GrapheneOS and instead want to rely on things like counting lines of security code because you once saw someone else do it in a different context.
My goal here is not to change your mind, that part is up to you and you've already had one of the finest minds in the field address your issues point by point elsewhere (that was a fun surprise to see). My goal is to reduce the ease with which you can continue to filibuster people into moving on with their lives so you can then continue making the same unjustifiable claim that nobody ever offers a meaningful explanation to you when you merely ask simple questions about the benefits of the project. Unstoppable Force Meets Argumentum ad nauseam.
> Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement
I guess you only opened my first link but not the second. Here is a quote from the second link for you:
> The size of the current TCB is on the order of hundreds of thousands of lines of C code, which is several orders of magnitude less than other OSes. (In Windows, Linux, and Mac OSes, the amount of trusted code is typically on the order of tens of millions of lines of C code.)
Server rendered HTML, htmlf endpoints and JQuery load was always the sweet spot for me - McMaster Carr[0] does the same thing behind the scenes and utterly destroys every "modern" webapp in existence today. Why did everything have to become so hard?
reply