GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Website: https://grapheneos.org/
Forum: https://discuss.grapheneos.org/
X: https://x.com/GrapheneOS
GitHub: https://github.com/GrapheneOS

Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

NIP-05 Address

grapheneos_at_grapheneos.social@momostr.pink

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsea55mw

Publishing to

relay.momostr.pink

relay.damus.io

nos.lol

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2024-10-12 10:59:27

- reply

We're going to be temporarily reverting our change in today's release before Facebook's broken code reaches more apps. We tried lying to apps about the stack layout to hide this change but that breaks compatibility much more. We'll have to detect the Facebook library instead.

2024-10-10 09:32:51

- reply

They directly worked with a YouTuber who was the main one directly orchestrating and engaging in harassment towards one of our developers which led to the swatting attacks from a CalyxOS supporter who follows that YouTuber. This spiraled into lots of additional harassment and attacks. Our community has never engaged in anything remotely comparable and yet they've dishonestly branded our community as toxic based on their community raiding our chat rooms, etc.

2024-10-09 09:00:06

- reply

Yes, but we aren't sure on the best way to do it. We're in active communication with the EU Commission and with a couple companies interested in helping with either pressure the EU Commission or take legal action with a lawsuit. It would be too hard to do it on our own but we have help and need more.

2024-10-09 08:01:07

- reply

There is no viable technical solution to apps trying to disallow using GrapheneOS or any other non-Google-certified-OS. The solution has to be forbidding this at a regulatory level or at least legal victories against the companies enabling and promoting it (Google). The best solution is regulation. Google should not be allowed to block using an alternate OS or encourage others to do it because that's highly anti-competitive and reinforces their monopolies.

2024-10-09 07:54:46

- reply

If someone MUST have Google Pay and wants to use GrapheneOS, there's the option to use a Pixel Watch or Galaxy Watch for it instead of a whole secondary phone. Pixel Watch technically supports using another OS but we have little interest in supporting it and it would lose Google Pay due to the same anti-competitive Play Integrity API pretend security feature. They allow using a device with no patches for 10 years, so clearly it's not actually about real security.

2024-09-20 16:53:16

- reply

From glancing over the thread, it sounds like it could have been one of their contacts using a shady Contacts app uploading and selling all the contacts data so the solution is really having multiple segregated, more disposable numbers.
You can get cheap VoIP numbers not tied to your identity from the open source https://jmp.chat/ service. Can pay with cryptocurrency to avoid it being tied to you through a credit card. They support Monero too.

2024-09-19 22:47:27

- reply

AICore might stop using hardware attestation when they open it up to more devices... or it might always use it and lock people into the stock OS on specifically approved devices. That's doing more than most apps using Play Integrity and leaked keys would be needed to bypass it. Ridiculous, but that's how it is.
Google Play's LiteRT (TensorFlow Lite) is portable and works fine via TPU accel on Pixels.

2024-09-19 22:46:13

- reply

Play Integrity API is a ridiculously anti-competitive API attacking alternate operating systems while providing zero actual security value. It needs to be stopped by regulators. It permits a device with no patches for 8 years but not GrapheneOS which is a much more secure OS using even more hardware-based security features. They COULD allow GrapheneOS via Android's hardware attestation, which we support and use ourselves for security via the pinning support, not control.

2024-09-19 22:42:10

- reply

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://privsec.dev/posts/android/choosing-your-android-based-operating-system/ is an article with more long form comparisons between OSes.

2024-09-19 22:42:01

- reply

Compatibility with Android apps is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
https://grapheneos.org/usage#sandboxed-google-play
Can run vast majority of Play Store apps on GrapheneOS, but not with the far more limited and less secure microG approach.
Fully privileged Google Play can of course allow using anything not using the Play Integrity API, but sandboxed Google Play essentially does that too without giving absolutely any special access to Google Play.

2024-09-19 22:41:13

- reply

Some standard information:
GrapheneOS and those operating systems are very different. GrapheneOS is a hardened OS with substantial privacy/security improvements:
https://grapheneos.org/features
Those are the opposite of hardened. They greatly reduce security vs. AOSP via added attack surface, rolled back security and slow patches.

2024-09-19 22:40:39

- reply

Can use the per-app exploit protection compatibility mode if an app is incompatible with our memory corruption exploit protections.
Apps using the Play Integrity API are growing in number but you'll have that issue with any alternate OS or the stock OS with the device unlocked. Trying to spoof it is a losing battle if you want things to actually consistently work instead of sometimes being able to trick it at the expense of massive harm to the OS security model and stability.

2024-09-19 22:39:07

- reply

You can use everything other than Digital Wellbeing on GrapheneOS because that requires a significant amount of privileged access. It's possible it could be coerced into working via messing around with ADB but unlikely.
Here are some options someone was recently considering as alternatives:
https://grapheneos.social/@npub1lcn…wcpw/113165766462339517
Every app should work on GrapheneOS if it's not a very special Google app designed to be built into the OS and isn't disallowing using an alternate OS via Play Integrity.

2024-09-19 16:12:05

- reply

Main app compatibility issue is with the DuckDuckGo app's "App Tracking Prevention" feature based on a VPN service. If you use that feature and upgraded to our cancelled 2024091700 release, that's the issue you're having. Likely an app bug, but we'll make sure it works next time.

2024-09-19 16:08:20

- reply

We'll be making a release today reverting our multicast leak prevention for all devices and will begin work fixing the minor app compatibility issues to ship it again.
5th gen will be switched to legacy extended support a few weeks early to work around the old Linux kernel bugs.

2024-09-19 16:02:38

- reply

Separately from this, our multicast leak prevention is causing minor app compatibility issues due to apps trying to use multicast when a VPN is enabled with leak blocking and then not catching the SecurityException which the low-level EPERM error is being converted into for them.

2024-09-19 15:52:37

- reply

We likely should have only provided legacy extended support releases via a legacy branch as soon as devices were end-of-life. Extended support encourages people to stick with insecure end-of-life devices and lead to regressions like this but we caught previous ones before Stable.

2024-09-19 15:52:24

- reply

Our extended support releases have only ever been planned for the legacy Pixel 5a and earlier with less than 5 years of support from launch. We provide extended support until the first yearly release not supporting them and then switch to a legacy extended support branch.

2024-09-19 15:47:10

- reply

We're hardly getting any testing feedback for the end-of-life devices which led to this issue slipping into the Stable channel. Our extended support for 5th gen devices will become legacy extended support after Android 15 meaning they won't get these kinds of changes anymore.

2024-09-18 22:48:35

- reply

The app usage stats are largely built into the OS itself but you need an app to view them and it needs to be granted the app usage stats special access permission. It would be possible for a local device manager to control when apps can be used but it likely doesn't exist since Digital Wellbeing exists so there wouldn't have been a reason for other developers to make something similar. Digital Wellbeing itself requires privileged OS integration and is not designed to run without it.

2024-09-18 15:02:52

GrapheneOS version 2024091700 released:
https://grapheneos.org/releases#2024091700
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/15819-grapheneos-version-2024091700-released
#GrapheneOS #privacy #security

2024-09-18 10:56:05

- reply

Enabling airplane mode disables all the radios but it only force disables cellular. You can re-enable the non-cellular radios in airplane mode.

2024-09-17 20:51:02

- reply

It might not drain a significant amount of power in practice, we don't know. We're just warning that it could theoretically drain significant power trying to reconnect, although it's probably fairly throttled and won't really make a significant impact.

2024-09-17 20:46:43

Vanadium version 129.0.6668.54.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/129.0.6668.54.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15803-vanadium-version-12906668540-released
#GrapheneOS #privacy #security #browser

2024-09-17 19:55:36

- reply

You can remove the radios from a Pixel if you want. It will still boot and work fine, although there will be errors and it might drain some battery life while awake trying to connect to those components without the OS explicitly supporting them being missing.

2024-09-17 18:23:56

- reply

Accidentally disabling airplane mode is not a real world issue if you remove the quick tile. Providing a toggle to prevent disabling airplane mode via an emergency call is already planned as a minor feature to improve protection against forensic data extraction similarly to how automatically disabling USB-C at a hardware level while locked is implemented by GrapheneOS and enabled by default. It's far lower value since it can't be default and is conditional.

2024-09-17 18:16:01

- reply

Your claims about this are highly inaccurate and not based on any real world threat model. You want to have something for unclear reasons and are trying to come up with contrived reasons you need it. You're working backwards from wanting something to coming up with reasons you should want it instead of having reasons to want it and then requesting it. Cellular is implemented via an isolated radio and other than SIM support is similar to Wi-Fi radios.

2024-09-17 18:13:46

- reply

An attacker with root access can use GNSS or Wi-Fi to detect location. GNSS exists for that purpose and Wi-Fi is heavily used for that by Apple and Google via their network location services. You're talking about an attacker who has ALREADY compromised the OS and gained kernel/root level access. You're trying to come up with contrived reasons for the existing functionality not being enough but none of what you're claiming checks out.

2024-09-17 18:03:37

- reply

You can remove the airplane mode quick tile if you don't want it to be possible to accidentally toggle it through the quick settings tray. If someone remotely exploits your device to get the level of control needed to disable it, they already have access to your device anyway. Wi-Fi can be used too.

2024-09-16 20:24:09

- reply

Cellular is integrated in a similar way as Wi-Fi and Bluetooth via an IOMMU isolated radio which can be reliably turned off. Samsung makes both the main SoC and the cellular radio. Not clear what you're trying to avoid. If you don't want to use cellular, use airplane mode.

2024-09-16 01:52:55

- reply

Pixel and Galaxy are the other devices truly striving to have a high level of security. However, Samsung doesn't meet all our security requirements at the moment. Samsung also cripples their devices when using an alternate OS including crippling security which is a complete dealbreaker. We aren't aware of any other OEM taking security seriously and Samsung has their efforts diluted across too many SoC platforms, devices, etc. along with adding far too much complexity.

2024-09-14 10:42:42

- reply

The purpose is making life harder for malware by adding a major UI barrier to getting dangerous permissions for apps not installed from a modern app store based on the concept that an app store using the modern package manager APIs is probably not filled with lots of malware. There is malware on mainstream app stores but in practice they're capable of preventing it from scaling up to huge numbers of users so lots of malware only exists as apps people manually install.

2024-09-14 10:40:49

- reply

There are no restrictions for any modern app store, and the restrictions can simply be toggled off via a menu hidden in plain sight. It's simply a 3 dot menu at the top right for accessing the advanced restricted settings toggle in the app settings. The messages showing you can't grant dangerous permissions doesn't explain it can be toggled off to avoid pointing users to that. A malicious app could tell users to do it, but they have to guide them through it and can't simply link to it.

2024-09-12 22:01:27

- reply

In what sense? It's a tiny app that's part of the standard Android UI.

2024-09-12 21:59:22

- reply

There's nothing for us to do. The restricted settings feature is perfectly fine with us. It restricts dangerous settings for apps installed manually or from poorly maintained app stores not using the modern package installation system. It does not restrict settings for apps installed via modern app stores. Users can toggle off restricted settings for apps installed manually or from poorly maintained app stores. What's the issue?

2024-09-12 19:43:30

- reply

Their devices don't meet our requirements and therefore can't be be supported.
https://grapheneos.org/faq#future-devices
There's currently nothing to do on our end. They're very far from meeting our security standards.

2024-09-12 17:51:33

- reply

On which device model? It sounds like the app is either not properly handling a configuration change or is getting killed from memory pressure and hasn't saved anything persistently to make it persist through a device reboot or the app getting killed. The app shouldn't be getting killed so easily unless you're using multiple profiles, particularly on an older device with a much smaller amount of memory.

2024-09-12 17:46:41

- reply

Connecting to the cellular network for emergency services does not require a SIM.
You should really replace both of these devices with ones still receiving firmware security updates though.
Android Open Source Project and GrapheneOS are Linux distributions too. It's not systemd, glibc and GNOME which makes it Linux.

2024-09-10 20:49:27

- reply

It's available in our port to Android 15 including support for sandboxed Google Play, Storage Scopes and Contact Scopes. It's a nice replacement for local usage of work profiles which was always a questionable way of doing things leveraging a feature for something it was never meant to do.

2024-09-10 12:54:25

- reply

AICore is definitely used for Summarize in Recorder and Gboard Smart Reply. It's almost certainly what Chrome is using on Android for the local AI features but we haven't confirmed that for sure and it's not really worth the effort to us.

2024-09-10 12:42:20

- reply

For some reason, they currently only allow using AICore based on checking the device/OS with hardware attestation so it's not currently possible to use it via their apps on GrapheneOS. They may have done this as part of keeping it exclusive to certain devices but that's not really clear. It might be intended to stop people essentially jailbreaking the AI model to use it for other purposes without their restrictions. Perhaps they'll relax the restrictions eventually.

2024-09-10 12:40:41

- reply

It's likely based on AICore which isn't only available for the Pixel 8 and Pixel 9. See here:
https://developer.android.com/ai/aicore
> Gemini Nano and AICore are available on Google Pixel 9 series devices, Pixel 8 Pro, Pixel 8, Pixel 8a, and Samsung S24 series devices, with support for more products coming soon.
It's going to be on a lot more devices soon. AICore depends on having a lot of free memory combined with good local NN hardware acceleration. It wasn't initially available for non-Pro P8.

2024-09-09 22:31:49

- reply

GrapheneOS is not a hobby OS project and we uphold all of the standard privacy/security properties along with substantially improving them. There's no legitimate reason for the Play Integrity API not permitting GrapheneOS to pass both basic and strong integrity. Google should be forced to allow it to pass and a neutral party should be responsible for defining the security standards and certifying an OS/device as meeting those standards. Google is abusing it.

2024-09-09 22:29:39

- reply

There are far more apps using the Play Integrity API than apps checking for mock location being active. Nearly all the apps checking for mock location such as location-based games already check the Play Integrity API or are in the process of implementing it. It makes little sense for them to check for mock location if they aren't using the Play Integrity API or the hardware attestation API since if the OS is modified it can simply show mock location as not being active.

2024-09-09 22:28:01

- reply

Hardware attestation is a very useful security feature. It's root-based attestation which is being abused. Having hardware attestation doesn't imply having a single root for verifying that a specific company approved a device. It can be implemented with only pinning support which is the main functionality we use in Auditor ourselves. Roots are useful for the initial verification but the security is very low for root-based verification due to leaked keys.

2024-09-08 06:05:05

Auditor app version 85 released:
https://github.com/GrapheneOS/Auditor/releases/tag/85
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15578-auditor-app-version-85-released
See https://attestation.app/about and https://attestation.app/tutorial for info about the app and optional monitoring service.
#GrapheneOS #privacy #security #android #attestation #VerifiedBoot #MeasuredBoot #HSM #SecureElement #auditor

2024-09-08 01:47:47

- reply

Please bear in mind that apps are forbidding using alternate operating systems via the Play Integrity API and the end result of hiding that mock location is active would be the OS being forbidden instead of being able to convince them to allow it via hardware attestation. We fully intend to provide per-app location spoofing built into the OS instead of needing the mock location feature but hiding it from apps is pointless if they use the Play Integrity API for this.

2024-09-08 01:46:13

- reply

There's already a mock location feature and we plan to provide a better per-app feature similar to our Contact Scopes and Location Scopes. Ingress and Pokemon Go use the Play Integrity API to enforce having a Google certified OS so they don't allow using GrapheneOS and that's unlikely to change. If we add a feature which doesn't appear via the mock location check, they'll simply not allow using GrapheneOS. If we don't hide it from the existing API, they may whitelist it.

2024-09-07 19:14:54

- reply

That's not really what's expected since Vanadium only uses EasyList + EasyPrivacy and conditionally also EasyList Germany when the German language is enabled. Brave uses EasyList + EasyPrivacy combined with uBlock Origin's supplemental list for those and a partially enabled list of privacy invasive domains are blocked too. uBlock Origin list has exceptions it makes to unbreak sites so reduces blocking somewhat but it increases it more than it reduces.

2024-09-07 07:51:15

GrapheneOS App Store version 25 released:
https://github.com/GrapheneOS/AppStore/releases/tag/25
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15559-grapheneos-app-store-version-25-released
#GrapheneOS #privacy #security #android #repository

2024-09-07 04:53:29

- reply

Probably a one time hardware glitch in that case.

2024-09-07 04:29:33

- reply

That's an error caused by a hardware issue, not something an update caused. Try fully turning off the device. If it still doesn't work next boot, it's due to hardware damage.

2024-09-06 20:00:52

- reply

Our thread is about many of the most popular ad blockers cheating on a (flawed) test. It's not a recommendation to avoid using those ad blockers. We're simply informing people a test which recently got widespread coverage after being linked by Troy Hunt and others with lot of reach does not give accurate results due to ad blockers cheating to get ~100% instead of the ~70% they should actually get due to trying to avoid blocking anything which would break sites.

2024-09-06 07:19:31

GrapheneOS Info app version 4 released:
https://github.com/GrapheneOS/Info/releases/tag/4
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15530-grapheneos-info-app-version-4-released
#GrapheneOS #privacy #security

2024-09-06 06:06:54

- reply

Yes, that's why Vanadium will always use a hard-wired filter list which gets extended based on the configured languages and can only be turned off rather than making specific changes to which filters are used or custom exceptions. We also don't actually see it as a particularly valuable privacy feature due to how easy it is to avoid content filtering for analytics, etc. by tying it together with functionality and even making it first party content despite being from a third party.

2024-09-06 02:29:02

- reply

Author is willing to fix issues but since ad blockers are cheating it'd need to be moved to another domain after fixing it.
Vanadium will not include rules for cheating at content filtering tests because we think it would be a breach of user trust, regardless of flaws in a test.

2024-09-06 02:28:05

Ad blocking test at https://d3ward.github.io/toolz/adblock is extremely flawed. It tests domains which are not used for ads/tracking and doesn't take into account that mainstream ad blocking is blocking specific paths hosted at those domains. Mainstream ad blockers also cheat at these tests.

2024-09-05 19:54:45

- reply

We requested backporting it after it shipped in June and that happened for September 2024.
It took ~3 months to ship the initial 2 fixes, ~2 more months to ship the new wipe-without-reboot feature in Android 14 QPR3 and then ~3 more months after we asked if it could be backported for that to happen. The only thing we don't really understand is why they shipped a firmware mitigation for the wipe interrupt issue in April 2024 instead of just shipping wipe-without-reboot.

2024-09-05 19:52:44

- reply

The wipe-without-reboot feature we proposed ended up having a device-independent implementation as part of AOSP they shipped in June 2024. We shipped it earlier, and we extended their implementation with 2 extra redundant forms of wiping material needed to derive the encryption keys.
June patch ended up being entirely in AOSP so other devices can ship it instead of making their own. They didn't consider it could be backported in ASB. We requested it and they did it.

2024-09-05 19:49:40

- reply

We reported the issues as a set of Pixel vulnerabilities being exploited in the wild. The 2 main weaknesses enabling the exploits apply to other devices too, and both us and the Google people understood that but we'd have had to report it to each Android OEM separately and we have a bad experience trying to get non-Pixel OEMs to do anything so we didn't bother. Other Android devices have not yet shipped the reset attack mitigation feature they added in April 2024.

2024-09-05 19:47:38

- reply

With few exceptions, non-Pixel devices do not ship monthly and quarterly updates. They stick with the initial yearly release and apply backported security patches from AOSP and the hardware vendors. The June 2024 patch was included in Android 14 QPR3 which is available for non-Pixels to ship but they don't do it. It was backported to older releases in the September 2024 Android Security Bulletin. Android Security Bulletin are backports of patches, not the main patches.

2024-09-05 19:46:22

- reply

Every month, there's a new monthly, quarterly or yearly release of Android. These are the updates shipped by Pixels. This means each year, there's 1 yearly update, 3 quarterly updates and 8 smaller monthly updates. Since Android 14 QPR2, quarterly updates are trunk-based and have as many changes as yearly updates under the hood. Yearly updates enable a bunch of feature flags resulting in much more user-facing change and new features, but quarterly updates are as large.

2024-09-05 19:44:28

- reply

In April 2024, they also shipped a partial mitigation for the issue of an attacker being able to interrupt wiping the device.
In June 2024, as part of Android 14 QPR3 (3rd quarterly releases of Android 14), they shipped our proposed wipe-without-reboot feature. They called this a Pixel firmware update in the Pixel Update Bulletin even though it was an AOSP patch because the initial partial mitigation was a Pixel firmware patch and the full fix got misclassified there.

2024-09-05 19:42:53

- reply

These are issues impacting all Android devices, not only Pixels. However, the firmware changes to defend against them are Pixel specific and not within the scope of the Android Security Bulletin. Google can't make other OEMs fix firmware flaws outside the scope of ASB.
In April 2024, they shipped the reset attack mitigation feature we proposed as a Pixel firmware update, but they limited the scope of it to fastboot mode, which fully addresses what we reported to them.

2024-09-05 19:40:04

- reply

We reported vulnerabilities being exploited by forensics companies in January 2024, but we lacked access to their exploits so we couldn't provide full details. We suggested implementing 2 major security improvements:
1) firmware-based reset attack mitigation zeroing memory on boot
2) wipe-without-reboot support in the OS to avoid needing to reboot to recovery to perform a wipe, which could be trivially interrupted by an attacker
They ended up shipping both of these.

2024-09-05 19:35:45

- reply

Not initially but it's possible later on. It's already possible to do this with user profiles but not within the same UI.

2024-09-05 04:47:26

- reply

Fairphone 5 is an insecure device without basic security patches and security features we require. Our hardware requirements are listed here:
https://grapheneos.org/faq#future-devices
We can't successfully defend users from real world attacks with hardware, firmware and drivers bringing too much insecurity. We need the hardware vendor to be prioritizing security and striving to do much better. Only Pixels are doing this outside of the Apple world.

2024-09-05 01:48:41

Vanadium version 128.0.6613.127.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/128.0.6613.127.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15494-vanadium-version-128066131270-released
#GrapheneOS #privacy #security #browser

2024-09-04 01:53:57

Our initial port of device-independent GrapheneOS code to Android 15 is done and we're testing it in the emulator. We still need to port the kernels, device-specific repositories, adevtool and generate the new vendor state. Can already be built for emulator from our 15 branch.

2024-09-03 23:22:59

- reply

Yes, and we've already been testing it via the Android 15 flags available in Android 14 QPR3. We already ported our changes to support those things previously. We have our Android 15 port largely done now.

2024-09-03 20:28:18

- reply

It's likely they'll take a bit longer than usual to push the tags for the monthly release of Android 14 QPR3 because it's queued up after the push of the Android 15 stable tags. We'll of course be prioritizing the monthly release but it's not actually published to AOSP yet.

2024-09-03 20:28:12

- reply

Today's early source code release of Android 15 should be enough for us to make special experimental releases for Android 15.
Trunk-based releases combined with early source code tags are a massive benefit to us. It should be dramatically easier for us than past major releases.

2024-09-03 20:08:57

- reply

Android Security Bulletins include the High and Critical severity patches for the Android Open Source Project backported to older releases (12, 12.1, 13, 14) and a small selection of firmware/driver patches for specific hardware. Non-Pixels ship these backports. Pixels ship more.

2024-09-03 20:07:26

- reply

Each month, there's a new Android monthly, quarterly or yearly release. This month is a monthly release of Android 14 QPR3, the 3rd quarterly release of Android 14 from June 2024. Android Security Bulletins have a subset of overall privacy/security patches. This is one example.

2024-09-03 19:58:52

- reply

We extended wipe-without-reboot with extra wiping and use it as part of our duress PIN/password feature.
Forensic companies are still able to exploit stock OS Pixels, but reset attack mitigation helps prevent bypassing GrapheneOS security via firmware.
https://grapheneos.social/@GrapheneOS/112826160880324005

2024-09-03 19:51:53

- reply

We pointed out that it was actually an AOSP patch which should be shipped for all devices, and they agreed with us and scheduled it for inclusion in September. Wipe bypass is now finally going to be fixed for non-Pixels. Reset attack mitigation will still be missing elsewhere.

2024-09-03 19:51:49

- reply

In June 2024, Pixels shipped our wipe-without-reboot proposal to fully eliminate wipe bypasses. The full solution is a set of AOSP patches (https://android.googlesource.com/platform/frameworks/base/+/8b7b2c66ca96d711fb364cbcc9d655197d9743e0) but they still classified it as a firmware patch since it was treated as phase 2 of the Pixel firmware patches.

2024-09-03 19:51:43

- reply

We reported several vulnerabilities exploited by forensic companies in January 2024. We proposed implementing firmware reset attack mitigation and wipe-without-reboot. Pixels shipped reset attack mitigation in April 2024 and also a firmware mitigation making wipe bypasses harder.

2024-09-03 19:43:13

September 2024 Android Security Bulletin includes a patch for the wipe bypass we reported: CVE-2024-32896. It's actively exploited by forensic companies across devices. Pixels patched it in June 2024...
September ASB: https://source.android.com/docs/security/bulletin/2024-09-01
June PUB: https://source.android.com/docs/security/bulletin/pixel/2024-06-01

2024-09-03 06:32:32

GrapheneOS support for the Pixel 9 Pro Fold is no longer marked experimental and is now available through our production site:
https://grapheneos.org/releases https://grapheneos.org/install/web
Our 2024083100 release has been confirmed to be working and to have a working future upgrade path.

2024-09-03 05:37:31

GmsCompatConfig (sandboxed Google Play compatibility layer configuration) version 135 released:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-135
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15450-gmscompatconfig-version-135-released
#GrapheneOS #privacy #security #gmscompat

2024-09-02 20:10:23

- reply

It doesn't currently show up in a non-stock launcher due to the app isolation since it can't be seen by non-OS components. We plan to add a special exception for an active launcher app.

2024-09-01 07:23:57

- reply

Yes, it should say that, and you can use it to verify you have genuine GrapheneOS by comparing the verified boot key fingerprint (sha256 hash of public key). It enforces that the key matches what was flashed to the secure element so it's not really something you need to check more than once.

2024-09-01 07:12:26

- reply

There shouldn't be anything saying the OS is corrupt during boot. It should say that it's loading an alternate OS and should show the correct verified boot key. Should be nothing showing it as corrupt. If you're getting a red notice showing corruption, you need to reinstall. Installing stock OS via their web installer and then GrapheneOS should resolve it.
If you're just getting the normal boot notice with the verified boot key and a yellow icon, that's expected.

2024-08-31 18:28:04

- reply

No, you just need to complete the installation process. You tried to boot before you finished installing. Hold volume down while rebooting to boot into fastboot mode and complete the process. Don't use the start option in the menu until you've fully installed the OS and locked.

2024-08-31 16:24:27

- reply

Sandboxed Google Play Store with a throwaway account (can be created in a browser too) works well and many Play Store apps depend on Google Play including Play Store services anyway.

2024-08-31 13:13:25

- reply

It's an alternate frontend to the Play Store. It still requires an account but fetches a shared one by default. It doesn't verify the signatures proving apps were published on the Play Store so it relies completely on trusting every WebPKI certificate authority without certificate transparency enforcement like browsers. It's not very secure and has major reliability issues partly due to the account sharing, which is against the terms of use and regularly gets blocked.

2024-08-30 13:44:48

- reply

Not really clear enough what you're referring to. If you're referring to a specific app using the WebView to run code, that's probably an issue with their app.

2024-08-30 13:41:44

- reply

There's a toggle for enabling the JIT. Why use a problematic browser that's adding substantial attack surface and not providing proper updates instead of enabling JIT compilation if you want it?

2024-08-29 23:42:48

- reply

You can leave Wi-Fi calling off if it regularly causes issues with your carrier but it shouldn't cause any extra problems due to GrapheneOS. The only extra compatibility issues with GrapheneOS are with certain US carriers for activating Wi-Fi calling in the first place because we omit carrier apps such as the Verizon app suite. Not really an issue elsewhere in the world and it still works fine with carriers like T-Mobile and AT&T in the US, mostly just Verizon with issues.

2024-08-29 21:50:46

Auditor app version 84 released:
https://github.com/GrapheneOS/Auditor/releases/tag/84
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15343-auditor-app-version-84-released
See https://attestation.app/about and https://attestation.app/tutorial for info about the app and optional monitoring service.
#GrapheneOS #privacy #security #android #attestation #VerifiedBoot #MeasuredBoot #HSM #SecureElement #auditor

2024-08-28 21:04:04

- reply

Yes. Pixel 8 Pro, Pixel 9 Pro and Pixel 9 Pro XL have it. Pixel 9 Pro Fold appears to have omitted it despite being the highest end device.

2024-08-28 19:38:19

GmsCompatConfig (sandboxed Google Play compatibility layer configuration) version 133 released:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-133
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15308-gmscompatconfig-version-133-released
#GrapheneOS #privacy #security #gmscompat

2024-08-28 08:26:41

- reply

Nothing other than the Google Play SDK. Can avoid that with Molly FOSS if you care, but it's simple Java code and can be quite easily analyzed anyway.

2024-08-28 07:28:55

- reply

Pixel Thermometer is also supported on the Pixel 8 Pro now too. 9th gen Pixel users are getting it early since we needed another early release to port them to our standard 6.1 GKI LTS branch. With the next official release, 9th gen Pixel should be on the regular release cycle.

2024-08-28 07:23:36

Our 5th release for Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL is available. Main improvement is replacing Linux 6.1.75 with latest GKI LTS (6.1.95). Remaining gap should go away soon. Pixel Thermometer is now supported for 9 Pro / 9 Pro XL and can be installed via our App Store.

2024-08-28 04:59:48

- reply

A similar thing happen in July where most news organizations messed up reporting on leaked April 2024 Cellebrite Premium documentation. We published the July 2024 documentation to get people's attention and give them a proper accurate explanation of it:
https://grapheneos.social/@GrapheneOS/112826067364945164

2024-08-28 04:42:51

- reply

GrapheneOS has never included Verizon carrier apps due to our security concerns, but this had no security impact and therefore not an example of one of the issues we avoided by not including them. We now have to deal with an ongoing support burden answering questions about this.

2024-08-28 04:40:59

- reply

News publications should do better than publishing inaccurate marketing material from security companies. Google clearly stating that it had no security impact should have been followed up by getting independent analysis. Should have reported the boring truth or dropped it.

2024-08-28 04:33:34

iVerify and Trail of Bits have cemented themselves as untrustworthy by not publishing retractions for their fake vulnerability media blitz. News sites failed to publish updates based on it being debunked by multiple security and Android internals experts.
https://grapheneos.social/@GrapheneOS/112967309987371034