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.

Changes in version 126.0.6478.122.1:

• restore fully disabling the JavaScript JIT compiler by default since Chromium changed the definition of disabling the JIT compiler into only disabling the 2 higher tiers of JIT compilation without disabling baseline JIT compilation which does not avoid dynamically creating executable native code
• add support for language-specific content filters automatically enabled when the language is selected (EasyList Germany has been added to the configuration app for testing the implementation)

A full list of changes from the previous release (version 126.0.6478.122.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.

Since Android 14 QPR3 is a major release, the end-of-life Pixel 4a (5G) and Pixel 5 receiving extended support releases from GrapheneOS will need to be ported to it with additional work in a future release, which is done as a low priority. Pixel 4a (5G) and Pixel 5 are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

• 2024062700 (Pixel 5a, 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, emulator, generic, other targets)

Changes since the 2024062000 release:

• 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

Notable changes in version 2:

• handle top bar title text overflow with ellipsis instead of wrapping
• handle rename of Twitter to X and replace twitter.com with x.com
• update AndroidX Compose UI library to 1.7.0-beta04
• fixes for state restoration when resuming or changing configuration

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

Releases of the app are published in the GrapheneOS app repository. You can use the GrapheneOS app repository client on Android 12 or later for automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel.

Wise has quietly started allowing people to add our EUR account and send us money again.

https://grapheneos.social/deck/@GrapheneOS/112672843944152400

Issue appears to be fully resolved. Similarly to how they quietly started blocking that without any notice, it has stopped without a reply to our support request.

https://poppopret.org/2024/06/24/google-stop-burning-counterterrorism-operations/

"counterterrorism operation being conducted by a U.S.-allied Western government"

Selectively leaking info to sway public opinion is a classic move. Over 3 years after https://technologyreview.com/2021/03/26/1021318/google-security-shut-down-counter-terrorist-us-ally/, no info about which US ally or supposed terrorist group.

Here's an example of a "counterterrorism operation" by a U.S.-allied Western government targeting political opponents with NSO exploits:

https://citizenlab.ca/2022/04/catalangate-extensive-mercenary-spyware-operation-against-catalans-using-pegasus-candiru/

Is this what's being referenced? Perhaps they mean the Polish government targeting the political opposition this way.

https://theguardian.com/world/2022/feb/17/more-polish-opposition-figures-found-to-have-been-targeted-by-pegasus-spyware

Is this the "counterterrorism operation" by a U.S.-allied Western government that's being referenced? If saying the country and "terrorist" group involved paints a flattering picture of these exploit tools, why aren't they saying which ones are involved?

A more extreme example of a US ally doing a "counterterrorism operation" using NSO exploits:

https://en.wikipedia.org/wiki/Assassination_of_Jamal_Khashoggi

Sure, not a "Western government". Does "U.S.-allied Western government" include Hungary, Turkey, Israel, Japan and South Korea? "Western" meaning what exactly?

Forensic data extraction tools are similar. They use exploits to extract data from devices. Many people claim that since they're primarily used by law enforcement it means they're primarily used for good. They're widely used to target arbitrary people at protests, borders, etc.

GrapheneOS is heavily focused on defending against both remote exploitation and local data extraction. As part of that work, we recently reported 2 vulnerabilities being actively exploited by forensic companies. These are now fixed for Pixels, but not yet other Android devices.

For more information on those 2 vulnerabilities:

https://discuss.grapheneos.org/d/11860-vulnerabilities-exploited-in-the-wild-fixed-based-on-grapheneos-reportshttps://discuss.grapheneos.org/d/13494-cve-2024-32896-wipe-without-reboot-added-to-aosp-due-to-reports-by-grapheneos

For detailed info on Cellebrite's capabilities based on leaked documentation which explicitly covers GrapheneOS:

https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares

We certainly support fixing these bugs...

cross-posted from: https://lemmy.ml/post/17265164

https://grapheneos.social/@GrapheneOS/112609239806949074

We questioned why this was only listed in the Pixel Update Bulletin and they agree:

After review we agree with your assessment that this is an Android issue and as such we are working on backports to include this in a future Android Security Bulletin.

April 2024 monthly update for Pixels included a partial mitigation for this vulnerability in firmware (CVE-2024-29748).

Android 14 QPR3 released in June 2024 includes a full solution for all Android devices by implementing the wipe-without-reboot proposal we made in our report.

The issue is that in practice, only Pixels ship the monthly and quarterly updates. Other devices only ship monthly security backports, not the monthly/quarterly releases of AOSP. They were only going to get the patch when they updated to Android 15. They're now going to backport.

The other vulnerability we reported at the same time for reset attacks was assigned CVE-2024-29745 but that's a firmware/hardware issue without a software solution available so we can't get them to include it in the Android Security Bulletin unless we convince Qualcomm to fix it.

Every vulnerability in the Android Open Source Project that's deemed to be High/Critical severity is meant to be backported to yearly releases from the past 3 years (currently Android 12, 13 and 14). Low/Moderate severity vulnerabilities are NOT generally backported though.

The issue is that they're really listing patches rather than vulnerabilities. Both of the vulnerabilities we originally reported impact all Android devices, but both got Pixel specific patches in April 2024 and therefore got treated as Pixel specific vulnerabilities instead.

Since the complete solution for the device admin API is an Android Open Source Project (AOSP) patch, they're going to backport it. Since there's no way to frame the reset attack issue as an AOSP issue, there isn't a good way to get it fixed for other devices through this system.

These patched vulnerabilities and other currently unpatched vulnerabilities are being exploited by forensic tools used by states to target journalists, political opponents, activists, arbitrary people crossing borders, etc. Sure, they target lots of drug users / dealers too...

Changes in version 126.0.6478.122.0:

• update to Chromium 126.0.6478.122

A full list of changes from the previous release (version 126.0.6478.110.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.

https://grapheneos.social/@GrapheneOS/112609239806949074

We questioned why this was only listed in the Pixel Update Bulletin and they agree:

After review we agree with your assessment that this is an Android issue and as such we are working on backports to include this in a future Android Security Bulletin.

April 2024 monthly update for Pixels included a partial mitigation for this vulnerability in firmware (CVE-2024-29748).

Android 14 QPR3 released in June 2024 includes a full solution for all Android devices by implementing the wipe-without-reboot proposal we made in our report.

The issue is that in practice, only Pixels ship the monthly and quarterly updates. Other devices only ship monthly security backports, not the monthly/quarterly releases of AOSP. They were only going to get the patch when they updated to Android 15. They're now going to backport.

The other vulnerability we reported at the same time for reset attacks was assigned CVE-2024-29745 but that's a firmware/hardware issue without a software solution available so we can't get them to include it in the Android Security Bulletin unless we convince Qualcomm to fix it.

Every vulnerability in the Android Open Source Project that's deemed to be High/Critical severity is meant to be backported to yearly releases from the past 3 years (currently Android 12, 13 and 14). Low/Moderate severity vulnerabilities are NOT generally backported though.

The issue is that they're really listing patches rather than vulnerabilities. Both of the vulnerabilities we originally reported impact all Android devices, but both got Pixel specific patches in April 2024 and therefore got treated as Pixel specific vulnerabilities instead.

Since the complete solution for the device admin API is an Android Open Source Project (AOSP) patch, they're going to backport it. Since there's no way to frame the reset attack issue as an AOSP issue, there isn't a good way to get it fixed for other devices through this system.

These patched vulnerabilities and other currently unpatched vulnerabilities are being exploited by forensic tools used by states to target journalists, political opponents, activists, arbitrary people crossing borders, etc. Sure, they target lots of drug users / dealers too...

Wise silently disabled adding our EUR account as a contact on Wise, blocking people from transferring us money on the platform. They're stonewalling us about it. We've received 3 donations via EUR today, so transfers from other banks to our Wise account are still working fine...

Wise's initial response was they're unable to talk to us about it for security/regulatory reasons and needed to talk to the people trying to send us money instead. Fine, but they stonewalled each of those people and said they couldn't say anything for security/regulatory reasons.

Wise won't tell us which of our accounts has disabled functionality or which functionality has been disabled. It only appears to impact receiving EUR via Wise, not sending it and not other currencies. We likely triggered a false positive and they simply default to stonewalling.

Our experience with financial services is that the only way to solve the problems is to post on social media about it, get significant traction and eventually someone who works with the company prods them internally to get it sorted out, which ends up being a quick/simple fix.

Appears to be a Wise software bug causing our EUR account to show up as deleted to other Wise users, but it otherwise works for receiving from external banks and sending money. Wise's support staff simply appear to badly trained and stonewall referring to irrelevant AML policy.

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.

Changes in version 120:

• update max supported version of Play Store to 41.5

A full list of changes from the previous release (version 119) 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.

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...