final [GrapheneOS] 📱👁️‍🗨️

Mobile security

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.

Public Key

npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm

NIP-57 Address

[email protected]

Profile Code

nprofile1qqsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgy6zd4j

Publishing to

nos.lol

relay.damus.io

Author Public Key

npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm

Show more details

Last Notes

2024-07-02 20:54:35

Project Announcement:
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.
#GrapheneOS is a hardened OS built on the latest release of the Android Open Source Project rather than older releases with inferior privacy/security and incomplete privacy/security patches. We substantially improve privacy/security with our changes rather than making it worse.
The work we do in GrapheneOS is highly regarded by privacy and security researchers. We've made major upstream contributions to the Android Open Source Project, Linux kernel and other projects, both through submitting privacy/security improvements and reporting vulnerabilities.
We've also reported numerous vulnerabilities in hardware/firmware along with making multiple suggestions for new features which were implemented for Pixels. They're the only devices meeting our security requirements ( https://grapheneos.org/faq#future-devices ). We target them because of security.
Pixels have first class alternate OS support, which does not come at the expense of security. Support for installing an alternate OS is implemented securely as part of best in class boot chain and secure element security for Android devices. Supporting it has benefited security.
Unplugged has claimed open source and support for alternate operating systems reduces security. Pixel security has benefited from many external security researchers along with contributions from GrapheneOS because of it. They'll benefit more as they publish more firmware sources.
GrapheneOS not only leverages the same hardware-based security features as the OS but implements major hardware-based features unavailable elsewhere.
Hardware memory tagging for production hardening is an exclusive GrapheneOS feature with a best-in-class implementation.
Our USB-C port and pogo pins control feature does hardware-level attack surface reduction with code written for the drivers on each device:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
Our Auditor app leverages the pinning-based hardware attestation available on Pixels based on our proposal for it.
Many of our other features are hardware-based, and some of these exist because of features we proposals or helped to secure against weaknesses.
In April, Pixels shipped reset attack protection for firmware based on our proposal, which is not available on other Android devices.
That reset attack protection blocks real world attacks by forensic data extraction companies, which we reported to Android. In April, Pixels also shipped a mitigation against interrupted factory resets used by those companies based on our report, not yet available on non-Pixels.
In June, Android 14 QPR3 was released with a hardware-based OS feature fully blocking interrupting factory resets. This was based on our initial proposal we made as part of our reports of active exploits in January, similar to the reset attack protection shipped in April.
Unplugged uses an older Android release. They do not have this AOSP patch. Their hardware is missing many standard security features including these recent 2 improvements shipped on Pixels. Their hardware doesn't even close to meeting our list of security standards even on paper.
Unplugged has tried to misrepresent these improvements and falsely claimed they're uniquely relevant to Pixels due to alternate OS support. That's not true. Their device is missing these and many other security features, and is not more secure due to lacking alternate OS support.
Unplugged was founded by Erik Prince, the same person who founded Blackwater. Erik Prince, it's founder, and others involved in UP are deeply tied to human rights abuses and surveillance around the world. Best case scenario is they're simply grifting like the Freedom Phone. Worst case is much worse.
Unplugged are also infringing on the open source licensing multiple projects including DivestOS where they ripped off their AV from without attribution. They even still use DivestOS servers without permission. SkewedZeppelin is lead developer of DivestOS.
https://image.nostr.build/5f465e5c3f817dc88ce1c5749aef0515f0ff9d57e49b8a8fb07f1cda43a8ee96.jpg

2024-07-01 06:37:04

Vanadium version 126.0.6478.122.1 released:
Users will need to enable JavaScript JIT compilation for sites requiring WebAssembly again via the permission menu next to the URL due to us reverting the upstream security regression which resulted in this working by default. Unfortunately, Chromium still doesn't have a WebAssembly interpreter like Edge and got this working by rolling back the security of the API used to disable JIT compilation for their desktop V8 Optimizer toggle.
Support for language-specific content filters was added which is automatically enabled when the language is selected (EasyList Germany has been added to the configuration app for testing the implementation).
https://github.com/GrapheneOS/Vanadium/releases/tag/126.0.6478.122.1
#grapheneos

2024-06-28 12:22:48

GrapheneOS version 2024062700 released.
• add new GrapheneOS Info app through which you can get information about the latest releases of GrapheneOS, links to our community spaces, and details on how to make donations
• Pixel 8a: add Let's Encrypt roots to Samsung gnssd CA root store for supl.grapheneos.org
• Pixel 8a: configure Samsung gnssd to use TLSv1.2 for SUPL instead of TLSv1.1 (TLSv1.3 would work but the config doesn't offer it)
• Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold: fully remove 32-bit ARM support to significantly reduce build time and update download size with no loss of functionality (7th gen Pixels launched with 32-bit app support disabled after several years of the Play Store blocking uploading 32-bit-only apps or installing them on 64-bit devices, and 8th gen Pixels use 2nd gen ARMv9 cores with no 32-bit support)
• Settings: fix several cases of UI state being lost when resuming activity after configuration changes, etc. for GrapheneOS settings
• kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.216
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.90
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.35
• Vanadium: update to version 126.0.6478.122.0
• GmsCompatConfig: update to version 120
https://grapheneos.org/releases#2024062700

2024-06-24 01:57:59

#GrapheneOS Info app is now available through our app repository and will be included in the next release of the OS. It supports viewing recent OS release notes, provides info on our chat rooms, forum and active social media accounts along with offering all the donations methods.
https://grapheneos.social/system/media_attachments/files/112/667/706/471/647/917/original/fb7ab68053c67eb1.png
This will be included in the next release of GrapheneOS. We also plan to make significant improvements to the other GrapheneOS apps in the near future. We'll also be working towards replacing or overhauling each of the user-facing AOSP apps as we already did with the Camera app.
We recently completely replaced the Setup Wizard shown during the initial installation with a modern replacement following the standard setup design style. We'll be adding more functionality there and our app repository to help people get started including obtaining their apps.

2024-06-16 19:47:21

#GrapheneOS version 2024061400 was released.
- revert upstream refactoring of the device association code in Android 14 QPR3 due to it introducing a chain crash bug at boot in edge cases with associated devices such as paired Android Wear devices
- kernel (5.10): update to latest GKI LTS branch revision
- Vanadium: update to version 126.0.6478.71.0
https://grapheneos.org/releases#2024061400

2024-06-13 15:08:44

- reply

When other hardware can meet these requirements, we will support them:
https://grapheneos.org/faq#future-devices
It is disappointing only Pixels do this currently. Samsung is a close contender if they didn't intentionally sabotage users installing other OSes by disabling cameras, security features and more.

2024-06-13 15:03:38

#GrapheneOS receives fourth Android Security Acknowledgement of the year. This time we are credited for moving wipe-without-reboot to the stock OS.
CVE-2024-32896 which is marked as being actively exploited in the wild in the June 2024 Pixel Update Bulletin is the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:
#nevent1q…5s2v
None of this is actually Pixel specific.
Bulletin:
https://source.android.com/docs/security/overview/acknowledgements
Attribution to us:
https://source.android.com/docs/securi
CVE-2024-32896 and CVE-2024-29748 refer to the same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.
CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3. It's not at all Pixel specific.
This is being widely incorrectly reported in tech news coverage. Pixel Update Bulletins are almost entirely patches for vulnerabilities which apply to other devices too. Android Security Bulletins are the list of what other OEMs are required to fix, not the full list of patches.
We explained this in our previous thread:
https://grapheneos.social/@GrapheneOS/112204437363495338
CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader. Full solution is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP.
Our 2024052100 release backported the upstream wipe-without-reboot feature being shipped in the June 2024 release of Android (Android 14 QPR3): https://grapheneos.org/releases#2024052100.
We extended it to make it more robust via extra redundancy in our 2024060400 release:
https://grapheneos.org/releases#2024060400.
There were 2 main issues:
1) memory not wiped when booting firmware-based fastboot mode, allowing exploiting it to get previous OS memory
2) AOSP device admin API depends on reboot-to-recovery to wipe before Android 14 QPR3
Neither of these issue is being fixed outside Pixels yet.
Each month, Android has a new version released. These are the monthly, quarterly (QPR) and yearly releases. The baseline monthly security patches are NOT the monthly releases of Android. They're backports of a SUBSET of the patches with High/Critical severity, not all patches.
Most devices only ship the backported patches to older Android releases (12, 13 and 14). Pixels ship the monthly, quarterly and yearly releases. Other devices will mostly get the 2nd vulnerability fix when they update to Android 15. They'll have to fix the 1st issue on their own.
We have a thread about forensic company capabilities at:
#nevent1q…r988
based on leaked Cellebrite documentation. Shows GrapheneOS does a much better job than iOS/Android blocking exploits and only Pixel 6 and later or iPhone 12 and later successfully stop brute forcing.

2024-06-06 16:29:50

#GrapheneOS version 2024060600 released.
- Sandboxed Google Play compatibility layer: adjust to DynamiteLoader changes being deployed with a new feature flag in Play services 24.22
- stop treating pressing the spacebar on a physical keyboard as submitting the lockscreen password since it prevents entering passphrases with spaces (upstream Android bug which has existed for around 8.5 years)
- Vanadium: update to version 125.0.6422.165.0
- GmsCompatConfig: update to version 116
https://grapheneos.org/releases#2024060600

2024-06-04 23:41:11

#GrapheneOS version 2024060400 released.
This is an early June security update release based on the May 2024 security patch backports since this month's release of the Android Open Source Project and stock Pixel OS with Android 14 QPR3 isn't available yet. There are also improvements to wiping which is used by the duress password.
- full 2024-06-01 security patch level
- extend the standard wipe-without-reboot implementation beyond wiping the hardware keystores (which prevents recovering any OS data by preventing deriving the key encryption keys) by also wiping the secdiscardable data needed to derive key encryption keys, the encrypted storage keys and the Weaver slots in the secure element through a secure element erase
- kernel (5.10): update to latest GKI LTS branch revision
- kernel (5.15): update to latest GKI LTS branch revision
- kernel (6.1): update to latest GKI LTS branch revision
https://grapheneos.org/releases#2024060400

2024-06-02 23:01:33

- reply

After the wipe it will boot to recovery as it can't access any data and then reset OS. After that it boots into the GrapheneOS setup wizard.
To flash to another OS or stock OS, make sure to enable OEM unlocking on the fresh GrapheneOS install after the duress happens.

2024-06-02 22:58:04

- reply

BTW we never recommended those apps that used device admin APIs for resetting the device since you could deactivate them and interrupt the erasure. XRY had tutorial videos explaining how to bypass Duress and others by holding the buttons that would boot into Fastboot mode. Law Enforcement knew for long time. We also had criminal sellers using our work unlawfully and bundling those apps trying to lie, sell it and say whatever they sold was better than GrapheneOS at extortionate prices.
Duress feature took as long as it did because we needed a unique way to wipe the device without reboot, that couldn't be interrupted and was also as fast as possible. We had our own wipe-without-reboot then Google designed one for future Android after our reports so GrapheneOS backported that as part of the infrastructure for the Duress feature.
Hopefully those apps are redundant for GrapheneOS users now.

2024-06-02 22:39:32

Here is footage of the brand new #GrapheneOS duress password in action from a user, here on Nostr.
#nevent1q…ywsa

2024-06-02 22:36:53

- reply

Thank you for posting this footage here on Nostr!

2024-06-02 19:18:04

- reply

https://xcancel.com/tuxpizza/status/1797314703468753342

2024-06-02 19:13:48

- reply

Tuxsudo has done a video here!
https://xcancel.com/tuxpizza/status/1797314703468753342
Twitter: https://x.com/tuxpizza/status/1797314703468753342

2024-06-02 17:20:51

- reply

It is a newly released feature and updates aren't pushed to Stable where most of the users are immediately. We just put the docs for the feature and all the past changes we missed like USB controls on the website now.
Now it's in Stable there should be. I will try source some footage.

2024-06-02 17:00:53

- reply

I'll try source some for you, may take some time.

2024-06-02 16:59:29

Latest release of #GrapheneOS finally shipped the long awaited duress PIN/password implementation. If you have a spare device, we recommend trying it out.
We've added initial documentation to the features page:
https://grapheneos.org/features#duress
It near instantly wipes and shuts down.
We've also finally added documentation on our USB-C port control to our features page:
https://grapheneos.org/features#usb-c-port-control
Most users can set this to "Charging-only when locked" without a loss of functionality or even "Charging-only" if you don't use USB accessories, DisplayPort or MTP.
Default is "Charging-only when locked, except before first unlock" to avoid locking users out of devices with a broken touchscreen. The main threat model for this is defending the device until the auto-reboot timer started when the screen is locked gets user data back at rest.

2024-06-01 23:57:05

- reply

Users are free to trigger their Duress password on a spare device in many different ways for feedback. ☺️

2024-06-01 20:47:20

- reply

It isn't planned currently as a technical threat would be able to figure that out, or would be able to tell if it is a decoy through other means. It's a big reason we don't have a hidden profile feature at all (e.g. FFS would leave signs). The feature would only work best against someone with no knowledge on what GrapheneOS is. Cellebrite and XRY and other industry actors mentioning us in their internal documents or product material would suggest they study our work and read our posts.
Another example is Owner is still required to be authenticated first and there's tons of ways to see if an authenticated profile os the Owner or not.
We believe features involved in tricking someone could lead to someone trusting that feature and underestimating how skilled the person they're trying to trick, which could endanger them or bring even more trouble. While you could also trick someone with our Duress PIN that's not the objective, the device owner should trigger it when the time is right.

2024-06-01 15:28:13

- reply

FYI: GrapheneOS does remain installed after a trigger right now so you can go into a recovery.

2024-06-01 15:00:29

- reply

FYI: Obviously Pixel 8a doesn't have this or other new features due to being in prerelease, since it is currently based on Android 14 QPR2 and not QPR3. Once it is available then all currently supported devices are together.

2024-06-01 14:56:06

- reply

Obviously we can't speak on what potential bad guys (criminals or abusive states) would do. Laws are different elsewhere, but some would likely choose whatever would happen to them over what would happen if they surrendered. If a threat threatens to kill you, how can you be sure they won't just kill you if you complied anyway?
Sadly a duress PIN isn't designed to make you unaccountable. An erased device will always look obvious, and how they treat it really depends on who is trying to take it away.
You can best describe it as a trigger for erasing data to prevent an unauthorized party (in your proximity) from having potential access. It's great for protecting data you do not want anybody but yourself knowing. A whistleblower preparing to leak something confidential could come to mind.
It's more about protecting your data than yourself.

2024-06-01 14:43:01

- reply

Yes of course. Wouldn't make sense to do something that causes permanent damage. Can reinstall GrapheneOS or another OS without problems.
Since release is in Alpha there will be people in Alpha testing channels reinstalling GrapheneOS often for further QA.
Once backups are improved and not using Seedvault, that new backup system should be designed to work well for recovering after a duress trigger. Although there are bigger priorities right now.

2024-06-01 09:45:43

#GrapheneOS version 2024053100 released. Duress Password is finally here.
- add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down
- disable unused adoptable storage support since it would complicate duress password support (support can be added if we ever support a device able to use it)
- increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature
- disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access
- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153
- kernel (6.1): update to latest GKI LTS branch revision
- Vanadium: update to version 125.0.6422.147.0
- GmsCompatConfig: update to version 115
-make SystemUI tests compatible with GrapheneOS changes
https://grapheneos.org/releases#2024053100

2024-05-30 14:59:30

I was requested to make a glossary for the terms so here they are:
AFU: After First Unlock
Cellebrite refers to devices AFU as a device where it is in AFU state where they do not know the user's credential. If it is known or brute forced, they use the term 'Unlocked' instead.
AFU support without Brute Force could imply a unique exploit to unlock, like IPR or a lockscreen bypass.
BF: Brute Force
BFU: Before First Unlock
A 'BFU Extraction' on the table is a type of extraction for a very small amount of BFU state accessible data only. It doesn't mean they can extract the entire device. Using a brute force to unlock the device would turn it into Unlocked.
FBE: Filesystem-Based Encryption (Encryption Android and iOS uses)
FDE: Full Disk Encryption (Android FBE is really a form of FDE, but they use FDE to refer to the non-filesystem-based dm-crypt encryption from older Android versions.)
FFS: Full File System extraction (OS data, data of current user, app data, files and more).
SPL: Security Patch Level ('Up to {date} SPL' means it works on versions BEFORE that date)
Supersonic BF: Supersonic Brute Force
IPR: Instant Password Retrieval (iPhone specific exploit)
#nevent1q…e4jw

2024-05-26 00:17:18

- reply

There isn't. We're just posting a review on these leaked details to help dispel false claims about GrapheneOS being compromised by Cellebrite and also advise the general public what these companies are up to.
The documents tell a bigger picture that we are one of the only platforms actually protecting against attacks on devices by users that don't provide the passphrase, as what the images tell.

2024-05-25 23:43:37

Personal note:
Companies selling exploits for smartphones talking about #GrapheneOS in their internal documents and their limitation and failure in targeting the OS is only further evidence of the success of our recent mobile security and privacy work.
A multi-million dollar industry of companies exist just to discover and sell exploits for devices. Cellebrite is only one of many. Attacks by actors of such capabilities is what GrapheneOS aims to protect against, like we had done earlier this year, where we discovered vulnerabilities these companies took advantage of and disrupted their fun with improving and adding new security features. There is more to come.
We may not be as large as they are, but think about why they have to say our name and why they separated us from Android and iOS. What we do is significant and impactful. We don't ignore the competition or be deliberately vague or misleading about capabilities like these companies have been about us.
Digital forensics is such a valuable (and in my opinion, undervalued) cyber security skill but it is a shame these titans of the industry are all secretive and protective about their work. Some go as far as to mislead the public. Transparency and co-operation is the most valuable trait in the realm of digital security and companies like these shouldn't get a waiver.
I could have so much more to say including about how these companies' software are often designed too deliberately simple or complicated to make you depend on them and give them more money. Tools like Cellebrite are so easy to navigate and use that it feels like it's designed that way to not create forensics experts that can end up doing work themselves, and that other tools are deliberately complicated to faciliate to customer to buy their training.
If you want to hit companies like these where it hurts, then try learning DFIR, learn mobile forensics, and do it without selling out to them. Reduce what they can sell to you and break the gatekeeping the sector has.
#nevent1q…r59g

2024-05-25 19:41:09

The most recent release of #GrapheneOS (2024052100) adds the first piece of our ongoing work on duress/panic features. It makes standard factory resets including by device admin APIs wipe the device near instantly before it reboots to recovery to wipe and format it.
We made our own wipe-without-reboot but we're backporting the Android 15 implementation instead of using ours. They made it in response to our vulnerability report about this (CVE-2024-29748, reported by GrapheneOS).
The April release added 2 Pixel specific protections against the 2 vulnerabilities we reported, but both vulnerabilities essentially impact all Android devices and were only addressed for Pixels. The factory reset interruption also isn't fully addressed until they ship this part.
A wipe without reboot is important as cutting device power during a restart can interrupt the wipe process. GrapheneOS now wipes without a reboot.
https://grapheneos.org/releases#2024052100…

2024-05-25 19:33:04

- reply

More information on how it would be phrased can be seen here: https://grapheneos.org/faq#trademark

2024-05-25 19:29:31

- reply

Someone could build their own OS which can be based on GrapheneOS. It's permissible as long as people don't present it as the genuine GrapheneOS.
https://grapheneos.org/build
The end result still wouldn't be GrapheneOS though, and the security GrapheneOS has cannot be guaranteed on these builds. Some features are also entirely dependent on the hardware like MTE for newer Pixels or the Tensor Pixels USB-C port controls.

2024-05-20 20:42:22

- reply

There has been the base for it for a while now, bit we expect Desktop Mode to be finalized and functional first.
We are keeping eyes on the improvements. Current reporting is say Android 15 is when this will be ready.
https://9to5google.com/2024/04/04/android-desktop-mode-window-management/
When there is a fully working desktop mode upstream, it will come to GrapheneOS.

2024-05-19 11:55:42

- reply

If your threat model doesn't account being forced by someone to unlock with your biometric then it is a good choice. It also prevents someone seeing your PIN which prevents certain types of shoulder surfing.
We do not support face unlock on supported Pixels as we do not think they are secure enough. The older generations had dedicated face unlock hardware the current Pixels don't have.
Our second factor unlock will do a combination of fingerprint + PIN. That way they are two separate types of authentication (something you are and something you know).

2024-05-19 01:41:23

- reply

The secondary factor unlock is especially close to being done though and has been worked on by a community member who we plan to hire.

2024-05-19 01:32:37

- reply

Not yet. Both this and duress password are being worked on and most are close to being done but there is also other priorities like Pixel 8a too. Hopefully it is soon.

2024-05-18 23:39:42

- reply

You're misunderstanding the post 😅
The documentation is saying modern Pixels (especially with GrapheneOS) cannot be brute forced and they only work if users give their passwords away. Cellebrite are having substantial trouble against us, they can't break into any device we support, nor GrapheneOS.
GrapheneOS is mentioned in the documents (see pictures) and is the only OS mentioned separately to Android as their standard choices don't work.

2024-05-18 23:30:22

- reply

If someone wanted to brute force a device that is BFU, they need to exploit that secure element in addition, rather than just the phone. Very old Pixels we do not support anymore have secure element exploits as per the Cellebrite documentation.

2024-05-18 23:27:24

- reply

The secure element is the core piece that protects against brute force attacks and physical attacks. It is what enforces brute force throttling and also makes tampering far more difficult. We also use it for other features like in Auditor.
It is a hardware requirement of GrapheneOS to have one and for the device to support an alternative OS using it. That is one of several reasons we use Pixels and this note is an example of the benefit.

2024-05-18 23:15:42

- reply

We agree it's not an attack, we even said that capability is an expectation at the start.
Unfortunately, some malicious actors, namely people selling proprietary scam phone products have been misinterpreting such claims by Cellebrite, XRY and others about GrapheneOS being supported as GrapheneOS being under attack.
This is our response. This post is meant to highlight how we have got these companies' attention and how they have trouble dealing with us. Earlier this year we found the exploit XRY was using to brute force modern Pixels which lead to us patching it (and got a pretty good bounty from Google for it too). This is more of a post talking about our recent successes and future plans.
We are showing GrapheneOS is not like the other devices with stock or other OSes with exception to some modern iPhones in this post. Consent is the ONLY way for supported GrapheneOS devices at this time. We also wanted to reveal this Cellebrite documentation for clarity as we had discussed it in the past on our forum.

2024-05-18 23:02:23

- reply

Consent based extraction means that the owner of the device provided consent to extract the device by providing their password to unlock the phone. No OS can't protect against someone willing to do that obviously, so it's out of our scope.

2024-05-18 22:43:59

- reply

To piss off the right people accordingly:
- Use the most recent phone you possibly can
- Upgrade your phone to the newest possible generation as soon as possible after release
- Use the latest version of GrapheneOS ASAP
- Use a strong high entropy passphrase (makes bruteforce impossible if secure element is exploited)
- Set auto reboot time accordingly so encrypted data goes back at rest when the phone reboots.
- Turn phone off when in a risky situation.
- Disable radios when not using them (turn off Wi-Fi, use airplane mode, disable NFC, UWB etc.)
- Set an appropriate USB port control
- Use user profiles (data stored encrypted with separate credentials)
- Enable duress password when it comes out
- Enable second factor authentication unlock when it comes out

2024-05-18 22:14:07

- reply

It means they can only extract the device if the owner of the device is giving the person with Cellebrite the password to their device.
Your pixel would not be able to be brute forced. The secure element helps in stock OS and GrapheneOS.

2024-05-18 21:51:46

- reply

Cellebrite, XRY and others know about GrapheneOS and they don't like us. They talk about GrapheneOS in their advertising media and claim to support it but they only support extractions where the person gives away the device credential.
We have copies of Cellebrite's updated government and law enforcement brute force / data extraction exploit documentation.
Fully supported GrapheneOS devices (Pixel 6 and above) cannot be brute forced by them. GrapheneOS with a Pixel is the ONLY mainstream device they can't beyond up to date, modern iPhones (subject to change).
GrapheneOS has additional features beyond the defaults to make this even harder which aren't mentioned in the docs. We plan to add more.

2024-05-18 20:22:02

#GrapheneOS uncovers leaked documentation for smartphone exploits by Cellebrite.
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.
https://image.nostr.build/8e893edfdc5699a979ca586def3e2b20e0179013da3e4cc5b57522870e2982c6.jpg
https://image.nostr.build/3ef47e97cddad7dc02cdbf6778e484aac415be896ee86053aa7452db791d2934.jpg
Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks.
https://image.nostr.build/17f7e488f9093601c0dff65bdb1274509a91d26362669decc0b006b39e132e58.jpg
https://image.nostr.build/0ef4e9dcfc1063fbb35c516e134c56df8348195810446128a4ffc6219bdd44e8.jpg
Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits.
Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much.
As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked.
Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks.
By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked.
Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes.
GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging.
Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all.
Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up.
GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastbootd zeroing.
New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits.
Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this.
If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable.
See https://x.com/GrapheneOS/status/1775305179581018286 for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us.
Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock.
Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it:
https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/4
We have info on XRY, Graykey and others but not the same level of reliable details as this.

2024-05-15 21:36:05

An experimental prerelease of #GrapheneOS for the Pixel 8a is now available, including web installer support.
Pixel 8a currently uses Android 14 QPR1 instead of Android 14 QPR2, meaning it's missing many improvements from the 2nd quarterly release including important privacy and security enhancements. It's likely Android 14 QPR3 will be released in June which should resolve this problem.
Android 14 QPR2 is the largest ever quarterly release of Android, because it's the first trunk-based development release. It brought a lot of what Android 15 is going to ship, largely under the hood with new user-facing features largely disabled but present in the code.
Android 14 QPR2 was released on March 4th but had a delay in publishing to AOSP due to issues with pushing the code which was finished by March 5th. GrapheneOS had a release based on it within a day of that, but it took a couple days to reach staging due to regressions we found.
One of those regressions was the High severity Bluetooth vulnerability we found which was introduced in Android 14 QPR2. This issue slipped into our Stable channel release due to only coming up with rare configurations but we got it fixed on March 9th.
Since the Pixel 8a is still using Android 14 QPR1, our initial release is based on porting our changes from our 2024030300 release which was the last one based on QPR1 (https://grapheneos.org/releases#2024030300). It has a current May security patch level, but this doesn't meet our usual standards.
It's missing improvements to GrapheneOS from March, April and May in addition to Android 14 QPR2 changes. We backported our change enabling PAC/BTI for userspace and are using a current GrapheneOS 5.15 LTS common kernel source tree. SHOULD be fixed with June update, QPR3 or not.
Pixel 8a switched to Samsung GNSS (GPS, etc.) from Broadcom so we need to add Samsung PSDS support to our network services for PSDS to work.

2024-05-15 12:03:56

- reply

We are very disappointed with this route they took. When the 8a has the same upstream OS version then it won't need to rely on a reduced feature pre-release like now.

2024-05-15 12:01:18

- reply

Always has been. It's just it never goes well so far because the OEMs always want gimmicks, implement security features improperly or don't want to at all to cut the cost. Having less security than the baseline in our documentation is unacceptable to us.
If we supported devices that are less or improperly secured then it ends up with us being the blamed party for these devices rather than the OEM who slacked off. People would then say it's the fault of GrapheneOS as a whole when the secure devices don't get affected by such problems.
Supporting existing devices is also on the cards but OEMs don't play fair, like Samsung crippling security features and even cameras permanently. I am personally not the type to have the law step in on things like this, but I totally think there should be some litigation about this.

2024-05-15 11:47:55

- reply

We're working on making an experimental pre-release build of GrapheneOS for the Pixel 8a. It will have the 2024-05-05 security patch level but it will initially be missing the Android 14 QPR2 improvements and also the many GrapheneOS improvements since our March 3rd release.
There's a high chance Android 14 QPR3 will be released in June, and they likely decided it didn't make sense to go through all the work of getting QPR2 ready for release. Launching a brand new Pixel with backports to a previous quarterly release is still quite a strange choice.

2024-05-15 03:56:25

Pixel 8a with the latest May 2024 update is running Android 14 QPR1 with backported security patches instead of Android 14 QPR2.
Android 14 QPR2 was released in March 2024 and is by far the largest quarterly release so far due to being the first trunk-based quarterly release.
We're definitely not going to backport all the changes we've made since March to Android 14 QPR1. That means we can't simply make the usual device support branch to support it. It's going to need to start out being treated as if it's an end-of-life device in extended support.
The Pixel 8a doesn't currently meet our expectations. We haven't decided if we want to move development resources from working on new features to providing experimental support for a device with a botched launch. It would be a lot more efficient to wait for it to be fixed first.
It might get fixed in the June release. We could put in a bunch of effort to get experimental support for it in the next 24 hours but that will come at a big cost and it won't be anywhere close to something we can consider a production release due to what they released, not us.

2024-05-14 23:17:38

Our #Vanadium browser (https://grapheneos.org/features#vanadium) is based on the stable releases of Chromium. We port to the new releases when they're still in Beta/Dev/Canary but we wait until it's Stable to upgrade, particularly since Stable is the only branch with proper security support.
Within release channels, Chromium uses staged rollouts where initially only a random subset of users get the new release. Recently, the initial Stable channel release started being done 1 week early and only rolled out to a tiny number of users:
https://developer.chrome.com/blog/early-stable
Current release status for Android is at https://chromiumdash.appspot.com/releases?platform=Android. There are 2 variants of a regular Stable release and 2 of an early one, since they enjoy A/B testing changes so much.
We've been following the early Stable, but this month they failed to support it properly...
After the pair of early Stable releases based on v125 for Android, there were 2 pairs of releases based on v124 with 2 rounds of security patches for issues being exploited in the wild. They failed to update the early Stable release as they have before, so we had to deal with it.
Strangely, it appears that the early Stable channel release was only rolled out for Android and the Safari-based iOS app. The 0.2% of Android users receiving the early Stable release aren't getting patches for those 2 vulnerabilities being exploited in the wild. That's not great.
These are the 2 patches missing for Android users who get updated to 125.0.6422.34 or 125.0.6422.35:
https://chromereleases.googleblog.com/2024/05/stable-channel-update-for-desktop_9.html
https://chromereleases.googleblog.com/2024/05/stable-channel-update-for-desktop_13.html
Both are marked as having an exploit in the wild. They should really simply make 1 tag and stop making things overly complex.
#GrapheneOS

2024-05-12 11:21:55

- reply

Auditor has been updated to support the Pixel 8a on the stock OS and preparations have been made for GrapheneOS support.
https://github.com/GrapheneOS/Auditor/releases/tag/80
When upstream source is available on the device release date, a GrapheneOS build will be produced.

2024-05-11 23:32:03

We've received the Pixel 8a for our device testing farm already even though it officially ships May 14th.
Both Android Open Source Project source code tags and stock OS factory images / updates will likely be published on May 14th. We'll need those to add GrapheneOS support.
They typically ship pre-ordered devices a few days early to provide most people with an estimated delivery date on the launch day. It's a bit odd they don't publish everything on the day they ship instead of the planned arrival day since many do arrive early. It's fine with us.
Today, we're going to be adding support for the Pixel 8a in Auditor along with generating and backing up official GrapheneOS signing keys which are separate for each device for security reasons. We can't do much else before the official launch day when the code is published.
#GrapheneOS
#nevent1q…f0z9

2024-05-11 09:45:29

- reply

Take a look at: https://discuss.grapheneos.org/d/10937-cant-update-vanadium/2

2024-05-10 22:37:43

Latest Vanadium release contains a backport early patch for CVE-2024-4671. Update if yours has not been already. #GrapheneOS

2024-05-10 09:05:48

#GrapheneOS version 2024050900 released.
This release provides a preliminary fix against VPNs that failed to configure DNS properly causing a leak.
- prevent app-based VPN implementations from leaking DNS requests when the VPN is down/connecting (this is a preliminary defense against this issue and more research is required, along with apps preventing the leaks on their end or they'll still have leaks outside of GrapheneOS)
- exclude Settings app from visible Location indicator too since it gets triggered from accessing Wi-Fi data when enabling Wi-Fi hotspot and potentially other info tied to Wi-Fi and Bluetooth
- Vanadium: update to version 125.0.6422.35.0
- PDF Viewer: update to version 19
https://grapheneos.org/releases#2024050900

2024-05-10 01:08:45

In light of a recent high severity vulnerability involving pdf.js, the #GrapheneOS' PDF viewer is not affected.
We use a strict Content-Security-Policy allowlisting the app's static CSS and JavaScript without permitting unsafe-eval or unsafe-inline. It's blocked from using eval or including dynamic JS.
Even if we didn't set a Content Security Policy, the whole point of the app is that it renders a PDF in a sandboxed WebView instance without network, file or content access. It exposes a fairly small subset of the attack surface exposed by a web browser to any web site you visit.
The only data in the sandboxed WebView instance is the PDF which is written into it by the app without giving it access to the file/content. Even if an attacker somehow got JavaScript code execution despite our strict CSP, they couldn't do anything beyond attacking the browser.
The reason we use pdf.js is because it's designed to run efficiently in the browser sandbox. However, unlike opening a website in the browser, we use a restricted environment: no network/file/other access, no dynamic JS or CSS, many features disabled via Permissions Policy, etc.
JavaScript is memory safe but normally has pervasive dynamic code execution via inline JavaScript, dynamically included files and eval. It runs inside a restricted browser sandbox. The browser renderer implementing that sandbox runs inside of the browser's OS level sandbox.
GrapheneOS uses a hardened WebView provided by Vanadium. On Google certified Android OSes, it's provided by Chrome. Either way, our approach is far safer than a C++ PDF library in an OS sandbox (isolatedProcess). It provides 2 extra layers of strong security against most attacks.
Exploiting a vulnerability in the PDF library doesn't really work against our PDF Viewer app since there's an allowlist for the code. In practice, an attacker would need to exploit Chromium's rendering indirectly through pdf.js such as targeting browser font/image rendering.
Android uses isolatedProcess for the official PDF rendering library, which lacks our additional layers of protection and is far easier to exploit. Nearly all Android PDF apps bundle their own C or C++ PDF rendering library and don't bother even using an isolatedProcess sandbox.
Likewise, an update for the PDF viewer had been pushed as soon as the new version was released to have the patched pdf.js version.
Information about the vulnerability: https://github.com/advisories/GHSA-wgrm-67xf-hhpq
#nevent1q…e45h

2024-05-10 00:55:12

- reply

When you download an app it gives you the choice to enable/disable on the install dialog.
Otherwise, go to Settings -> Apps -> All apps -> (the app you choose) -> Permissions -> Network

2024-05-09 21:35:38

- reply

That notification appears for any keyboard app, it isn't specifically about GBoard.
You are free to disable internet access for the keyboard and it can't send anything out.

2024-05-09 20:17:10

- reply

Have you considered GBoard? It is the official keyboard used in the stock Pixel OS. You are free to disable it's network access if you have privacy concerns. It has no issues.

2024-05-08 11:29:49

- reply

As we expected, it's listed in the Pixel Update Bulletin despite being an Android Open Source Project vulnerability and patch:
https://source.android.com/docs/security/bulletin/pixel/2024-05-01
Android Security Bulletins only cover the subset of High/Critical severity patches backported to the baseline yearly releases.
(this has been pushed in the latest GrapheneOS update)

2024-05-08 04:51:40

#GrapheneOS version 2024050700 released:
While it appears the patch level is older, this is due to Google not releasing the full SPL until later.
- full 2024-05-05 security patch level
rebased onto AP1A.240505.005 Android Open Source Project release
- update our backports of mainline APEX Health Fitness patches
- kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.213
- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.151
- TalkBack (screen reader): update dependencies
- Vanadium: update to version 124.0.6367.159.0
- PDF Viewer: update to version 18
https://grapheneos.org/releases#2024050700

2024-05-07 23:30:30

We've pre-ordered a Pixel 8a for our official device testing farm. They push the Android Open Source Project tags and stock OS factory images on the official release day. Should take us a couple hours to add support for it. We'll build, test and make an official release quickly. #GrapheneOS

2024-05-07 18:37:01

Pixel 8a is official
https://arstechnica.com/gadgets/2024/05/the-499-google-pixel-8a-is-official-with-120-hz-display-7-years-of-updates/

2024-05-07 18:28:19

- reply

None
It was patched by us months ago, within days after Android 14 QPR2 was released. Pixel 8 / 8 Pro supports hardware memory tagging (MTE) which GrapheneOS uses. Whenever something like this happens then what causes the memory corruption would crash. MTE is also how we noticed it so quickly. We have no reason to expect it was exploited anywhere.

2024-05-07 18:03:04

#GrapheneOS receives third Android Security Acknowledgement from Google this year. This time for a high-severity Bluetooth vulnerability:
Google has listed the CVE-2024-23694 vulnerability we reported in the security acknowledgements for May 2024:
https://source.android.com/docs/security/overview/acknowledgements
This is the Bluetooth issue we found with memory tagging which they assigned a High severity. We fixed this on March 9th. This vulnerability isn't listed in the baseline Android Security Bulletin despite being an Android Open Source Project issue. It will likely be listed in the Pixel Update Bulletin which should be today with the monthly update of AOSP and the Pixel OS.
This vulnerability only impacts Android 14 QPR2 and later. It's possible they only list issues impacting the initial release of Android 14 in Android Security Bulletins and put the rest in Pixel bulletins. It's odd how Pixel bulletins are mostly issues impacting other devices.
Last month, Pixels fixed 2 vulnerabilities we reported which were both classified as High severity and were both exploited in the wild by forensic companies to extract data on smartphones. Both also impact non-Pixels but were only fixed for Pixels and listed in the Pixel bulletin.
We understand why they didn't list those firmware patches in the Android Security Bulletin (ASB) since other devices with the same issues need their own unique firmware patches for them.
The AOSP 14 QPR2 Bluetooth big not being listed means ASB is less complete than we thought though.

2024-05-07 15:40:18

- reply

I posted this note a while back, and we disagree with Mullvad on this. A GrapheneOS user discovered them and we are aware of some leaks they didn't mention... VPN apps can leak if not implemented properly, that's why not every VPN was affected by this according to their article.
The second issue with leak while the VPN has crashed is likely an OS bug (race condition?) though and what we want to fix. Fortunately this affecting someone should be a very low chance and bo one would go out of their way to reproduce this bug willingly by forcibly disconnecting and timing a DNS query at a precise moment.
#nevent1q…aakd

2024-05-07 14:19:54

- reply

Proton is as transparent as they could be on this and they openly talk about what they do / could see on their web site all the time. It comes across like a lot of people use Proton Mail but don't actually read what they say and then get in trouble. A lot of the data they received are opt-in by users (IP history logs, recovery emails) and what is left is impossible for them to stop them knowing.
If a company following the law is 'compromised' then by their logic everything is. Arguably using a service that endorses breaking it makes you even more compromised by putting a target on your back. EncroChat, SkyECC, Phantom Secure, ANOM had hundreds of thousands of combined users and countless arrests... the price is paid on all of their users. Fortunately they were almost all involved in serious crime, but that doesn't mean the next time it wouldn't be normal people who could be misled by a false promise of security and privacy. Proton is a good provider by telling the truth and following good practice.
Email is not like SimpleX or Signal, they can't move hosted infrastructure away to their users so they cannot get legal requests or design their product in a way where they can't provide any valuable information. Even if you host your own email, it wouldn't stop them going after the person above the pyramid (your host / network provider) to disrupt the operation...

2024-05-07 13:30:35

Android monthly security backports were released this Monday. We expect the full monthly release to be released much later today (Tuesday). It's what happened last month, but last time we expected the monthly release to be delayed a week so we did an early release with backports.
Monthly/quarterly/yearly releases include Low/Moderate severity patches not backported to older releases and are needed for Pixel firmware/driver patches. Those aren't published/disclosed for May yet. We'll do an early release with the ASB backports if it's not released today.
We've reviewed the backports and can easily ship them if needed. We've included the next set of Linux kernel GKI LTS updates too.
We'll have mitigations for the 3rd party VPN app DNS leaks discovered by our community soon, but likely not today's release.

2024-05-06 14:33:06

- reply

We don't make choices on that since it requires an extremely high degree of trust to use a VPN. I am aware IVPN, Proton VPN and Mullvad have exceptional reputation but that isn't a formal recommendation. Some members go beyond and use Tor. For someone around Nostr I heard IVPN accepts Lightning and Mullvad has lightning resellers so that would likely be better for them.
I just use what I like. There's a lot of things people would enjoy knowing I use, but I also use a lot of things people in a lot of spaces would lynch me for using as well. Use what is best for you and learn more about that choice to help establish trust beforehand.

2024-05-04 18:13:38

- reply

This is different and was also misleading on Mullvad's part, it's intentionally designed that way.
We make an explanation on that here: https://grapheneos.org/faq#default-connections
You can also turn that off in GrapheneOS.

2024-05-04 18:11:24

- reply

They would have, but we have heavy disagreements with Mullvad on how they phrase this as they fixed it within their app. If it is possible to set up apps in a way that they don't leak without OS changes then it was an app issue, it's premature to blame the OS. They are being unclear about this. The Android OS VPN implementation is unaffected. The OS could also prevent these leaks but it is possible they may not had viewed this in scope of the feature. DNS is handled in a special way and the VPN gets to set DNS separately from the VPN and can send it through it or outside it, etc.
VPN app developers should also be testing these basic cases themselves already ("only affect certain apps") and it appears they had not. As for the second case ("For a short period of time while a VPN app is re-configuring the tunnel or is being force-stopped/crashes"), this is being investigated. It sounds like an OS bug but a leak is not inherently responsible by the OS. Fortunately that second example is very limited.
It is also worth noting they did not discover these issues first rather they were reported to us by a GrapheneOS user which we posted about days before them. We are also aware of a local network multicast leak which is an actual OS bug which they haven't mentioned.
Also see: https://news.ycombinator.com/item?id=40252719
Mullvad are also linking an older article regarding a connectivity check "leak" which is misleading. That connectivity check is needed for determining which networks work, and triggering captive portals the user can interact with to log into WiFi networks with login pages. This would help you deal with the captive portal *without* disabling the VPN which would make everything else leak. GrapheneOS has also had the option to disable or change it for a long time.

2024-05-04 08:18:20

- reply

Forgot about that link:
https://grapheneos.org/releases#2024050300

2024-05-04 08:17:13

- reply

You can only use 5.15 on Pixel 8 and later at the moment. The 6.10 builds are because Google is planning to upgrade to Kernel 6.1 for all Tensor devices in the future. When an upgrade is done above, we will follow.

2024-05-04 07:59:31

#GrapheneOS version 2024050300 released.
This update contains various hardening additions, fixes Google Fi eSIM activation (again) and changes OS infrastructure to prepare for an upcoming App Communication Scopes feature.
See the changes:
- remove special handling of the resolver activity ("Open with..." dialog) which was added to Android in order to support instant apps as preparation for our in-development App Communication Scopes feature
- fix Google Fi eSIM activation
- improve isolation of the eSIM activation apps
- improve GrapheneOS infrastructure for per-app state
- enable heap memory tagging for vendor processes by default, remove the user-facing toggle in the Settings and restrict toggling the value to debug builds
- disable most handling for instant apps in the package manager as attack surface reduction
- disable out-of-band APEX updates as attack surface reduction
- only allow first party app source and shell to update system packages
- improve robustness of original-package handling
- Settings: hide GNSS SUPL and PSDS settings on devices without GNSS hardware
- fix regression from our Android 14 QPR2 port causing Storage/Contact Scopes link to disappear after going back to the permissions screen
- improve setup wizard theme to more closely match the stock Pixel OS configuration
- backport mainline APEX module patches for Android Health, Media Provider, Network Stack, and Wi-Fi
- kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.212
- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.150
- kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.80
- Log Viewer: use human readable UTC time for logcat timestamps
- GmsCompatConfig: update to version 109
- Vanadium: update to version 124.0.6367.113.0
- Apps: update to version 23
- work around our app repository client taking ownership of updates for the debug toggle we use to test new Android Auto releases
- fix debug build option for testing same versionCode package updates

2024-04-29 08:14:37

- reply

Also: there's so many you wouldn't be able to try them all.
On a personal note, I use Phoenix for my LN funds, but want to see what the hype with ZEUS is about.

2024-04-29 08:07:33

- reply

By 'setups' I am also talking about a good branch of wallet users who would set up a GrapheneOS device and never connect it to the Internet to keep it cold. I have also heard loyal Samourai users had done this, hence their prior mention.
Please keep your device up to date if you choose to do something like this. Do not ignore this. New security features and further hardening happen often, for example, the USB Port Control feature to disable the USB port is very valuable.

2024-04-29 08:02:27

- reply

GrapheneOS will not (and will probably never) make a formal recommendation for a cryptocurrency wallet, and considering recent events regarding some popular offerings it is best to leave that responsibility to the users. If a project was endorsed that ended up having consequential events (unmaintained, a breach of trust, legal issues) then that would be terrible. Doing such a move is a dangerous slope. We are grateful wallet developers recommend and use GrapheneOS however.
Use a wallet that is up to date, maintained and trustworthy and follows app security practices. Avoid suspicious apps. If you use a cold wallet then use your official or endorsed by manufacturer apps to avoid as many trusted parties as possible.
However, it is up for recommendation to follow the core cryptocurrency security practices. Use GrapheneOS for funds you are okay with the potential risk of loss if you are using the device as your smartphone. Your phone will not protect your funds for a lifetime, if you are concerned you have been compromised or you no longer have access to the device holding those funds, move the funds to a new address/wallet as soon as possible. The security model for smartphone wallets are that you are expected to move the funds if you lose the device that accesses it.

2024-04-29 07:45:23

Throwback to some comments from the past about setups involving #GrapheneOS with and the threat model of the former Samourai Wallet.
#nevent1q…4guk

2024-04-29 04:13:51

- reply

I'm glad it's not 😥

2024-04-29 04:13:38

- reply

Might require play services since PWA notifications uses Firebase:
https://discuss.grapheneos.org/d/2587-push-notification-not-working-with-pwa/

2024-04-29 04:01:01

- reply

The final boss
"Hack is Wack' - what were they thinking??
https://youtu.be/C_N0pDqfsX4

2024-04-29 02:11:54

- reply

FAQ, usage guide, installer:
https://grapheneos.org

2024-04-28 01:19:50

A familiar face in this blog post... 🫣
#nevent1q…t4wg

2024-04-27 05:24:05

- reply

Can add the BSDs, iOS, and Web on there too... Go has seriously untapped potential.

2024-04-27 04:32:42

If I had a dollar for every time someone made GrapheneOS anime girl fanart I'd have about 10,000 sats
And no, AI doesn't count.

2024-04-26 13:48:01

- reply

Respectable opinion! I just find it hard to find what the selling point is... since in my experience many other browsers provides a similar option with side tabs and split tab views and whatnot... Vivaldi (and even Microsoft Edge) seems to do all of this just fine.
Chrome does slack off in the UI department though, I hate the layout where the tabs are just floating boxes now, but it's a very subtle issue.

2024-04-26 13:29:37

- reply

Go is a fantastic language
Closest I can think of for a task like this is Gio UI. I've seen some work done on there and it's interesting but I've heard it's not the complete package yet. I want GUI libraries for Go to succeed. Think it would be a great starting block for cross-platform (Android and desktop in my case) Nostr/wallet apps.
Think web browsers should strictly be web browsers, any feature should exist to improve the browsing experience. I find software projects that are unnecessarily using the web platforms aggravating and I hate people making web browsers The Everything App™️ when they're already a security nightmare.
I've seen irrelevant things like clipboard managers and ffmpeg GUI wrappers using Electron and it's absolutely disgusting. I'm very selective when it comes to it

2024-04-26 10:00:38

Every new browser tries to reinvent the wheel when it doesn't need to be reinvented. Most browsers look the same because they are what people favour the most. Stop trying.
New UIs, service integrations, bundling VPNs and AI assistants, trying to ecosystem some shit no one wants is an example of reinventing the wheel that doesn't need to be. Browsers like Arc and Opera GX are just today's Maxthon Nitro or Comodo Dragon.
Browsers should be universal because the web is universal and everyone uses their own thing. Vivaldi has a ton of cool, optional features for this like an email client (for any service) and feed reader (used universally) and don't bug you to use theirs intrusively. These are FAR MORE important than Brave's AI assistant in my eyes. Edge has some awful features as well despite having leading browser security features at the same time.
Bundling an AI assistant or other services also doesn't make sense when you can just add sidebar page support and add an AI assistant you use as a sidebar (Note: Brave doesn't let you add other pages as a sidebar). I think you could even debloat browsers like Vivaldi and have these things like translators, notes or email clients be something the user sets up as a sidebar web page, instead of having them in the browser at all to be honest. I understand there's a user experience merit though!
Making a browser faster, more productive, more secure and private while making the web far more tolerable should be the way to go about things. Instead of trying to let users be unique, let users be themselves.
#nevent1q…yra3

2024-04-26 09:22:51

- reply

And Vanadium hardening when we're talking mobile ;)

2024-04-26 09:22:10

Vivaldi UI and features with Brave state partitioning, anti-fingerprinting and content blocking would kill the browser game

2024-04-25 20:59:31

- reply

Many of that depends on users but I would suggest reading the docs and guides on https://grapheneos.org for it. How and where people get their apps is down to who they trust to do the job.
We have expressed interest in adding Accrescent.app (a privacy and security focused app store) as a mirror to our app repository soon. It's app catalogue is very small and it is in early alpha but it's hopeful users add onto it. When that happens we will recommend users to use Accrescent further.
The forums also exist ( https://discuss.grapheneos.org ) as well for user questions

2024-04-25 03:52:41

- reply

According to the indictment Keonne had links to the UK and SamouraiDev had France as well. These two also had a company registered in the UK which was dissolved a while ago.
I can't speak on their legal case but I imagine they weren't in their sights for long considering the publicity of their identities beforehand and their social media posts. I imagine most of the work went into seizing their infrastructure.

2024-04-25 03:39:18

- reply

Because the data for that is *always* not at rest the moment you unlock the device once after boot. On a user profile you can put data at rest by pressing the end session button, you cannot do that for the Owner because the owner manages crucial OS functions. It is how Android works. To put Owner at rest you need to power off the device or restart it instead.
It's a more extreme move but it adds resistance to attacks especially in forensic situations.

2024-04-25 00:44:50

- reply

Can be, but unless the threat model calls for it then sure.
I currently have 4 profiles, not counting the Owner which has nothing but a VPN on it for OS updates.
One is for normal use
One for Google Play required apps
One for handling cryptocurrencies separately (that way data is only not at rest when not using it)
One for Tor only usage (very rare and unused)
I rarely use the others to be honest

2024-04-24 16:03:15

- reply

This is a common way people set-up user profiles, no issue with using it this way if you're fine with sacrificing a little user experience.

2024-04-22 22:30:47

- reply

* most people don't enable encryption in public Matrix rooms anyway since it scales like shit, super unstable platform and rooms can just brick if they are large enough. Happened several times with us.

2024-04-22 22:29:29

- reply

Discord is more of a social media platform than a messaging platform, everything you do on there should be treated as public, it's literally designed for rooms for tens of thousands of people to talk in. Sites like these have existed for years.
People do the same mistakes with Matrix as well, although you can just look at the web preview of rooms with no account, and encryption is useless in big rooms if anyone can join and watch.
We was able to watch an approve-only Discord server for forensics analysts (employees of *those* companies) and law enforcement because they kept the room preview open. They sounded pretty annoyed about GrapheneOS too...

2024-04-22 06:37:56

#GrapheneOS version 2034042100 released.
This update backports an upstream Linux kernel patch for a kernel panic caused by another patch in the last update.
These are the changes from the previous update (2024042000) that are relevant:
- add toggle in Settings > Security for opting into memory tagging in vendor processes currently excluded from it with the end goal of having it force enabled without a toggle as we do for the rest of the base OS
- allow eSIM activation app to interact with Google Fi app when installed to fix Google Fi activation
- use ro.vendor.build.svn system property from adevtool instead of AOSP to make sure it always matches the stock OS
- Pixel Fold: update to AP1A.240405.002.A2 vendor files
- Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel 8, Pixel 8 Pro: update to AP1A.240405.002.B1 vendor files
- Log Viewer: include kernel log buffer in default log output
- Log Viewer: show "Save" instead of "Copy" button for logs that are over ~50 KB
- Log Viewer: improve handling of log saving
- backport mainline APEX module patches for Android Health, ART, DNS Resolver, Media Provider, Network Stack, PermissionController and Wi-Fi
- TalkBack (screen reader): update base code to 14.1 and massively overhaul our changes to it
- Vanadium: update to version 124.0.6367.54.0
- Camera: update to version 68
- Auditor: update to version 79
- GmsCompatConfig: update to version 104
- Setup Wizard: layout and style improvements
- Setup Wizard: add functionality for testing on debug builds
https://grapheneos.org/releases#2024042100

2024-04-21 18:12:57

Our latest release will remain in the Alpha channel due to upstream Linux kernel regressions in the latest 5.15 GKI LTS release causing crashes on the Pixel 8 and Pixel 8 Pro for some users. Very likely caused by f2fs backports in the newer LTS release. Major thanks to our testers.
#nevent1q…jzzk

2024-04-21 09:38:48

- reply

Updates are delivered OTA and installed automatically after an update check. A reboot finishes the process. You can also choose to check for an update immediately after it is released providing it is in your release channel manually in Settings on the owner user profile as well.
See: https://grapheneos.org/usage#updates
This update is currently in Alpha channel. It will move to Beta in a few hours and then the Stable channel after more, providing no issues of the update are reported.