@weare_unplugged @fndr76 Unplugged's hardware, firmware and software is highly insecure relative to an iPhone or Pixel and doesn't meet our basic security requirements:



Unplugged are making incredibly false claims about how what they provide compares to GrapheneOS on a Pixel.grapheneos.org/faq#future-dev… @weare_unplugged @fndr76 An iPhone is legitimately a far better option for privacy and security than an Unplugged device. Unplugged has been repeatedly attacking GrapheneOS unprovoked with false claims about it along with false claims about iPhones and Pixels. That's their approach to marketing.

Android 15 QPR2 is moving 6th/7th/8th generation Pixels to the Linux kernel's 6.1 LTS branch already used for 9th generation Pixels. This will reduce the kernel branches we need to support down to 6.1 and 6.6. There will likely need to be a yearly migration for all the devices. Linux kernel increased official support time for the Long Term Support (LTS) branches from 2 years to 6 years, mainly for Android devices using Generic Kernel Image (GKI) releases. However, it was recently reduced back to 2 years. Pixels will need to start migrating every year.

IMEI is not the only hardware identifier for the device available to the cellular network. Changing the IMEi alone isn't enough to hide the device identity from the network. It will only hide one commonly used ID rather than making the device not uniquely identifiable. Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities.

@LysolPionex @Authy Sandboxed Google Play compatibility layer does not require using a work profile, user profile or Private Space for the apps to be sandboxed. They're sandboxed if you use them in your main Owner profile too. Putting it in a separate profile just keeps it a bit more separate. @LysolPionex @Authy SafetyNet Attestation API was deprecated a while ago and is nearly entirely phased out. It was replaced by the Play Integrity API. Both of these things work fine with sandboxed Google Play. The issue is they largely exist to support services banning any non-Google-ceritifed OS.

There's a highly inaccurate article about Pixels from Cybernews making the rounds everywhere in privacy communities. It gets the details nearly completely wrong and thoroughly misrepresents things like the optional network-based location used nearly everywhere as Pixel specific. Any non-Pixel device with the standard Google Play integration has similar Google service integration doing the same things. You don't avoid it at all by using a non-Pixel, but you do end up with a device that's far less secure and adds OEM services with their own privacy issues.

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:
June PUB: source.android.com/docs/security/…
source.android.com/docs/security/… 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.

This is a fake story. 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.

https://x.com/cryps1s/status/1824077327577591827

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.

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.

wired.com/story/google-a… 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.

Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.

404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.



Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.

@Parallel_Comms @utdream CalyxOS rolls back security a fair bit and doesn't provide comparable privacy or security features to GrapheneOS. It is not a hardened OS but rather somewhat anti-hardened. Their focus is marketing and bundling party apps and services, often with problematic privileged access. @Parallel_Comms @utdream CalyxOS lags a bit behind on updates and misleads users about the security patches and privacy/security they offer. All their release notes have inaccurate claims about it, and they copied setting an inaccurate security patch level from LineageOS among other problems from there.

Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as highly private and secure. Bottom of the barrel MediaTek device with outdated AOSP is worse than status quo. All marketing, no substance. As part of marketing their products, Unplugged are spreading unsubstantiated spin and misinformation about GrapheneOS and the much more secure hardware we target. We've been aware of it for a while but chose not to respond to it until they began doing it in direct response to us.

@davidbombal This video has major inaccuracies. CalyxOS always uses multiple Google services and gives them extensive privileged access within the OS. CalyxOS has far more limited app compatibility than GrapheneOS, and their approach to compatibility comes a high security and privacy cost. @davidbombal GrapheneOS provides far broader app compatibility via our sandboxed Google Play compatibility layer. It also has a much easier installation process. It's completely backwards to say that GrapheneOS is harder to adopt. What's the basis for making those statements about GrapheneOS?

XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB. Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.

April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:




These are assigned CVE-2024-29745 and CVE-2024-29748.source.android.com/docs/security/…
source.android.com/docs/security/… CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.

We've added documentation for the hardware memory tagging implementation in hardened_malloc:



GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.github.com/GrapheneOS/har… GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.

Earlier this month, unknown attackers targeted our website servers by spamming requests in an attempt to overload the servers and prevent users from accessing out website. We provided detailed information on what was happening and how we responded to it.

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

We made it clear we don't know the specific group behind that specific DDoS attack. In response to , we explained it's not a sophisticated attack and very likely originates from groups who openly engage in other forms of underhanded attacks on GrapheneOS.

https://twitter.com/kitfunfel/status/1623632234971545600

Our website was targeted with a Distributed Denial of Service attack using HTTP/2 multiplexing within the 2 minute window from 2023-02-09T00:58:00Z to 2023-02-09T01:00:00Z. OVH detected it and enabled mitigation but enough went through to cause downtime due to memory limits. In September, a similar attack caused nginx's master process to be killed by the out-of-memory killer causing much longer downtime. Default systemd service lacked auto-restart since master process supervises workers. We fixed that:

github.com/GrapheneOS/inf…
github.com/GrapheneOS/inf…

Uptime monitoring dashboard for the production GrapheneOS services is available at nodeping.com/reports/status…. Alerts are also posted publicly in our #infra:grapheneos.org Matrix room when a check is added, starts failing or stops failing. It's often not really an outage. For example, today, the TLS checks for attestation.app detected the certificate would expire in less than 15 days. This ended up being because the removal of a legacy subdomain several weeks ago broke automatic certbot removal. It can do much more advanced checks though.

Google publishes the source code for their TalkBack screen reader. GrapheneOS maintains a fork of it and includes it in GrapheneOS with the help of a blind GrapheneOS user who works on their own more elaborate fork. Eventually, we'd like to include more or all of their changes. TalkBack depends on a text-to-speech (TTS) implementation installed/configured/activated. It needs to have Direct Boot support to function before the first unlock of a profile. Google's TTS implementation supports this and can be used on GrapheneOS, but it's not open source.

We've purchased grapheneos.social and it we'll be hosting an official Mastodon instance for our project accounts there in the near future.

If you follow @grapheneos@infosec.exchange right now, you'll be automatically moved over to following the new account on our instance. fedifinder.glitch.me will scan the profiles of the people you follow on Twitter to find them on the fediverse (Mastodon). It helps you choose an instance and gives you a list of their handles to import into your new account so you can keep a lot of the people you follow there.

There are several dozen companies selling phones with GrapheneOS or forks of it. Many of these companies falsely claim to be partnered with us or working with us which isn't true. Most of these companies don't contribute back to GrapheneOS and try to get free support from us. It's easy to install GrapheneOS with grapheneos.org/install/web and we don't expect to have a revenue stream from selling phones not specifically made to run GrapheneOS. Still, it's quite problematic for companies to claim they are supporting us when they aren't actually doing it.