nostr:nprofile1qqsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgpz9mhxue69uhkummnw3ezuamfdejj7mtxgrd Does the GOS crew have any dirt on the new Pixels? Think the leaks are legit?
I know about as much as everyone else does, to be honest.
Usually news on leaks for Pixels end up being consistent with the real product so I do believe it somewhat. I don't have any dirt myself 🤷♂️
Certain banking apps use a buggy anti-tampering library which was broken by a security improvement in the most recent #GrapheneOS release. It wasn't reported during 2 days of Alpha/Beta testing. We've paused rolling it out to the Stable channel and we're working on resolving it.
Compatibility issue is caused by these apps having hand-written 64-bit ARM assembly code that's making system calls with the 32-bit ARM compatibility layer even on devices unable to run 32-bit ARM code at a CPU level. They depend on a quirk of how 32-bit ARM compatibility works.
Unfortunately, it means we need to temporarily revert the removal of the kernel's 32-bit compatibility layer on devices without 32-bit support. Banking apps are holding back security with their anti-tampering libraries. They do this to make it harder to audit their insecure apps.
#GrapheneOS version 2025070900 released.
- Settings: extend standard fingerprint enrollment stages with proper support for devices with power button fingerprint scanners (Pixel Fold, Pixel Tablet) which is not present in AOSP (Pixel Fold was still usable, but it had become incredibly hard to successfully register new fingerprints on the Pixel Tablet)
- improve warning for 32-bit-only apps by explaining why the warning is shown, how to resolve it for apps that are still developed and that we plan to phase out support for it on 5th/6th generation Pixels where it's still available
- show warning for 32-bit-only apps on each launch instead of only once
- kernel (Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a): disable 32-bit ABI support to substantially decrease kernel size and attack surface and raise mmap_min_addr to the standard 65536 for 64-bit-only ARM
- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.158
- adevtool: update file removal for 8th gen Pixels to skip Family Space related files
- GmsCompatConfig: update to version 122
- Vanadium: update to version 126.0.6478.122.3
#GrapheneOS: About the Positon location service:
#GrapheneOS: We're planning on phasing out support for 32-bit apps on 5th/6th generation Pixels where they're still supported. They were already phased out by Android for 7th generation Pixels and later, and by ARM for 2nd generation ARMv9 Cortex cores onwards. Since 7th/8th generation Pixel users are doing fine without them, we want to bring the improved security to users on 6th generation Pixels which still have a lot of support ahead of them. It will also save a significant amount of build time and bandwidth, particularly when we can move to 64-bit-only builds of Vanadium.
The main benefit is dropping all the 32-bit ABI support from the kernel including a bunch of awful legacy cruft for emulating legacy ARM features no longer supported by hardware.
The next release will add a clear warning to each launch of 32-bit-only apps. In nearly all cases, people just need to switch to proper builds of apps which aren't 32-bit-only such as the ones distributed by certain 3rd party mirror sites where users accidentally ended up on 32-bit-only builds.
It hasn't been possible to install 32-bit-only apps from the Play Store on 64-bit-capable devices since August 2021 and they blocked uploading either new apps or app updates without 64-bit support since August 2019.
#GrapheneOS version 2024070200 released
This is an early July security update release based on the July 2024 security patch backports. This month's release of the Android Open Source Project and stock Pixel OS will be available later today and we'll quickly release an update based on it following this one.
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.
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
Chromium's V8 Optimizer toggle for disabling JavaScript JIT compilation was changed to only disable the 2 higher tiers of JIT compilation while still leaving the baseline JIT compiler enabled. This also caused the device management policy for JIT predating this to change meaning.
They did this because they decided having a toggle which breaks WebAssembly support is unacceptable. We had to revert these changes.
Microsoft Edge implemented a WebAssembly interpreter instead, but it's not open source and there's nothing like it for Chrome yet.
Vanadium disables JS JIT by default and provides a convenient per-site toggle available in the drop down menu next to the URL. We've restored the previous meaning of disabling the JIT so you'll need to add exceptions for sites requiring WebAssembly again.
In theory, we could add 4 choices instead of 2: Disabled, Baseline JIT, Baseline JIT + Tier 2 and Full JIT. However, it's likely far too complicated and we're likely going to stick with having it either enabled or disabled. Chromium will hopefully add a WASM interpreter soon...
#grapheneos
Cool blog post from a prolific security researcher about how GrapheneOS's MTE caught a crash in the Signal messaging app: https://dustri.org/b/grapheneoss-mte-caught-a-crash-in-signal.html
Nostr is an unofficial platform and it's better for community moderators or supporting team members with knowledge of other platforms to do it individually. How Nostr is designed makes it hard to share an account with multiple people in a trustworthy way and also isn't something we'd like to do. Not every GrapheneOS member uses Bitcoin or Nostr, a portion prefer something else. There is diverse backgrounds. Our reach on Nostr is fantastic and very supportive.
This is also my personal page, but yes, most of my posts are about GrapheneOS since I don't have much else to talk about except GrapheneOS.
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
Apps can only see files you allow them to acces, id that's what you mean. Storage Scopes is a GraphneOS feature to only allow apps to see certain files if you don't want all to be seen by them.
#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.
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.
Our latest release improves our hardware-based USB-C port attack surface reduction. Our previous software-based feature has been extended and merged into it as a 2nd layer of enforcement. We've also extended it to disable pogo pins data at a hardware level on the Pixel Tablet.
Our previous feature is now fully obsolete and has been removed on devices with the newer approach, which is a nice simplification. We've rewritten the documentation here:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
Older approach is now only used on the Pixel 5a and earlier end-of-life devices.
Our documentation explains why our approach is much better than the standard Android USB HAL toggle available to device admin apps since Android 12. Standard approach only disables USB connections in the OS. It leaves USB-C and pogo pins enabled at both the OS and hardware level.
The standard approach also can't block new USB connections without ending existing USB connections. It has no distinction between those things. It forces a choice between ending existing USB connections when locking or delaying using it at all until the last USB connection ends.
Several operating systems previously included a port of our legacy software-based approach and mistakenly moved to the less secure approach of disabling USB via the standard USB HAL after the last USB connection ends. It's less secure than simply extending our legacy feature...
#GrapheneOS
#GrapheneOS version 2024062000 released.
This version removes the USB peripheral security settings where USB-C port controls are supported. This is because that setting does the same job and far better. There are also hardening improvements.
- remove our USB peripheral security setting on devices supporting our much better USB-C port mode (Pixel 6 and later)
- extend USB-C port setting to also handle pogo pins on the Pixel Tablet
- kernel (5.10, 5.15, 6.1, 6.6): replace our deny_new_usb feature with a new deny_new_usb2 feature also disabling USB gadgets
- extend USB-C port setting to enable deny_new_usb2 as a second layer of defense disabling new USB connections in the kernel (the existing implementation disables new connections and USB data at a hardware level via the USB controller, which disables more attack surface, but we want to keep around the higher level kernel approach too)
- Files: fix upstream null pointer exception triggered on resuming activity
- Settings: require user authentication for changing auto-reboot, USB peripheral and USB-C port security settings
- Settings: avoid prompting for user authentication when selecting the same value as before for GrapheneOS settings requiring it
- temporarily add back memory tagging exception for Pixel wifi_ext service
- simplify implementation of our auto-reboot feature and properly handle the first lock after the user first sets up a lock method
- avoid resetting USB-C port after first unlock if it was already connected Before First Unlock (fix for regression caused by upstream changes)
- add GrapheneOS Linux kernel port to the 6.6 GKI LTS branch
- kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.215
- kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.87
- kernel (6.1, 6.6): add script for building emulator kernel
- kernel (6.1, 6.6): enable forced module signing for x86_64 (emulator builds)
- System Updater: increase update check interval to 6 hours from 4 hours
- Vanadium: update to version 126.0.6478.110.0
GmsCompatConfig: update to version 119
- fix cast in GrapheneOS package management infrastructure needed for upcoming App Communication Scopes work
I don't believe they would be listing things like this. It doesn't mean they wouldn't be able to see that though. If you're using the cellular network for Internet access then they could see the connectivity check (and if you aren't using a VPN, much more like updates). You can change connections to their Google counterparts to blend in.
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm
A practical question.
Pixel 8/pro or/a
Is there any difference from Graphene's perspective that would make you suggest one over the other?
And an important question for those looking for a great camera or post-processing app. Is there any open source app you recommend?
No difference from a security/privacy perspective. The 8a has a longer support time since it released later than the 8 and 8 Pro though.
The differences between the versions mostly come down to camera, display, screen and build quality and battery size. Pro has more RAM.
The Secure Camera app built into GrapheneOS uses CameraX and has almost all features and the same camera quality. It's the only open source app we recommend. Others who don't make that choice would use the Pixel Camera for certain features.
#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
Our community members discovered it (and other leaks not mentioned) and we've been working on it since before VPN providers were aware of it. You can see from our release notes we already shipped an attempted fix for it but it caused app compatibility issues with other VPNs and had to be rolled back. Users reported many issues with their VPN apps not working afterwards.