KindnessInfinity

joined 1 year ago
MODERATOR OF
[–] [email protected] 1 points 3 days ago

I 100% agree! Thank you so much for the kind words.

 

Changes in version 149:

  • revert change in the previous release forcing GCM flags for Firebase Cloud Messaging to their default values since it wasn't necessary and may end up introducing issues so we never rolled out version 148 beyond Alpha and never bundled it in the OS
  • update max supported version of Play Store to 43.6

A full list of changes from the previous release (version 148) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.

 

Changes in version 131.0.6778.39.0:

  • update to Chromium 131.0.6778.39

A full list of changes from the previous release (version 130.0.6723.102.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

 

Our sandboxed Google Play compatibility layer is open source code shipped as part of GrapheneOS which enables optionally installing and running Google apps as regular apps in the standard app sandbox without any special access, control or privileged integration into the OS.

In order to make it easy to install sandboxed Google Play, our App Store provides mirrors of the official releases. These have through extensive testing by users either opting into the Alpha and Beta channels for those in our App Store along or Beta releases in the Play Store.

Our compatibility layer teaches Play services and the Play Store how to function as regular apps via the standard Android APIs and permissions. It's not necessary to grant any permissions to either of them in order to use them and provide compatibility with near 100% of apps.

Apps with mandatory or optional dependencies on Google Play are including Google Play libraries in their app. Many of these libraries such as Ads and Analytics work fine without Google Play services. These libraries could do everything sandboxed Google Play can do without it.

For example, Google could include fallback code in the Firebase Cloud Messaging library to support receiving push messages through a service run by the app itself. Google could also support using Play services and Play Store as sandboxed apps. We've shown it works fine that way.

It's important to understand that our approach is not granting any access to them or allowing them to do anything they couldn't do without it.

Our compatibility layer demonstrates a regulator could reasonably require Google to not use capabilities unavailable to regular apps.

Our approach also allows us to reimplement arbitrary portions of Google Play ourselves. For example, we reimplement the Play services location service by using the OS location service. By default, apps using Google Play location are redirected to standard GrapheneOS location.

We provide emulated network location support to use apps depending on network location without it. We're in the process of implementing our own network location client with support for choosing between multiple services. It's currently being tested and polished up to ship it.

Our opt-in network location that's going to be shipped soon is not tied to Google Play compatibility. It's available to any apps using the OS location API. Our default enabled redirection means that apps using Google Play location will transparently use this when it's enabled.

We'll also be providing support for using Apple's location service or a GrapheneOS proxy to it as the starting point. We're also going to be providing our own location service based on our own database built from data scraped/merged from multiple sources which is entirely legal.

Our own network location service will support downloading regional databases to use it entirely locally without sending location data to a service. We plan to provide the same features for the SUPL service used for A-GNSS which currently defaults to a GrapheneOS proxy to Google.

We're also going to be providing our own implementation of geocoding (converting addresses to location) with a choice of providers which is currently in an experimental state. We can very easily host that ourselves too. We'll be doing the same for many other things over time.

Our position is that useful features should be directly provided in the OS disconnected from Google Play compatibility. Apps using Google Play for it can be redirected to using the OS implementation instead with a toggle for it. We can also unify it with the provider toggles.

For network-based location, it's completely legal for us to scrape enormous amounts of data from publicly available services not even requiring accounts to combine into our own multi-source database. It will allow us to provide non-satellite-dependent offline location detection.

We have additional extensions beyond the baseline compatibility layer to support Android Auto. It's disabled by default, and Android Auto is a regular sandboxed app when installed. Users can choose to grant it extra USB access to use wired Android Auto. Wireless needs a lot more.

 

Punkt. MC02 phone doesn't run GrapheneOS. It still runs a fork of Android 13 while GrapheneOS is solely based on Android 15. MC02 is clearly using the LineageOS update client, not the GrapheneOS update client. It's problematic that some people think it's a way to get GrapheneOS.

MC02 appears to use an older version of our sandboxed Google Play compatibility layer, but they haven't kept up with our updates at all so they don't have the full app compatibility of GrapheneOS. We're unsure how much other code they used from GrapheneOS but it's not current.

There are many companies selling devices with GrapheneOS preinstalled. It's also very easy to install it on your own with https://grapheneos.org/install/web from a web browser on another device. MC02 isn't a way to obtain GrapheneOS preinstalled and GrapheneOS can't be installed onto it.

There's a lot of media coverage about the device including reviews where it's portrayed as running GrapheneOS. We weren't contacted by news publications about their stories/reviews. We would have been happy to correct misconceptions if we have been contacted about any of this.

 

iOS 18.1 added an implementation of the auto-reboot timer for locked devices we've been using in GrapheneOS since June 2021:

https://chaos.social/@jiska/113447894119816217

This was one of our early generation protections against forensic data extraction. We added a lot more protections this year.

iOS 18.1 was released on October 28, 2024. This has nothing to do with recent news coverage where cops are blaming imaginary features for devices not staying in After First Unlock state. Devices likely crashed due to one of many bugs which exist, including already patched ones.

The fantastical theories about iPhones communicating with each other about being kept without cellular access and rebooting based on what they were told by other phones do not check out. It doesn't make sense. Law enforcement has the capability to host properly signed cellular.

It wouldn't make sense for Apple to deploy such as strange and insecure take on it. They've deployed essentially the same feature we use in iOS 18.1, although we aren't sure when they enable it. We enable our auto-reboot feature by default with an 18h timer, which used to be 72h.

Our auto-reboot implementation builds upon our other hardening which protects the device. We use default enabled hardware-level + software-level disabling of USB-C data while locked, default enabled aggressive use of hardware memory tagging in a hardened allocator and a lot more.

Our USB-C port control feature and hardware memory tagging are examples of features built on hardware-specific features. Hardware memory tagging is near exclusive to Pixels, but the stock OS only has it as a developer option for finding bugs with a weaker implementation and bugs.

We proposed auto-reboot, USB-C port disabling, reset attack mitigation and wipe-without-reboot as features to Google in January 2024. They implemented part of our reset attack mitigation proposal for Pixels in April 2024 and wipe-without-reboot in June 2024, but not the others.

We've made a lot of proposals and vulnerability reports to help improve Pixel and Android security but they don't always listen to us. Perhaps they'll add auto-reboot now that Apple shipped something, although as we said above we don't know if it's lockdown mode exclusive, etc.

Apple and Google have much weaker forms of USB attack surface reduction than our approach. It's also not enabled by default for either. We designed the default balanced security vs. usability mode of "Charging-only while locked" to avoid disrupting almost any real world use case.

We use support in the Pixel USB-C controller for disabling new USB connections but keeping existing ones working. As soon as there are no active connections, data is disabled. People who want more security can make it stricter and even disable charging to block USB-PD exploits.

We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (https://grapheneos.org/faq#future-devices) and we expect it could be implemented for Snapdragon too but it's missing hardware memory tagging and devices using it are missing far more...

We've heard that iOS 18.1 is using a 4 day timer for auto-reboot after the device is locked, which is similar to the 72h default we used before moving to an 18h default. Our users can configure it between 10 minutes and 72 hours (or disabled) based on their tolerance for it.

When we proposed it to Google in January 2024 as a standard Android feature, we suggested starting with 1 week. Android has a lot more tolerance for adding user-facing configuration so they could expose the same functionality we do just with a less aggressive default for it.

 

Changes in version 130.0.6723.102.1:

  • backport upstream patch for spell checking related crash

A full list of changes from the previous release (version 130.0.6723.102.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

 

Tags:

  • 2024110700 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2024110400 release:

  • full 2024-11-05 security patch level
  • rebased onto AP3A.241105.007 Android Open Source Project release (November monthly release of Android 15)
  • ignore Person.Builder.setUri() when Contact Scopes is enabled since apps can't access the contact's URI with Contact Scopes enabled (this resolves the incompatibility between Contact Scopes and apps attaching contact information to notifications which was introduced by a November Android Security Bulletin patch)
  • fix "App info" uninstall dialog link added by GrapheneOS not working in some cases for secondary profile apps
  • GmsCompatConfig: update to version 147
  • Vanadium: update to version 130.0.6723.102.0
 

We're investigating a compatibility issue between WhatsApp and Contact Scopes impacting push notifications. It started in the past couple days via a WhatsApp update, Google Play update or November Android Security Bulletin patches we shipped Monday before the stock OS today.

Issue appears to be caused by one of the November 2024 Android Security Bulletin patches we shipped early on Monday interacting poorly with our Contact Scopes feature. We're working on confirming it and implementing a workaround for Contact Scopes + WhatsApp push compatibility.

A new release of Android is in the process of being published today and we'll be quickly moving to being based on it as we always do. We'll try to include a workaround for this WhatsApp issue in today's release. We can add a temporary workaround and switch to a cleaner fix later.

This issue is resolved in the latest release of GrapheneOS pushed out via Alpha and Beta last night. Has been rolling out to everyone since earlier today:

https://grapheneos.org/releases#2024110700

The security patch is strangely not in the mainline Android releases yet but we're including it.

 

Changes in version 148:

  • force GCM flags for Firebase Cloud Messaging to their default values to avoid possible issues from flags being rolled out to a small subset of users

A full list of changes from the previous release (version 147) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.

 

Changes in version 130.0.6723.102.0:

  • update to Chromium 130.0.6723.102

A full list of changes from the previous release (version 130.0.6723.86.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

 

Changes in version 147:

  • don't disable GcmFeature__use_prioritized_alarm_api flag since this isn't needed, could theoretically break FCM push and it will start applying again after GrapheneOS 2024110400
  • fix FIDO support on current Play services versions in combination with the flag fixes in GrapheneOS 2024110400
  • update max supported version of Play Store to 43.4

A full list of changes from the previous release (version 146) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.

 

This is an early November security update release based on the November 2024 security patch backports since a monthly Android Open Source Project and stock Pixel OS release hasn't been published yet.

Tags:

  • 2024110400 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, emulator, generic, other targets)

Changes since the 2024103100 release:

  • full 2024-11-01 security patch level
  • fix a bunch of upstream Android bugs breaking SMS and MMS functionality in secondary profiles, including both Android 15 regressions and pre-existing issues
  • backport upstream Android fix for UsageStatsDatabase locking from the AOSP main branch
  • Sandboxed Google Play compatibility layer: fix flag overrides being partly ignored on recent versions
  • add workaround for rare system_server null pointer exception crash in showShutdownDialog()
  • add missing null handling for extended application error report
  • fix upstream bug causing App Not Responding link to not work properly outside of Owner
  • Settings: avoid opening parent user log viewer in nested profiles (Private Space, work profile)
  • System Updater, GmsCompat: reduce included SettingsLib components to reduce the size of these apps from around 10MB each to below 4MB each
  • GmsCompatConfig: update to version 146
[–] [email protected] 2 points 3 weeks ago

You're welcome

[–] [email protected] 1 points 3 weeks ago

Yes, bank would need to add compatibility. They may follow these instructions to do so.

I'd also recommend you read this, if not already done: https://grapheneos.org/usage#banking-apps

[–] [email protected] 1 points 3 weeks ago

May you please report this issue here?

[–] [email protected] 1 points 3 weeks ago

This year was a good year! 👍

[–] [email protected] 2 points 2 months ago
[–] [email protected] 1 points 2 months ago

Whoops. It has been corrected. My apologies.

[–] [email protected] 1 points 2 months ago
[–] [email protected] 2 points 2 months ago (1 children)

General thought is that if meta was lying about E2EE, due to their massive size, it would likely be leaked to the general public that they were lying. The app also has such a large userbase of skilled security researchers that can and do reverse engineer it, so they'd also find if meta lied.

[–] [email protected] 1 points 2 months ago

What do you mean by static?

Have you read this? https://grapheneos.org/faq#vpn-support

[–] [email protected] 1 points 2 months ago

You're welcome!

[–] [email protected] 1 points 3 months ago (2 children)

Do you have "block all connections without VPN" enabled in android setting? Do you have have VPN in use for multiple profiles? Sms and voice over wi-fi are not routed through VPNs on main user profile.

view more: next ›