It's in our issue tracker, but it's a low priority compared to what needs to be worked on. You can hold press the Vanadium icon on the home menu and hold press the "New incognito tab" to add the shortcut to the home screen if that helps.
It's still a planned feature but it is very difficult to implement the way we want it to be. This may take a while the same way duress PIN or 2FA fingerprint unlock did. It's likely this feature will start with a narrow implementation that blocks most app communication but not prevention of two apps working between one another. It will progress from there.
User profiles and private spaces segregate app communication while also providing users the choice to use a different VPN or Tor.
For alpha testers, a preview update of the AOSP Messaging app is out in #GrapheneOS. It is mostly bug fixes and to be updated to a newer target API.
This is part of future work to replace all the default apps with new, better apps or to fork them and make them more useable. App developers have been hired to help for this task. Changes won't be immediate but app improvements should be made in the near future.
The 6 is the oldest, but the 6a is cheaper than the 6 and is supported longer as it is their budget version released later. Once a device is no longer supported by Google it becomes unsupported by us.
The 8a is the best overall value as you get 7 years of updates rather than 5 and ALL security features are available. Memory tagging (our top class security feature) isn't available on Pixels earlier than 8 due to hardware. The 6a is the cheapest Pixel overall though.
Stacker News is now noncustodial (after some delays) so final@stacker.news goes to final@minibits.cash from now on. Smaller, separate zaps preferred as sometimes I don't see them.
How they know:
We don't just prevent exploitation, we discover and fix ones that hit the stock OS:
Do we know if grapheneos is doing a version of its OS for the pixel watch?
nostr:npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c
We aren't planning to make a watch OS, sorry.
SMS wouldn't provide this access at all. It's likely a VPN issue, I had the project account reply to you about more info as well. It's through Mastodon so it may not show everything correctly, a project-wide Nostr account is being considered though.
Improves battery lifespan by not charging the device. It supports bypass charging so once it goes over, the device runs on the charger's power instead of using the battery.
#GrapheneOS version 2024123000 released. Introducing two-factor fingerprint and PIN authentication, 80% battery charge limit, and more.
• add support for adding a PIN as a 2nd factor to fingerprint unlock to enable our new recommended high threat model configuration of a random diceware passphrase as the primary unlock method and fingerprint+PIN with a random 4-6 digit PIN as the regularly used secondary unlock method (the usual limitations of secondary unlock only being usable for 48 hours after successful primary unlock and our limit of 5 total secondary unlock attempts apply as usual)
• add support for limiting charging the battery to 80% with support for bypass charging similar to the new Android 15 QPR1 stock Pixel OS feature, although unlike the stock Pixel OS our implementation still works while using a secondary user (the limit is currently hard-wired to 80% due to that being what's properly supported throughout the OS, but we can eventually make it configurable)
• add support for disabling dynamic code loading via storage for user installed by default as we already do for the dynamic code loading via memory setting
• allow dynamic code loading from storage by default for apps depending on Play services due to the legacy dynamite module implementation not yet being fully replaced by split APKs to avoid users encountering a huge number of issues if they disable it by default for user installed apps (users can still disable it for these apps manually and we won't need to keep this exception forever since Google is moving to split APKs for dynamite modules)
• add support for partially recompiling apps (speed-profile) in the Finalizing step of OS updates to skip partially recompiling them during boot, but while still doing most of the work after boot in the background (speed) to avoid slowing down OS update installation too much
• remove adding back boot-time display of app compilation progress now that it's no longer heavily used
• use 2 threads instead of 1 for background compilation of apps
• switch to the new upstream default of 4 threads for compiling apps during boot instead of our previous 2 threads which we set to replace the previous upstream default of a single thread
• Settings: add back battery optimization settings link to Battery screen which was removed by Android a long time ago
• Settings: don't disable App info > Battery usage item while its summary is loading
• Settings: temporarily stop showing battery usage info in App info item summary due to an upstream regression causing it to take more than 5 seconds to load in many cases
• add back our fix for an upstream Android bug causing null pointer exception system_server crash in InputMethodManagerService triggered when ending user sessions because it turns out to still be required after Android 15 QPR1
• fix upstream Android bug causing null pointer exception system_server crash in NotificationManagerService
• Contacts: improve dark theme color contrast
• kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.232
• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.173
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.119
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.61
• kernel (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold): fix very minor Android 15 QPR1 regression causing the kernel commit hash to the omitted from the kernel version string and the Unix epoch being used as the build time instead of the kernel commit timestamp
• Camera: update to version 75
• Vanadium: update to version 131.0.6778.200.0
• add developer option to log binder transactions
• fix ignoring harmless fingerprint-service.goodix crash for our system service crash reporting
No one else has reported this and every other query I looked in our forums and chats shows theirs as expected. I can't consider it a bug without it being reproduced. Please check your profile's settings and apps.
I would evaluate what apps you are using that has location permissions. You may have provided a location access even if you think you may have not or you haven't realised.
Apps can embed Google services into their own apps and integrate Play accounts for IAPs, etc.
Enabling location accuracy also gives Google location in exchange for more accurate locations optionally. Some had enabled this before.
I've only seen users report when relating to:
https://github.com/GrapheneOS/os-issue-tracker/issues/502 which has been known for years (it's in our FAQ) but this is only registered country code of the SIM and nothing further than that. I've also heard this isn't even used for what you're talking about either.
The session data may also be historical (did you initially set up or install without the VPN?) and I would see what happens if you remove that session and sign in again. Google also attempts to infer location based on location specific Google searches on the accounts.
just so you know I also made a Google account just for this, and I've not been able to reproduce it. I have all the privacy settings in the Google account maxed out. on other platforms it just tells me the device used to sign in and nothing else.
No one else has reported this and every other query I looked in our forums and chats shows theirs as expected. I can't consider it a bug without it being reproduced. Please check your profile's settings and apps.
I would evaluate what apps you are using that has location permissions. You may have provided a location access even if you think you may have not or you haven't realised.
Apps can embed Google services into their own apps and integrate Play accounts for IAPs, etc.
Enabling location accuracy also gives Google location in exchange for more accurate locations optionally. Some had enabled this before.
I've only seen users report when relating to:
https://github.com/GrapheneOS/os-issue-tracker/issues/502 which has been known for years (it's in our FAQ) but this is only registered country code of the SIM and nothing further than that. I've also heard this isn't even used for what you're talking about either.
The session data may also be historical (did you initially set up or install without the VPN?) and I would see what happens if you remove that session and sign in again. Google also attempts to infer location based on location specific Google searches on the accounts.
This isn't dumb at all, it's definitely the best keyboard available. I'm also using it.
It's in the roadmap to replace the stock OS keyboard with another but software licensing can be an issue.
Our 2-factor fingerprint unlock feature is now fully implemented and will be available in the upcoming #GrapheneOS release. This adds the option to set a PIN for using fingerprint unlock. You can use a strong diceware passphrase as the primary unlock method with fingerprint+PIN secondary unlock.
The usual restrictions on fingerprint unlock still apply. It's a secondary unlock mechanism only usable for 48 hours after the last primary unlock. The limit on failed fingerprint unlock attempts in GrapheneOS is 5 as opposed to allowing 4 batches of 5 attempts (20 total) with 30s delays in between.
The devices we support have a high quality secure element heavily throttling unlock attempts which is why a random 6 digit PIN provides secure encryption, unlike most Android devices. It's nicer to have a strong passphrase not depending on an attacker never being able to exploit the secure element.
Our new 2-factor fingerprint unlock feature means you can get this benefit of a strong passphrase while still having the convenience of a PIN. Since our PIN scrambling feature works with the 2nd factor PIN, you get the combined anti-shoulder-surfing benefits of a scrambled PIN and a fingerprint.
If you want to avoid entering your passphrase in public, you just need to make sure to refresh the 48 hour timer after last using it to unlock to keep fingerprint unlock available. We plan to add configuration for how many failed fingerprint unlock attempts are allowed to help with this use case.
We came up with the concept for this 2-factor fingerprint unlock feature in 2015 and filed it in the public issue tracker in 2016. This was extremely difficult to implement correctly and we needed to fix multiple upstream Android bugs. The lockscreen will be more robust even if you don't use this.
This is now one of the flagship features of GrapheneOS alongside hardened_malloc, hardware memory tagging, hardware-level disabling of the USB-C port, Storage Scopes, Contact Scopes, sandboxed Google Play compatibility layer, etc. It will be harder to port to new versions than our existing features.
Our duress PIN/password feature is fully compatible with our 2-factor fingerprint unlock and will near instantly wipe the device as usual if you enter the duress PIN instead of the correct 2nd factor PIN for fingerprint unlock. See https://grapheneos.org/features#duress for more details on that feature.
There will be a new #GrapheneOS release later with far more changes than usual, which will introduce two major features.
The first is the experimental implementation for 2-factor PIN and fingerprint unlocking.
The next is our own implementation of the Stock OS battery limitation setting, which will be better than the Stock OS as it will work with secondary users.
Compiling apps at boot should also be slightly faster as well.
Why does Duress PIN boot into recovery? Here's why
https://discuss.grapheneos.org/d/18523-why-duress-works-this-way/10