This is a fake story: https://x.com/cryps1s/status/1824077327577591827
Turns out that getting security information from the CISO of a mass surveillance company trying to build a dystopian police state providing police with "predictive policing" software largely based on racial stereotypes is a bad move.
Trail of Bits iVerify EDR product runs in the standard app sandbox on iOS and Android. It can hardly do anything beyond static scanning of APKs. It's a crippled antivirus app marketed as detecting sophisticated attackers. It's a scam and Trail of Bits has lost all credibility. Trail of Bits is working closely with Palantir and is focused on getting government contracts. They've created a fake news story to promote their EDR product which has been propagated across mainstream media. Journalists didn't do basic due diligence and spread false marketing.
Verizon has a suite of low-level apps for Android devices to fully use their network. These are included on any Android device with full Verizon support. Pixels disable the packages unless a Verizon SIM is active. This is equivalent to having them installed/uninstalled on demand. One of the apps in this suite is the Showcase retail demo app for Verizon to show off phones in their store. It requires manually up the phone as a retail demo device. Verizon says they don't use it anymore. This demo app is where Trail of Bits / iVerify found an HTTP connection.
In order to exploit Verizon's demo app not verifying a signature for the downloaded config or even fetching it via HTTPS, it would already need to be set up to use retail demo mode. The contractors Verizon paid to implement it did a bad job, but it's not a Pixel security issue. Since it's an obsolete app that Verizon isn't using anymore, the stock Pixel OS already removed it in Android 15 which is visible in the Android 15 Beta. The other Verizon apps needed to fully use their network which get activated with a Verizon SIM are of course still included.
#GrapheneOS has been omitting these carrier apps since around 2015. This meant GrapheneOS users weren't able to use Sprint and can't use certain features on Verizon like Wi-Fi calling. Apple has a special deal with Verizon and implements what the control they want as part of iOS. The restrictions set in Verizon's carrier configuration and the functionality implemented by these apps is a major part of why they prevent installing an alternate OS on any device sold by Verizon. They want to control how people use features like tethering and Wi-Fi calling.
Every month, a bunch of real vulnerabilities are patched for Android on Pixels. A subset of these including all High and Critical severity issues in Android itself get backported to older Android releases for non-Pixels too. iVerify's finding isn't even a Low severity issue. Supposedly reputable news organizations including the Washington Post, New York Times, Wired, etc. are largely acting as press release distribution service for governments and corporations. If it fits a narrative they want to tell, there's no attempt to question or confirm it.
Trail of Bits employees should think over whether they want to be part of building a police state with pervasive surveillance as Palantir partners. You're not even working at a reputable security company anymore. Trail of Bits has become the charlatans they used to criticize.
#security #privacy
final [GrapheneOS] π±ποΈβπ¨οΈ
npub1c9d9...sqfm
Keeping the fight.
Community Moderator for #GrapheneOS
https://discuss.grapheneos.org/u/final
This is a personal account. I do not speak on behalf of GrapheneOS developers as a whole (nor am I) and suggestions shall not be endorsements.
Wired was manipulated into spreading misinformation to market Palantir and iVerify by misrepresenting a vulnerability in a disabled demo app as being a serious problem which could be exploited in the real world. They should retract the article but won't.
iVerify are scammers and anyone paying them money should rapidly stop doing it and remove their malware from their devices. The real security risk is giving remote code execution on your devices to one of these sketchy EDR companies lying about their capabilities and discoveries.
This is one of multiple carrier apps in the stock Pixel OS which we don't include in #GrapheneOS. We were aware of it already since we had to go through them and figure out why they exist. We could embrace this fearmongering and leverage it for marketing, but we aren't dishonest.
"iVerify vice president of research [...] points out that while Showcase represents a concerning exposure for Pixel devices, it is turned off by default. This means that an attacker would first need to turn the application on in a target's device before being able to exploit it."
"The most straightforward way to do this would involve having physical access to a victim's phone as well as their system password or another exploitable vulnerability that would allow them to make changes to settings. Google's Fernandez emphasized this limiting factor as well."
Wired should retract the article and explain how they're going to do better. They keep publishing this kind of fearmongering misinformation from information security industry charlatans. There are real remote code execution flaws being fixed in Android and iOS but they push this.
WIRED
Nearly All Google Pixel Phones Exposed by Unpatched Flaw in Hidden Android App
A fix is coming, but data analytics giant Palantir says itβs ditching Android devices altogether because Googleβs response to the vulnerability...
Organic Maps (a very nice offline-capable open source maps and navigation app) is now available on Accrescent by the way. I personally use this app myself so I recommend to give it a try.
If you download it and you previously installed it on Obtainium or an APK then it will appear as a separate app, this is due to Organic Maps using a different application ID for the app released on GitHub. GitHub downloads use 'app.organicmaps.web' instead of 'app.organicmaps'.
The Organic Maps team discusses this here:
As for Accrescent, the maintainers still want to work on developing Accrescent features to allow scaling first rather than adding apps in bulk, but they are allowing apps to come. You are free to read the app requirements and documentation and ask to be added to an allowlist.
GitHub
[android] Unify application id and signature between GitHub, Firebase AppTester and Telegram release-candidates Β· Issue #8516 Β· organicmaps/organicmaps
Currently, we have the following distribution channels for Android: Google Play Open/Closed Beta - app.organicmaps Google Play Production - app.org...
#GrapheneOS version 2024080500 released.
This is an early August security update release based on the August 2024 security patch backports. This month's release of the Android Open Source Project and stock Pixel OS should be available later today or tomorrow and we'll quickly release an update based on it following this one.
β’ full 2024-08-01 security patch level
β’ suppress crash notifications for 2 harmless crashes occuring on service shutdown for the Android Bluetooth service and Pixel wifi_ext service
β’ enable memory tagging for the Pixel wifi_ext service again
β’ Settings: disable predictive back gesture in PIN/password input activities to fix an upstream Android vulnerability
β’ flash-all: remove unnecessary sleep after flashing AVB key
β’ flash-all: exit on errors
β’ flash-all.sh: avoid false negative for device model check
β’ flash-all.bat: pause before exiting after an error
β’ fastboot: add support for CLI install with the GrapheneOS optimized factory images format already used by the web installer (will reduce memory/storage usage for CLI installs and will reduce storage usage on the update servers by avoiding multiple factory image formats)
β’ hardened_malloc: update libdivide to 5.1
β’ kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.43
Releases | GrapheneOS
#GrapheneOS version 2024080200 released.
This update is an improvement of the last update's attempt at fixing potential VPN DNS leaks in certain apps as the last ones broke certain apps like Proton VPN.
-prevent VPN apps from having leaks to non-VPN DNS servers while not yet strictly preventing leaks to VPN DNS outside the VPN tunnel due to multiple VPN apps including Proton VPN not connecting reliably with stricter enforcement (in a future release, we can do strict blocking by default with an opt-out toggle and a list of known incompatible apps such as Proton VPN until the compatibility issue is resolved)
- GmsCompatConfig: update to version 126
- GmsCompatConfig: update to version 127
- Camera: update to version 73
Releases | GrapheneOS
We've become aware of another company selling devices with #GrapheneOS while spreading harmful misinformation about it to promote insecure products. We're making our usual attempt at resolving things privately. However, we need to quickly address what has been claimed regardless.
Downloading and installing an app followed by entering sensitive data into it or granting it powerful permissions isn't a vulnerability/exploit. Accessibility service access can't be directly requested but rather has to be granted via Settings app in the accessibility section.
Accessibility service access is extremely powerful and essentially gives the same control available to the user to the app. This is explained with clear warnings. It's also not possible to enable it for an app not installed from a modern app store without an extra hidden menu.
Apps not installed through a modern app store have extremely dangerous settings including accessibility service access restricted. Users have to navigate to a semi-hidden menu to enable this. UI doesn't explain how to do it. It's a higher barrier than simply phishing info, etc.
Accessibility services are required by many users and the feature can't simply be removed. It's possible to disable this and other dangerous features for end users via a device management app. This is the right approach if you have a userbase you want to protect from themselves.
If you purchase a device with GrapheneOS, we strongly recommend booting it into recovery and wiping data before using it. Next, verify it's running genuine GrapheneOS:
Due to complete verified boot, wiping provides the same assurance as a fresh install.
Our web installer is very easy to use. If you're able to use a web browser and follow basic instructions, you have the skill set required to install it:
However, if you do buy a device with GrapheneOS, you can verify it's the real deal without malware.
Simply going to a mainstream local business and purchasing a device to install GrapheneOS is the most secure way to obtain a device.
Consider the risk of buying a device from a company marketing to cryptocurrency users, and at least follow our wiping and verification advice.
Purchasing a device with malware installed is something we defend against. We provide a way to block this through verified boot and the verification process recommended on the site. But you can't prevent something like replacing battery with one including a standalone tracking device...
Web installer | Install | GrapheneOS
Web installer | Install | GrapheneOS
#GrapheneOS version 2024073100 released:
β’ add back our change to prevent app-based VPN implementations from leaking DNS requests when the VPN is down/connecting but without enforcement for VPN apps without DNS configured to avoid breaking compatibility in rare cases (our previous implementation had to be reverted before it reached Stable)
β’ kernel (6.6): update to latest GKI LTS branch revision
β’ Camera: update to version 72
β’ Vanadium: update to version 127.0.6533.84.0
#privacy #security
Releases | GrapheneOS
We're including a less strict variation of our previous VPN DNS leak prevention for third party VPN apps in the next #GrapheneOS release. The new approach only aims to prevent leaks in apps handling DNS configuration correctly. It should avoid causing the compatibility issues which blocked us shipping it before.
We shipped an even stricter approach in our 2024050900 release but compatibility issues were reporting during Beta testing so it didn't reach the Stable channel. It was reverted in 2024051500. Proton VPN may now be compatible with it but not all apps will be so we can't be that strict.
The hardest part of shipping privacy and security improvements is often fully preserving compatibility with the massive number of Android apps. We try to avoid needing toggles to work around compatibility issues, but we make an exception for apps with memory corruption bugs.
arstechnica.com/gadgets/2024/07/loss-of-popular-2fa-tool-puts-security-minded-grapheneos-in-a-paradox/
The article unfortunately leaves out most of the points we made in the thread.
#GrapheneOS supports hardware-based attestation and it's entirely possible for Google to allow it as part of the Play Integrity API. They choose to ban using GrapheneOS.
Play Integrity API has no minimum security patch level and nearly all these apps use weak software-based checks that are easily bypassed by attackers. The hardware-based checks rely on trusting every key distributed to every certified Android device, which are often leaked.
Hardware-based attestation can be used for security purposes such as verifying device integrity with a pinning-based approach without the weakness of being vulnerable to leaked keys from the whole Android ecosystem since specific per-app keys in the secure element can be pinned.
Play Integrity API is claimed to be based on devices complying with the Compatibility Test Suite and Compatibility Definition Document. We have irrefutable proof that the majority of certified Android devices do not comply with the CTS/CDD. Play Integrity API is based on lies.
Essentially every non-Pixel device has important CTS failures not caused by CTS bugs. OEMs are cheating to obtain certification. Google claims GrapheneOS can't be permitted because we don't have a certification where they freely allow cheating and don't ban non-compliant devices.
Since Play Integrity doesn't even have a minimum security patch level, it permits a device with multiple years of missing patches. Hardware attestation was required on all devices launched with Android 8 or later, but they don't enforce it to permit non-compliant devices.
The reality is that the Play Integrity API permits devices from companies partnered with Google with privileged Google Play integration when they're running the stock OS. It's easy to bypass, but they'll make changes to block it being done at scale long term such as if we did it.
It does not matter if these devices have years of missing security patches. It doesn't matter if the companies skipped or improperly implemented mandatory security features despite that being required by CDD compliance. Failing even very important CTS tests doesn't matter either.
Google can either permit GrapheneOS in the Play Integrity API in the near future via the approach documented at or we'll be taking legal action against them and their partners. We've started the process of talking to regulators and they're interested.
We're not going to give Google veto power over what we're allowed to do in GrapheneOS. We comply with CTS and CDD except when it limits our ability to provide our users with privacy and security. Google wants to be in charge of which privacy/security features can be added. Nope.
Google's behavior in the mobile space is highly anti-competitive. Google should be forbidden from including Google Mobile Services with privileged access unavailable to regular apps and services. GrapheneOS sandboxed Google Play proves that hardly anything even needs to change.
Google should also be forbidden from participating in blocking using alternate hardware/firmware/software. They've abused their market position to reinforce their monopolies. They've used security as an excuse despite what they're doing having no relevance to it and REDUCING it.
Google is forbidding people from using a growing number of apps and services on an objectively far more private and secure OS that's holding up much better against multiple commercial exploit developers:
They're holding back security, not protecting it.
We've put a lot of effort into collaborating with Google to improve privacy and security for all Android users. Their business team has repeatedly vetoed even considering giving us partner access. They rolled back us being granted security partner access by the security team.
As with how they handle giving out partner access, the Play Integrity API serves the interests of Google's business model. They have no valid excuse for not allowing GrapheneOS to pass device and strong integrity. If app developers want to ban it, they can still do it themselves.
After our security partner access was revoked, we stopped most of our work on improving Android security. We continued reporting vulnerabilities upstream. However, we're going to stop reporting most vulnerabilities until GrapheneOS is no longer blocked by the Play Integrity API.
This year, we reported multiple serious vulnerabilities to Android used by widely used commercial exploit tools:
If Google wants more of that in the future, they can use hardware attestation to permit GrapheneOS for their device/strong integrity checks.
Authy's response about their usage of the Play Integrity API shows their service is highly insecure and depends on having client side validation. Play Integrity is thoroughly insecure and easily bypassed, so it's unfortunate that according to Authy their security depends on it.
If Authy insists on using it, they should use the standard Android hardware attestation API to permit using GrapheneOS too. It's easy to do:
Banning 250k+ people with the most secure smartphones from using your app is anti-security, not pro-security.
Attestation compatibility guide | Articles | GrapheneOS

GrapheneOS Mastodon
GrapheneOS (@GrapheneOS@grapheneos.social)
Attached: 3 images
Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.
404media recently published an article based on the sa...
Android Open Source Project
Android security acknowledgements | Android Open Source Project
Attestation compatibility guide | Articles | GrapheneOS
#GrpaheneOS Camera version 72 released:
- use default CameraX camera selection to avoid compatibility issues with some multi-camera setups
- avoid video recording not working after audio permission change
- use CameraX to determine the video timer instead of a separate timer which can get slightly out of sync
- animate the start of video recording
- dynamically show/hide EIS settings based on current configuration

GitHub
Release 72 Β· GrapheneOS/Camera
Notable changes in version 72:
use default CameraX camera selection to avoid compatibility issues with some multi-camera setups
avoid video record...
#GrapheneOS version 2024072800 released 2 days ago.
β’ avoid isolating eUICC LPA (eSIM activation) app from third party apps to allow carrier activation apps to work (we still block communication with Google Play to avoid sending telemetry data to Google services when sandboxed Google Play is installed)
β’ Pixel 8a: fix GNSS configuration to avoid occasional crashes of the service (Pixel 8a is currently the only Samsung GNSS device)
β’ Settings: don't allow disabling user installed apps when uninstall is disallowed
β’ Settings: drop code for supporting the legacy Settings UI
β’ Sandboxed Google Play compatibility layer: avoid infinite wait for GmsCompatConfig update when call to App Store fails
β’ enforce stack clash protection for x86_64
β’ enforce minimum 64kiB stack guard size for arm64 due to the standard stack probe size of 64kiB
β’ future proof our Bionic libc changes for dynamic 64k pages (hardened_malloc still doesn't support it)
β’ flash-all: remove unnecessary reboot after flashing Android Verified Boot (AVB) key
β’ kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.222
β’ kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.163
β’ kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.92
β’ kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.42
β’ adevtool: update to latest carrier settings
β’ App Store: update to version 24
β’ Camera: update to version 69
β’ Camera: update to version 70
β’ Camera: update to version 71
β’ Auditor: update to version 81
β’ Auditor: update to version 82
β’ Vanadium: update to version 127.0.6533.64.0
β’ Vanadium: update to version 127.0.6533.64.1
β’ GmsCompatConfig: update to version 124
β’ GmsCompatConfig: update to version 125
β’ fastboot: add support for generating web installer optimized factory images zip for an improved web install approach not requiring fastbootd
β’ integrate generating web installation optimized factory images zip into release signing script
β’ split script/release.sh to remove dependency on build output and the OS source tree (see the new instructions for signing releases)
β’ rename script/release.sh to script/generate-release.sh
β’ add script/generate-releases.sh wrapper script
Releases | GrapheneOS
We've developed a new factory images format optimized for web installation which avoids the need for fastbootd mode and greatly reduces memory/storage usage. The new approach is compatible with 5th gen Pixels and later. It's deployed on our staging site:
We'd appreciate help with testing the new web installer on our staging site. It should reduce issues caused by low quality USB connections/drivers by avoiding switching to a different mode. It should also eliminate the need to install a fastboot driver on up-to-date Windows 11.
We'll wait for feedback from people using it successfully across different operating systems and devices.
Sections for working around Debian, Ubuntu and Windows USB deficiencies should be unnecessary other than the legacy extended support devices so we'll likely remove those.
#GrapheneOS
Install | GrapheneOS
Vanadium version 127.0.6533.64.1 released:
- enable per-site isolation for sandboxed iframes instead of per-origin isolation
- avoid rare uncaught exception from attempting to load content filters from the Vanadium Config app when native code isn't loaded yet
#GrapheneOS
GitHub
Releases Β· GrapheneOS/Vanadium
Privacy and security enhanced releases of Chromium for GrapheneOS. Vanadium provides the WebView and standard user-facing browser on GrapheneOS. It...
Chromium has merged the WebAssembly interpreter submitted by a Microsoft Edge engineer:
https://chromium-review.googlesource.com/c/v8/v8/+/5509903
Once this reaches a Chromium stable release, Vanadium will support WebAssembly by default instead of requiring turning on JS JIT via drop-down site settings. Example of a site using it is Mutiny Wallet.
Chromium has a V8 Optimizer toggle for disabling the 2 optimized tiers of the Just-In-Time (JIT) compiler to greatly reduce attack surface. However, it doesn't disable baseline JIT and therefore still does dynamic native code generation. They did this to avoid breaking Wasm.
In Vanadium, our JIT toggle fully disables the JIT and therefore currently loses Wasm support. An increasing number of sites are depending on Wasm with no fallback to JavaScript. Most of these sites perform perfectly fine with only the fast V8 interpreter and no JIT compilation.
Vanadium has JIT compilation disabled by default as part of the security focus. This Wasm interpreter will be a nice usability improvement for sites depending on it with no fallback code since users won't need to toggle on the JIT compiler for the site unless it performs badly.
Unplugged have doubled down on false claims about GrapheneOS security, pretending people cannot buy devices with GrapheneOS installed and pretending it's hard to install along with promoting their blatantly insecure products with false marketing.
We have an existing thread going through many of their false claims and debunking them:
We also responded to their lies about GrapheneOS directly. They've read our posts and have chosen to continue peddling the same misinformation about GrapheneOS.
They keep pushing the false claim that Pixels supporting using another OS makes them less secure. The reality is that it's properly implemented in a secure way without adding any significant attack surface. The bottom of the barrel MediaTek Unplugged devices have awful security.
They still haven't ported to the initial release of Android 14 with Android 15 right around the corner. This means they're missing at least around a year of Moderate severity privacy/security patches and huge privacy/security improvements from the past year of Android releases.
Unplugged is using an SoC from MediaTek, a company known to have poor security practices, which fares poorly against real attackers and which has a history of repeatedly shipping actual backdoors. They're trying to portray that as more trustworthy and more secure hardware. Nope.
Unplugged was founded by Erik Prince, noted war criminal and illegal arms dealer. They make a point in talking about the involvement of their employees in enabling these kinds of operations:
That doesn't imply competence, but explains the lack of ethics.
They're trying to present themselves as if they were leaders in the field and switched sides, but they never were and simply want money.
Unplugged is an affinity scam in the same vein as the Freedom Phone. Unplugged has built their product out of open source projects, but without complying with the licenses from projects like DivestOS and while trying to harm open source. Claiming to be in the process of replacing some of the code they were caught stealing doesn't change much...
X (formerly Twitter)
The Andres Segovia (@_AndresSegovia) on X
Long before Unplugged delivered their first phone, they were under scrutiny because of it's founders. And while people can hear from co-founder Eri...

X (formerly Twitter)
GrapheneOS (@GrapheneOS) on X
Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as high...

X (formerly Twitter)
GrapheneOS (@GrapheneOS) on X
Here's an example of a "counterterrorism operation" by a U.S.-allied Western government targeting political opponents with NSO exploits:
https://t...
Accrescent app store documentation and website have been updated to reflect the collaboration with #GrapheneOS.
If using Accrescent before this, the recommended method to verify Accrescent is to install it from the GrapheneOS App Store. This approach chains the signing verification of Accrescent to GrapheneOS itself, which can then be chained to a hardware-backed root of trust through the GrapheneOS verified boot and Auditor app.
You can learn more about the Accrescent security modeling here: 

Accrescent
Accrescent
Notable features of Accrescent distinguishing it from other stores.
For Signal users: Outside of just the security benefits for using Molly we discuss a lot about, you should also use it if you don't use Google Play Services, as the non-FCM push notifications in the original Signal app drains a lot of battery.
Molly FOSS has a much more efficient implementation of non-FCM push notifications and doesn't drain battery.
You can find Molly FOSS on the Accrescent app store (available in GrapheneOS Apps app) or from the project site.


Molly
Molly is an improved Signal app for Android