To anyone using a Pixel: install and donate (if you can)!
The web installer[1] is basically a few clicks on a web page. So damned impressed.
Basically, where other privacy AOSP forks typically offer up to three choices...
- no Google at all
- root and install an extremely fragile FOSS alternative GPS implementation (MicroG)
- root and install the full Google Play Services binary blobs
... GrapheneOS offers option #4: you can install Google Play Services in a sandbox so that they still run, but they don't get root-level access to your system, instead they are treated the same as any other app (so e.g. you get to manage their access to location/storage/contacts etc.).
Note that you don't have to, it's just an option in the built-in Apps menu. I personally run GrapheneOS with no GPS at all in my main profile, and occasionally access my old Gmail/Gdrive accounts via web browser.
I never realized how many permissions the play store had, until I ran it under graphene.
[1] https://grapheneos.org/build#reproducible-builds
Secure -> It's code. There are no absolute guarantees. They have security enhancements on top of AOSP. So that's a rough proxy for what you should expect.
I saw @jchw stating some good point but seems most in this thread here got their head in the sand.
too much trust in a product/service that may be secure on the surface, never means it's actually secure;
I ended up installing lineageOS rooted and firewalling everything and uninstalling useless services...that's better than having a system that is being advertised as state of the art security.
How dl you think google feels if their main OS market is being taken by a "secure" alternative like Graphene OS, unless they both struck a deal or are working together behind closed doors?
I got a suspicion that there's something the lead Dev of Graphene Os is unrevealing to us...hence they put him on desk job like a rookie cop who came across some sh*t that the public shouldn't know...
Meanwhile noone can fully confirm what's inside the OEM signed blobs that are on Graphene OS and other components. What more the heavy suggestion for never rooting; when over 200k apps on the playstore are riddled with malware/spyware?
Why would a billion dollar coorp let such clumsy mistake happen? I am starting to trust the fdroid store over Googleplay (despite being unable to have access to other apps) due to the fact:
Fdroid it's community baded/ the ppl make the app out of purely enjoyment versus montary need.
I have pxl4xl and ended up uninstalling Graphene OS something feels off about it.
No company CEO/Lead Dev just have a public dispute digitally and never explain why and the very next moment they are claimed to have had a mental breakdown.
and the fact that people are asking sincere questions and are being ridiculed for it, even raises more red-flags...
Think about it;
it's 2023, people gotta start thinking for themselves, nothing seems as it awlays is based on surface exposure.
I started only using software/tools by individuals or teams where the morale or principles is non-political and is in alignment with what makes sense no matter where you apply it.
Reading your comment in the dead comment from the other guy, I can't actually tell what the grievance is. One of the lead devs stepped away from social media? Whoopty doo.
From what others have explained, graphene OS is fully open, has a number of provable security improvements over AOSP, and has notable improvements in controlling how apps access your device.
Some healthy skepticism in security software is fine. But I don't think there's anything to what you or the other person are saying. And if a minor personnel issue is enough to make you question an entire project, maybe you should buy a dumb phone with a Faraday cage, and run slackware on a Thinkpad.
I remember Louis Rossmann posting a video[1] that felt pretty damning regarding project leadership, especially given that he seemed to be implicated in the mess for almost no reason at all. In general I wouldn't give a good god damn about drama, but I'll admit it: it's ALREADY hard to trust operating systems, and especially security software, that's effectively made by effectively random strangers on the Internet, but much worse so if it's unclear they wouldn't be willing to abuse their position.
Daniel Micay (aka strcat on here I believe) apparently announced they were stepping down from leadership roles in the project shortly after, according to tweets that appear to now be deleted, but that Wikipedia has links to an archive of.[2] At least from the code side of things though, they are still working quite actively.[3] Which is not a bad thing, but it doesn't tell us much about what happened.
What I'd hope to hear is that Daniel Micay is in better mental health, but they made the almost-certainly wise choice to stop engaging with social media, and I can't find much information about what actually went down, so I guess it's a question mark.
This is unfortunate because as I understand it, the closest competitor to GrapheneOS, CalyxOS, is not nearly as sophisticated. I'd really prefer to just be able to trust GrapheneOS, but I'm left absolutely unsure about what even happened. Did I miss something?
[1]: https://www.youtube.com/watch?v=4To-F6W1NT0
[2]: https://web.archive.org/web/20230530063836/https://nitter.fd...
I mean, it sounds like you have pretty much all the relevant information already?
strcat's technical chops were AFAIK never in question, but he had a tendency to pick up loud internet fights - to be fair, sometimes the other party were also being hostile jerks, but sometimes they weren't and he'd just swing at shadows.
After he pissed off Rossmann, he either realized or someone close to him made him realize (doesn't really matter which) that he should step away from the public square, and he did. Now he's just an ordinary, and I presume highly valued, contributor to GrapheneOS and to upstream AOSP.
Whether he still lurks the GrapheneOS discussion threads or not, or whether he is currently undergoing therapy or just chilling with a good book isn't really anyone else's business.
What else do you need to know?
So if it happened, who replaced them? Are they trustworthy? At least in my cursory searching, I didn't figure out an answer to that.
I assume the answer is actually out there, but I don't have it.
> Whether he still lurks the GrapheneOS discussion threads or not, or whether he is currently undergoing therapy or just chilling with a good book isn't really anyone else's business.
Sure, whatever. But failing any information about whether or not anything happened, I assume they still have root access to critical infrastructure. If so... I mean, naturally, the problem of trust hasn't changed much. If that's the case, then you still need to trust them to trust GrapheneOS. Can you? Don't know.
https://github.com/thestinger/daniel.micay.dev/commit/79e44b...
They just stepped down as the official head and stopped making public comments. They still are a major developer for the project and still seem to own/run parts of the project.
On one hand, the track record for the actual OS is still completely fine as far as anyone knows. On the other hand, the stuff said and done on record is pretty tough to swallow for someone you are investing a lot of trust into, for an OS that is meant to be privacy and security focused.
Like. It's one thing if you are a casual user running random ROMs off XDA, the risk is high and the only real assurance you get is online reputation and the normal assurances of social pressure. But this is software endorsed by Edward Snowden and many others whose opinions regarding security and privacy are well-regarded. The stakes could be quite high for some users. In the light of that, I really don't like the situation here at all.
Dismiss it if you want to, but there's really absolutely no good reason for this to simply remain effectively unaddressed indefinitely.
> Stock Pixel OS has it as a developer option which isn't usable in practice since it breaks far too much. The implementation is also much less powerful than hardened_malloc.
> We integrated it into hardened_malloc where it's able to provide stronger security properties than the experimental stock OS implementation.
> When fully integrated into the compiler and each heap allocator, MTE enforces a form of memory safety. It detects memory corruption as it happens. 4 bit tags limit it to probabilistic detection for the general case, but deterministic guarantees are possible via reserving tags. In hardened_malloc, we deterministically prevent sequential overflows by excluding adjacent tags.
Also, currently it's not clear if it makes sense to enable kernel MTE:
> MTE support for protecting the Linux kernel isn't enabled yet, but we can likely enable that by default too. However, it's currently part of kasan and is more oriented towards debugging than hardening. It's not entirely clear that enabling it in the current state is a good idea.