>their security model is the only reasonably secure approach in the world

They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems.

QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.

▲

strcat 2 days ago | parent | next [-]

See the response at https://news.ycombinator.com/item?id=45244398.

▲

fsflover 2 days ago | parent | prev [-]

>> their security model is the only reasonably secure approach in the world

>They have not said anything like that.

Quote (https://news.ycombinator.com/item?id=30769666):

> Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required.

The reality is that Librem 5 is secure according to a different threat model than the one GrapheneOS follows. This doesn't make it "incredibly" insecure, unless you believe that only you can define good threat models.

▲

strcat a day ago | parent | next [-]

Librem 5 not only doesn't provide firmware updates for serious security vulnerabilities but goes out of the way to block the OS from doing it and block updating firmware in general. It uses a bunch of low security components. It's a closed source device with closed source firmware. Not updating the firmware from the OS has nothing to do with a threat model but rather a loophole in a definition of freedom where a device with a fully closed source OS would be considered free as long as it couldn't be updated by anyone...

	▲	fsflover a day ago \| parent [-]
		> Librem 5 not only doesn't provide firmware updates for serious security vulnerabilities but goes out of the way to block the OS from doing it and block updating firmware in general This is plain wrong: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque... (And I think I already told you that once. Upd: @amosbatto did: https://news.ycombinator.com/item?id=30769589, and you ignored that.)

▲

ysnp a day ago | parent | prev [-]

Sorry, but it is very difficult to understand what you mean and what you want from GrapheneOS. GrapheneOS is a FOSS project and they have committed to that being the case for the forseeable future.

They have expressed interest in open hardware, well-designed open source secure elements, open source blob-free firmware with proper signature verification, open source greenfield kernel and OS projects, hardware kill switches with a proper threat model etc.

Why should anyone expect them to throw away everything they have accomplished to start several steps backward on platforms that don't achieve any of these things?

▲

fsflover a day ago | parent [-]

> Why should anyone expect them to throw away everything

I don't expect them to throw away anything. I just wanted to get a statement from them concerning what's a reasonable goal and what isn't. But still:

- to break from their life-threatening dependence on Google? https://news.ycombinator.com/item?id=45208925;

- to allow more people benefit from a better security, not just those who can afford a Pixel?

> open source blob-free firmware

Where did you find that?

> open source greenfield kernel and OS projects

I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware.

> hardware kill switches with a proper threat model

Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches.

	▲	ysnp 13 hours ago \| parent [-]
		>I just wanted to get a statement from them concerning what's a reasonable goal and what isn't Please contact the OEMs/manufacturers and ask them why they cannot support reasonable requirements like: minimum five years of full (OS, firmwared, security patches etc.) device support code, hardware accelerated virtualisation, isolated radios (Wi-Fi/Cellular/Bluetooth etc.), a decent secure element implementation and support for throttling, proper Wi-Fi privacy support etc. (https://grapheneos.org/faq#future-devices) You are clearly passionate about this, and you are not alone. But I have never understood why people expect GrapheneOS to compromise their goals and values, rather than wanting others to improve to meet them. GrapheneOS is completely free. >to break from their life-threatening dependence on Google? They have had talks with at least one OEM in the years past before the recent round of communications, trying to secure support for GrapheneOS on non-Pixel hardware. They have had builds in the past for Samsung hardware and development boards to explore alternative platforms and interest in minimal blob platforms which they had to abandon because those were not suitable for the project long term. They have always been completely willing to support non-Pixel devices that meet their requirements, but none have been available or validated so far. It's not appropriate at all to say they have no interest in breaking their dependence on Google Pixels. Personally, I think it's bizarre that numerous companies like Fairphone, Punkt and OSOM can come and go without ever seriously attempting to meet the reasonable requirements set by GrapheneOS and offer alternative options. >to allow more people benefit from a better security, not just those who can afford a Pixel? GrapheneOS is not a hardware manufacturer with the benefits of economies of scale. If they could magically create an affordable device that met their standards they would do it... As you already understand, GrapheneOS is a project with limited resources. They put those resources to use in significantly improving the privacy/security for an operating system (OS) that guards regular people's most personal data and device. Any device they support that lowers that standard means much much more time spent on device support and much less time on important work that improves on what you can have now (GrapheneOS + Pixel 8 and above). GrapheneOS is also open source, so nothing stops you or I from adapting parts of it for a less suitable platform and releasing that for others to use. DivestOS for example used code and ideas from GrapheneOS in their own project, and GrapheneOS were always supportive of the project and even offered the founding developer a role in the development team after they stopped working on DivestOS. >Where did you find that? As I've said above, it is something they experimented with in the past. But the reality is that they are intimately familiar with some past and present projects around that area including Raptor Engineering stuff, SiFive, Betrusted, coreboot, OpenTitan, Tropic Square etc. GrapheneOS has always been deeply interested in quality open source software and open hardware, unfortunately they just never had opportunities to support those things while improving on the progress they have already made. >I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware. I did not say Pixels are a blob-free platform. I said GrapheneOS have expressed interest in open source kernel and OS projects even outside of GrapheneOS itself. >Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches. No, I don't mean usability, I mean physical privacy switches with a proper threat model. GrapheneOS have stated they would be 100% interested in usable privacy switches for specific goals like stopping audio recording or location detection but it is a lower priority than other ideas they have to improve privacy/security on the device as a whole.