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.
1) memory not wiped when booting firmware-based fastboot mode, allowing exploiting it to get previous OS memory 2) AOSP device admin API depends on reboot-to-recovery to wipe before Android 14 QPR3
Neither is issue is being fixed outside Pixels yet.
Our 2024052100 release backported the upstream wipe-without-reboot feature being shipped in the June 2024 release of Android (Android 14 QPR3): https://grapheneos.org/releases#2024052100.
CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader. Full solution is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP.
This is being widely incorrectly reported in tech news coverage. Pixel Update Bulletins are almost entirely patches for vulnerabilities which apply to other devices too. Android Security Bulletins are the list of what other OEMs are required to fix, not the full list of patches.
CVE-2024-32896 and CVE-2024-29748 refer to the same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.
CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3. It's not at all Pixel specific.
CVE-2024-32896 which is marked as being actively exploited in the wild in the June 2024 Pixel Update Bulletin is the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:
XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.
Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.
Google has awarded bounties of $5000, $3000 and $250 for our 3 vulnerability reports related to physical data extraction attack vectors. Both $5000 and $3000 issues are being exploited in the wild. $250 bounty is for a minor issue we found while doing general USB hardening work.
@forteller Fairphone 5 is not open hardware. It's a proprietary smartphone with a completely proprietary SoC and other components. Wi-Fi, Bluetooth, cellular, touchscreen, battery, SSD, memory and everything else it uses is proprietary. It's not clear where you got the idea that it's open hardware. Many people are also under the misconception that the Librem and Pinephone devices are open hardware when they are not.
Fairphones are blatantly insecure and don't meet many of our requirements.
@paolo@ilumium It always uses multiple Google services whether or not microG is used. See https://eylenburg.github.io/android_comparison.htm which covers some but not all of the non-microG Google connections. They integrate microG with privileged access and that makes connections to Google too, and unfortunately without preserving important standard security checks for those.
This really doesn't matter compared to the disaster of having such incomplete and significantly delayed privacy/security patches and other issues.
An anonymous person donated 39 ETH to GrapheneOS on February 12th. Value of ~$59k at the time and now almost $65k.
Currently, all the developers we pay to work on GrapheneOS are directly funded with cryptocurrency donations. This donation will let us hire another full time dev.