How would one compromise graphene os?

Matth

The fact that it is open source is certainly re-assuring and prevents that anything in the code itself can be sneaked into without being noticed, or so the theory goes.

However, how is that code executed on the phone? Is it run as it is downloaded from the source, or does it have to be compiled first? Could the compiler "add" certain parts on its own without the user even noticing? And at which point does that happen? Is it a single machine (that creates the download package) or is it at the user level?

nodsocket

Matth I believe GrapheneOS has reproducible builds, so everyone would have to have the same infected compiler in order for the malware to evade detection. But perhaps the firmware or hardware from Google could contain malicious code?

Blastoidea

nodsocket
The average criminal in the US is not all that bright.

They do, after all, get caught, and they are up against folks who are smarter, more numerous, and who have better technology.

matchboxbananasynergy

Fair disclaimer here, because I've seen it time and time again.

Let's please make sure that this thread doesn't turn into the classic "GrapheneOS vs your imagination" scenario.

Nothing is bulletproof. What GrapheneOS does is significantly raise the bar across the board.

zzz

Quick side question -

Eirikr70

we are about 100,000 users

Does anyone have a link to a source on this? I'd love to learn more about any openly published stats.

matchboxbananasynergy

[deleted] This is not correct. The 'Restricted setting' restriction will not apply (to the app being installed) If the installer app uses a install session with the PACKAGE_SOURCE_STORE parameter to install It.

Hey, thanks for the correction! Would you happen to have a source where I can read more about this? I believe (not sure if this is still true), that installing an app through F-Droid will result in an app requesting the invasive permissions to have the "restricted setting" pop-up. Same with sideloading.

zzz we are about 100,000 users

Does anyone have a link to a source on this? I'd love to learn more about any openly published stats.

The latest estimate is actually around 175k users:

https://twitter.com/GrapheneOS/status/1687517530183598080

There are likely at least 175k GrapheneOS users. It hasn't been 25k for several years.

https://twitter.com/GrapheneOS/status/1687517530183598080

I say estimate, of course, because GrapheneOS doesn't ship with telemetry or analytics which makes gauging that kind of thing very difficult.

Here's an older thread going over the crude methodology for estimating GrapheneOS users in the past, where the estimate was about 150k users at the time:

Based on the number of update downloads, we estimate there are currently around 150k GrapheneOS devices.

Since we're still temporarily publishing GrapheneOS signed Auditor releases (app.attestation.auditor) on the Play Store, the Auditor install statistics give some useful info.

Based on app repository update counts, there are around 40k people using sandboxed Google Play on GrapheneOS.

Play Store only counts 22k active installs of Auditor but we think it only counts logged in users. Many people use sandboxed Google Play without logging into an account.

These are very rough estimates because we don't have any analytics / telemetry. We can count the number of update checks and downloads via our web server logs. There are a ton of daily factory images downloads but we don't know if they're new users or people upgrading hardware.

Since our update client resumes interrupted downloads, we're counting the total number of fresh downloads (200 response code) while ignoring resumes (206 response code) for a specific release. Frequent releases end up cutting this counting short but we know the rate it drops off.

https://twitter.com/GrapheneOS/status/1587912474002542592

[deleted]

matchboxbananasynergy when you sideload or install an app from a store that doesn't use a modern session installer

This is not correct. The 'Restricted setting' restriction will not apply (to the app being installed) If the installer app uses a install session with the PACKAGE_SOURCE_STORE parameter to install It.

[deleted]

matchboxbananasynergy Would you happen to have a source where I can read more about this?

Here: https://www.esper.io/blog/android-13-sideloading-restriction-harder-malware-abuse-accessibility-apis (Also note that at the time this article was written, NotificationListener Permission was not restricted like the Accessibility service permission by the 'Restricted setting' feature)

matchboxbananasynergy I believe (not sure if this is still true), that installing an app through F-Droid will result in an app requesting the invasive permissions to have the "restricted setting" pop-up. Same with sideloading.

This is true because F-Droid does not use the session installer

[deleted]

matchboxbananasynergy

matchboxbananasynergy Since we're still temporarily publishing GrapheneOS signed Auditor releases (app.attestation.auditor) on the Play Store, the Auditor install statistics give some useful info.

I was under the impression the id is app.attestation.auditor.play.

Play Store only counts 22k active installs of Auditor but we think it only counts logged in users. Many people use sandboxed Google Play without logging into an account.

For some reason this threw me off. What's the value of counting Auditor installs to estimate active GrapheneOS users and how it relates to whether or not these users are logged into Play?

matchboxbananasynergy

[deleted] Note I'm quoting an old tweet thread there. Currently, the only Auditor on Play store is indeed the Play variant (app.attestation.auditor.play). Before that, we used to have app.attestation.auditor on Play Store (signed by us), but have since removed that variant to make it so all GrapheneOS apps on the Play Store are signed by Google via Play App Signing, which is mandatory to use for new app submissions.

The number of auditor installs estimates how many people use Sandboxed Google Play (as per the tweet thread, at the time, _40k). GrapheneOS users were estimated based on download statistics instead.

[deleted]

matchboxbananasynergy The number of auditor installs estimates how many people use Sandboxed Google Play

The assumption being that everyone who downloads Auditor from Play Store has Play services enabled on their device? I would have thought GrapheneOS app repository update counts of Sandboxed Google Play is the best estimate of that.

matchboxbananasynergy

[deleted] The assumption being that everyone who downloads Auditor from Play Store has Play services enabled on their device? I would have thought GrapheneOS app repository update counts of Sandboxed Google Play is the best estimate of that.

Play Store/Services can also be updated by Play Store itself (no login required), so it's not a great metric to use. In fact, using Play Store for updating itself and play services is the recommended way to go.

[deleted]

matchboxbananasynergy Play Store/Services can also be updated by Play Store itself (no login required), so it's not a great metric to use.

Yeah, makes sense. It's admirable how little you know about your users.

csoo0550

Eirikr70 because graphene is open source it's harder to compromise.

But a group of users trying to mitigate much more aggressively against attack vectors presents as a possibly more valuable target for attack vectors and Pixels have some closed source firmware.

They would likely try to compromise something closed source.

Graphene mitigates against attack vectors. It can't stop them because it doesn't control all the code on the devices and even graphene could have a 0 day or undiscovered exploit. The intelligent graphene developers mitigate against many attacks and it would be very hard for a non-state actor to hack a Graphene phone configured well.

« Previous Page