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
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.
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.
#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.
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)
#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
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
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.
#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.
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.
Before you start sharing clickbait headlines like "Proton is compromised", "privacy is dead", etc, just read the whole fucking news article first.
Proton always said they would provide whatever they have (metadata) to Law Enforcement if subpoenaed. That was never a secret or in question. They are an actual registered company...
They still don't nhave access to email body content. E2E encryption still works. What they can provide is IP addresses, recovery email, recovery phone, browser fingerprints and email metadata (timestamp, recipient, sender, subject, size).
If you are worried about this (you should), use a VPN (not proton VPN) or Tor, avoid disclosing sensitive information in the email subject.
Despite the FUD, people are still 99% safer and more private using ProtonMail relative to Gmail or similar.
https://restoreprivacy.com/protonmail-discloses-user-data-leading-to-arrest-in-spain/
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...
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.
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.
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.
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm does this Android bug also affect GrapheneOS?
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.
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.
#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
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.
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.