Earlier quoted context omitted.
It's quite secure against casual attacks, but a proprietary mobile platform has inherent issues wrt. withstanding even mildly sophisticated attackers, including mercenary spyware services. You still have a huge attack surface from all sorts of proprietary firmware blobs and hardware IP blocks that are running directly on the SoC. It's not clear that it's really worth even trying to secure it as opposed to just treati…
well, a concerted attack could easily subvert the baseband if you have a few million dollars and the correct letterhead or private contacts. GrapheneOS really wants the software in the phone to not pwn the phone. This is good. Its a different, and much more difficult problem to secure the connection to the telco, and the larger internet, because the transport is attacker controlled. Think of it this way: Say you use…
GrapheneOS – Break Free from Google and Apple
851–860 of 967 posts
Re: GrapheneOS – Break Free from Google and Apple
#852Re: GrapheneOS – Break Free from Google and Apple
#853Earlier quoted context omitted.
Author is installing Google Play Services it seems, wouldn't that work around this? In any case, for me this also sort of defeats the purpose: I'd rather break free from Google and Apple, not just (stock) Android and iOS.
No, because most banking apps call upon the Google Play Integrity API, which GrapheneOS doesn't (or can't?) use. There's a decent list kicking around of which ones work (Monzo, for instance). https://privsec.dev/posts/android/banking-applications-compa...
Re: GrapheneOS – Break Free from Google and Apple
#854Earlier quoted context omitted.
The (desktop) Linux security model is different. You trust the distro maintainers in the same way you trust the GOS devs, and instead of "app sandboxing" you use user accounts, containers or VMs to protect personal information. The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
> The (desktop) Linux security model is different In that it doesn't really exist. Sure, linux has all the capabilities to do it properly, but defaults matter in security so the way it currently works, basically every program has access to everything actually important (personal files, photos, ssh keys, etc). It just can't upgrade your GPU driver.
I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user.
You can't fix the lack of trust you have on Android with just sandboxing.
Re: GrapheneOS – Break Free from Google and Apple
#855Earlier quoted context omitted.
> The (desktop) Linux security model is different In that it doesn't really exist. Sure, linux has all the capabilities to do it properly, but defaults matter in security so the way it currently works, basically every program has access to everything actually important (personal files, photos, ssh keys, etc). It just can't upgrade your GPU driver.
Security goes way beyond a technical checklist. I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user. You can't fix the lack of trust you have on Android with just sandboxing.
As has been shown, it's almost trivial to get malicious code merged into open source projects, so not really sure where your "trust" comes from. It's not trust, it's naiveness.
Re: GrapheneOS – Break Free from Google and Apple
#856Earlier quoted context omitted.
I have been a user of /e/OS for 5 years, and also of GOS and would like to share my opinion on this: > it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS What I have seen (and I am not involved in any of those projects) is that GOS does care a lot about security, has a higher quality in that regard than anything else, and tends to be…
The founder and CEO of /e/ and Murena openly spreads content from Kiwi Farms and neo-nazi sites. He directly engages in harassment towards the GrapheneOS team. Here's him supporting authoritarians smearing GrapheneOS by replying to threads about it linking to harassment content based on fabrications on a neo-nazi conspiracy site: https://archive.is/SWXPJ https://archive.is/n4yTO The communities of several projects in…
I find it very hard to reconcile claims like "repeated swatting attacks aimed at killing our team members...Child Sex Abuse Material..." with the proof offered being a blog post that makes the fairly anodyne (especially read in light of this comment) case that you are an extremely paranoid person whose paranoia leads you to extreme judgements that may harm users. If you are the target of extreme attacks, it seems far more plausible to me that those originate from state actors and security adversaries, rather than from erstwhile allies also trying to build better mobile OSes.
Rather than reading this as "harassment", I would suggest you should try to take it as constructive feedback: You do not play well with others and your prickly interpersonal demeanor hampers the adoption of what is (by all accounts) technically strong software.
Re: GrapheneOS – Break Free from Google and Apple
#857Earlier quoted context omitted.
Meanwhile, it's probably A-OK for the app to run on a phone that hasn't received security updates for 5 years. I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date? I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secu…
Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years. For example, a malicious OS maker could add their own certificate to the root store, essentially allowing them to MitM all the traffic you send to the bank. Liability works on the principle that "if it's good enough for Google, it's good enough for me." A bank cannot realistically vet ev…
That's just straight-up false ; the phone without security updates has known exploits its user knows nothing about (and certainly not how to avoid them). The phone with an unknown OS has a user capable of installing said OS, at the very least.
Re: GrapheneOS – Break Free from Google and Apple
#858Been running GrapheneOS for a while on a Pixel 9, and extremely happy with it! Apart from the usual perks of the FOSS ecosystem, there are a few things specific to GrapheneOS that are not immediately apparent but have turned out to work very well - 1. The Pixel camera app works, including all modes and settings. A camera that takes good photos was absolutely a requirement for me, and the FOSS camera apps are not quit…
I originally wanted to get the Pixel camera app working when I got started with GOS a few years ago, but then I found Open Camera and haven't looked back. Does it do something cool that Open Camera doesn't?
Re: GrapheneOS – Break Free from Google and Apple
#859Earlier quoted context omitted.
I'm not convinced that all of these is required for security. My Qubes OS desktop is probably more secure than any GrapheneOS phone, and it only requires good hardware virtualization for that. > If the hardware is an open book then no. So you choose security through obscurity. I have no further questions.
x86 virtualization isn't perfect at all QubesOS certainly has some good things going for it with isolation but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot. With regards to security through obscurity, the Pixel firmware isn't o…
You cannot just say this without any links. Last escape from VT-d virtualization, which Qubes uses, was found in 2006 by the Qubes founder ("Blue Pill").
> Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
You can run Qubes OS on something even better: Coreboot with Heads and with a hardware key. All based on FLOSS. Works for me.
> but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
First of all, you can in principle run any OS in Qubes VMs, including hardened ones. You can even disable the root account. Second, with such statement, you misinterpret the Qubes' approach to security. You isolate trusted workflows from untrusted ones, which gives you the strong security. You never open anything untrusted in trusted VMs, so their internal security plays no big role.
Re: GrapheneOS – Break Free from Google and Apple
#860Earlier quoted context omitted.
Security goes way beyond a technical checklist. I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user. You can't fix the lack of trust you have on Android with just sandboxing.
I do trust the Linux distro maintainers that they don't have nefarious purposes. But they can't and won't verify third party projects' code, nor the huge number of contributors that come and go on any of these projects, or their transitive dependencies. As has been shown, it's almost trivial to get malicious code merged into open source projects, so not really sure where your "trust" comes from. It's not trust, it's…
And to answer your question, of course they can't check everything, that's why it's a model based on trust and not a model based on verify.
What would happen if let's say VLC would upload your user documents in the background? They would get nuked out of the repository and never be seen again. That's why apps do not tend to do that.
I'm not against sandboxing and a strong technical model myself, it's just that if I have to pick between a trust model and technical features, well the trust model wins hands down 10 times out of 10 as it has a better proven track record.