As Freeborns OH has the issue some others may have noticed it too.
The official project response follows:
Google and carriers deployed changes to RCS which have been breaking it for many users on the stock OS including with certain carriers and in whole countries. The changes appear to have specifically impacted GrapheneOS users too. It's not related to our September 8th update. We're working on it.
You can find many recent threads about people having issues with RCS in Google Messages while using a stock OS with Google Mobile Services. There are articles about how some carriers and countries no longer have it. It still works for most people but the changes definitely regressed compatibility.
GrapheneOS users were impacted by these recent changes much more than other users. We don't know why yet but we're working on determining that and restoring compatibility with Google Messages for people who use it. We'll try to get compatibility with the new way it functions implemented very soon.
Google and carriers deployed changes to RCS which have been breaking it for many users on the stock OS including with certain carriers and in whole countries. The changes appear to have specifically impacted GrapheneOS users too. It's not related to our September 8th update. We're working on it.
You can find many recent threads about people having issues with RCS in Google Messages while using a stock OS with Google Mobile Services. There are articles about how some carriers and countries no longer have it. It still works for most people but the changes definitely regressed compatibility.
GrapheneOS users were impacted by these recent changes much more than other users. We don't know why yet but we're working on determining that and restoring compatibility with Google Messages for people who use it. We'll try to get compatibility with the new way it functions implemented very soon.
Had this asked in our testing room, so enabled it and plugged in, and it stopped at 83%. Going to leave it like this and continue over the weekend but on the very latest release I can't replicate on Pixel 8.
April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:
https://source.android.com/docs/security/bulletin/pixel/2024-04-01
https://source.android.com/docs/security/overview/acknowledgements
These are assigned CVE-2024-29745 and CVE-2024-29748.
source.android.com
Android Security Acknowledgements | Android Open Source Project
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks.
GrapheneOS already implemented defenses against this attack before we became aware of it. After becoming aware of this attack against Pixels running the stock OS, we improved our existing defenses and added new ones alongside reporting the firmware weaknesses to get those fixed.
CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app. It appears they've implemented a partial solution in firmware. See https://twitter.com/GrapheneOS/status/1772616917611585809 about ongoing work we spotted on wipe-without-reboot support.
Google is publicly working on a fix for the factory reset vulnerability we reported:
https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138
Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.
Show more
GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.
GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.
Can see the announcement of these being exploited in the wild at https://source.android.com/docs/security/bulletin/pixel/2024-04-01#Announcements.
In addition to them working on our proposal to implement wipe-without-reboot, we've spotted work on our other suggestions such as wiping key derivation results from memory after unlocking.
April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:
https://source.android.com/docs/security/bulletin/pixel/2024-04-01
https://source.android.com/docs/security/overview/acknowledgements
These are assigned CVE-2024-29745 and CVE-2024-29748.
source.android.com
Android Security Acknowledgements | Android Open Source Project
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks.
GrapheneOS already implemented defenses against this attack before we became aware of it. After becoming aware of this attack against Pixels running the stock OS, we improved our existing defenses and added new ones alongside reporting the firmware weaknesses to get those fixed.
CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app. It appears they've implemented a partial solution in firmware. See https://twitter.com/GrapheneOS/status/1772616917611585809 about ongoing work we spotted on wipe-without-reboot support.
Google is publicly working on a fix for the factory reset vulnerability we reported:
https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138
Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.
Show more
GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.
When you level up your coffee game and the homebrew matches, note for note, the experience from the roastery. βπ―π #DialedIn
UK council won't say whether two-week 'cyber incident' impacted resident data
#security #uk
https://go.theregister.com/feed/www.theregister.com/2024/03/21/shock_uk_councils_recovery_from/
Not the only sketchy thing about that council...
"i approached five Labour councillors representing the Spinney Hills and North Evington wards, where many textile factories are located, about the situation. None of them responded."
Tested and confirmed also spoke with dev team, this is upstream with AOSP unfortunately.
This popup DOES appear on GrapheneOS regardless of Play Services being installed or not. 
This and on the cutting edge, be an Alpha π
I know what you mean but you're approaching the question from the wrong perspective.
It works on any phone that supports it, just happens to be that Pixels are still the only ones that do. We're waiting and willing others to do the same. It's a damning indictment of the mobile device landscape that they haven't and don't.
GrapheneOS Current Android QPR2 Bluetooth Compatibility statement:
Due to mainline modules, the Stock Pixel OS is currently using a much older release of the Bluetooth module than the current release in the Android Open Source Project without current security patches. We believe this is the reason for remaining issues not occurring for stock.
The remaining compatibility issues with a small number of devices such as the past couple generations of Galaxy Watch hardware appear to be the consequence of the March security patches and other changes in QPR2. There's a solid chance the Bluetooth devices are what's buggy.
GrapheneOS is on Bluetooth module version 990090000 from the Android 14 QPR2 release. Stock Pixel OS is still using 341313030, without tags available for that. Needs to be addressed even if simply by tagging the older Bluetooth module release being separately built/shipped.
There was no option like that for me. Interesting. Could be diff versions floating around I suppose.
Menu>Settings>Wallet will allow you to use any NWC (Nostr Wallet Connect) enabled service (eg Alby).
Don't use their wallet so all good π
Change your Vanadium release channel to Alpha in the Apps app and ensure you are using the latest version.
Vanadium is significantly more secure. It provides strict site isolation for the sandbox and type-based control flow integrity which are not normally available for mobile Chromium. It also disables JIT compilation by default, another setting not normally available on mobile.
See https://grapheneos.org/features#vanadium.
Brave currently has a more advanced content filtering engine with broader content filters due to supporting more syntax. It also has more complete state partitioning. Vanadium will be implementing more complete state partitioning in the near future.
Android is moving towards completing one of the areas of verified boot which currently only works in GrapheneOS. They never fully adopted verifying out-of-band system APK updates with fs-verity and then disabled it. They're now moving towards using APK Signature Scheme v4.
Said raids and harassment often involves CSAM and gore. We have members of our community across the age range.
From a moderation view point and the fact the Matrix protocol suffers from state reset bugs that brick rooms, it makes perfect sense.
I would suggest reading this thread:
https://x.com/GrapheneOS/status/1397952450108313600?s=20
If you haven't got X and can't find a nitter instance still running or alternate method let me know and I'll take the time tomorrow to paste the entirety.
Yes GrapheneOS is against persistent app accessible root access. As an open source project you are free to make whatever changes you wish to implement whatever options you desire. You can make debug builds etc as suggsted in the thread to determine the level of root you might desire and the method of it's operation.
It is your device, your prerogative and power to you.
Initial build instructions can be found here:
However as a privacy and security focused OS with clearly stated scope and high standards with many high risk individuals and organisations depending on it, it would be anathema to claim to be reducing attack surface while providing easily accessable tools and methods to do the exact opposite.
Good luck in your endeavours.
Not the PWA (Progressive Web App) but the actual Android app.
Running #Primal native Android for a week. So far, so slick.
It would be really useful if there was a way to stop boosts by followers of people you already follow not appearing in the main timeline. My thumb has RSI, Repetitive Scroll Injury.
I'll pass the feedback along π
Yep thats what iv done ππΌ just thinking could impact on boarding if others have the same issue
It's available...
#m=image%2Fjpeg&dim=864x1920&alt=Aurora+Store+Play+Store+Front+End+Amethyst+Listing&blurhash=%5BG9%3F8%5Dxbs%3At61utRt8of%7C%7BofofkC7KWBj%3Fj%5B%3A%2BWBWCWVA%3DM%7BRjaerDRjV%40V%40I.V%40WBWBogNGRjoL&x=856fc1b29b5d2e8cd500ec41ea03c3b58d3907936d247cd4fa8ae1dd14f88a63
Oh look another cycled npub. Nevermind honeypot, you're a timesink. You keep using that word FORCE too so lets get all Inigo Montoya...
#m=image%2Fjpeg&dim=537x464&alt=Inigo+Montoya+Meme&blurhash=%3BVD%2BuXf69tWWw%5Ds%3ANGj%5BfkMxayf%2Bayt6WBR*jZjZ_NWVs9s.R*WXWBoLjZbvayn%24f6RjayoLayj%40xvjtxafQflfQaebHRj-%3Bf6NGayRjoLoeWVWXV%40oLt7WVofoLjsWVR*%25Mf6aeazWBj%5BayWVjt&x=3e0af40376ee9f6d391ff0da96133f2667848b6aaeed0a126d0c586287576bb7
When you have no argument you can always play "hostility" or similar card.
You're just a liar. I use to have GrapheneOS on my phone.
Users CANNOT use any other server than GrapheneOS to sync clock using WIFI or LAN.
Why are you lying?
You can read YOUR site.
"An HTTPS connection is made to https://time.grapheneos.org/generate_204 to update the time"
You have no option to choose other server.
Your lies only confirm that GrapheneOS is not reliable.
Lets quote the WHOLE thing shall we:
Β° An HTTPS connection is made to https://time.grapheneos.org/generate_204 to update the time with a millisecond precision X-Time header. As part of future support for using other services, it falls back to the standard Date header with second precision.
This is a full replacement for Android's standard network time update implementation, which uses unauthentication SNTP (Simple Network Time Protocol) with fallback to the cellular network when it's not available (GNSS can also be used as a time source but is disabled by default, and OEMs can choose the priority order). Network time updates are security sensitive since certificate validation depends on having an accurate time, but the standard NTP / SNTP protocols used across most OSes have no authentication or encryption.
We plan to offer a toggle to use the standard functionality instead of HTTPS-based time updates in order to blend in with other devices.
Network time can be disabled with the toggle at Settings β System β Date & time β Set time automatically. Unlike AOSP or the stock OS on the supported devices, GrapheneOS stops making network time connections when using network time is disabled rather than just not setting the clock based on it. The time zone is still obtained directly via the time zone provided by the mobile network (NITZ) when available which you can also disable by the "Set time zone automatically" toggle.
So as I said "Dependent on Connection" and as I said we DO NOT FORCE people to use our services. Not only can it be disabled, as I said "use either/or or NONE" we ARE going to offer the default connection.
You're a bad faith actor.