While the rest of the sats from the past week are still remaining to be sent to me, I've sent an equivalent donation of everyone's sats in fiat so everyone knows where the money goes. Thank you so much for supporting #GrapheneOS! https://image.nostr.build/710f864af681f1d541da3aa73cb7c61975b7863d9b64e277608110ca28d42967.jpg#m=image%2Fjpeg&dim=1022x1280&alt=A+screenshot+of+a+wire+transfer+of+%C2%A325+GBP+to+the+GrapheneOS+Foundation&blurhash=_NS6SsfQ%7EXofE0j%5Bs%3BWUfQt7j%5BRjj%5BWB-qayE0j%5B-qfQRj%25MfQM%7BfQs%3Bj%5BayInfQ%253j%5BM%7BayofWBayoMj%5BWUayof-%3Bj%5BIUfQofayofjuj%5BR%25ayofj%5Bs%3Bt7j%5BWBayjuj%5BRj&x=806c29e522864e531066d2e372056811102f5e868e3013f2907bef2989a917f2

Have you ever wondered why #GrapheneOS has a separate PDF viewer? Well that answer is pretty obvious, it is more secure to have a separate hardened, sandboxed utility designed for that instead of sharing such a responsibility with a much larger app with greater attack surface like a web browser or office suite. It is trivial for some threat actors to deliver weaponized, malicious PDF files to their targets. If we know all of this, the next step for some may be to wonder "Why is the GrapheneOS PDF viewer secure?", for you, I will explain some of the most important details: The GrapheneOS PDF Viewer app requires absolutely no user-facing permissions to run, it doesn't ask for any, nor does it need them. Without permissions the app is completely contained in the Android app sandbox and the security access model is far greater. How the viewer opens a file is through making a false request to Localhost from the WebView and then intercepting that request with a stream of the PDF data. The benefits to this include: 1. We don't needing files access in the WebView (both setAllowFileAccess and setAllowContentAccess are set to false). 2. Allowing us to intercept headers into the request like CSP, Permissions Policy for hardening the sandboxing done via the WebView With CSP, all dynamic and inline CSS and JS is disabled. The only scripts loaded are those used for the viewer itself. 3. In addition to using WebView for PDF Viewer, Vanadium takes the place for the WebView on GrapheneOS, meaning GrapheneOS users take advantage of the exploit protections used in Vanadium. Even with all of this, the PDF Viewer still has a fair amount of room for improvement when it comes to quality of life features and usability enhancements.

GM! I thought I sent a post about this last night. I don't see it so I guess I did not. I'd love to see wallet app developers focus on more external signing device support for their apps. Especially Monero, but BTC a little too. It is almost an injustice the only thing close on GrapheneOS is Monerujo and Ledger support. This is just my opinion of course. Trezor Safe 3 has far greater physical attack resistance with a secure element now and should be the device for Monero users. Trezor Safe 3 + #XMR + #GrapheneOS would be a changer for hardline Monero users (many of which support the project - so thank you!) If there are apps that support this, please let me know because I'm eager to try.

GM! #GrapheneOS version 2024011600 is out now! This is mostly quality of life improvements. See the changes: - Work around upstream Android bug causing system_server crash due to failed security-related assertion by denying the action without crashing system_server, which avoids turning a buggy security check into a denial of service issue - Add workaround for upstream Android crash reporting bug recording clean f2fs filesystem check results as errors which is resulting in many users receiving filesystem check error reports on GrapheneOS due to our user-facing notifications for serious errors/crashes - Add workaround for upstream Android crash reporting bug causing old crashes to be reported again -Add workaround for upstream Android crash reporting bug wrongly attributing certain app crashes to system_server - only show kernel crashes when the user opts into system crash notifications since there are many false positives caused by hardware issues such as some users having devices which sometimes fail to resume from sleep while idle - only show report button in log viewer for system_server Java/native crashes, MTE crashes and filesystem check errors (which now have non-error results properly filtered out) due to receiving too many reports about upstream bugs and hardware issues - hide specific system apps and also sandboxed Google Play from Aurora Store so users don't try to update them through it and receive errors - Log Viewer: explicitly set status bar color to fix light mode icon colors

Releases | GrapheneOS

GM Just want to personally thank again to all the users who have zapped sats to my posts here and/or on stacker news. While this is a personal account I understand most of my following is relating to GrapheneOS, therefore I will be sure to offramp almost all the sats to the GrapheneOS Foundation Bitcoin address because of that. They will have more uses for it than I would. My stacker news sats withdrawal have been stuck on pending for almost two days, I am still yet to access most of the funds. I've found making smaller batches of transactions more reliable, which I keep in my Phoenix wallet. I will make sure to send the sats, or equivalent, to the foundation. For the sats I will keep such as ones earned on other posts or on SN, they will be used to create content and send to others. I've stacked enough sats to purchase a domain name, though not sure what to go with. I strongly support the value for value model of these platforms, so I also want to give back in value beyond sats such as with online content. Once again, thank you! ⚡

More #GrapheneOS coverage, this time by Android Police. GrapheneOS appreciates the very positive feedback with the discovery of vulnerabilities. However, the same unfocus with what the mitigations the GOS team suggested from other articles are present here. Automatic reboots do not entirely fix this vulnerability, rather it is a part (of many) countermeasures against threat actors who'd want to take advantage of it. While a safe power off or reboot caused by our auto-reboot feature does make a scenario where taking advantage of this impossible (by means of making the device BFU), that weakness would always still be present. If a threat actor timed to attack the device when the reboot hasn't happened then there is still window of attack. Security researchers who have read these articles have already noted criticisms and holes in relying only on automatic reboots (as we have) and have been reading the article believing this is our approach when that is not entirely true. GrapheneOS doesn't rely just on this single feature, we have several. Proper reset attack protections, an example such as preventing sensitive data in memory being used by zeroing them and patching up the problems with unsafe reboots would fix this. This is what GrapheneOS suggested to Google. Any suggestions that this feature is the entire proposed solution is incorrect and the project cares deeply about real security enhancements that eliminate entire vulnerability groups and capabilities of active threats in the operating system. There is no utility to just defeating vulnerabilities one by one. Computer and data security requires cooperation by sharing information to the community, and it's very important that said community have the most accurate and reliable information about modern threats and how to defeat them.

Android Police

This new exploit shows why Google Pixels need an auto-reboot option

Schedule reboots for your phone in the name of security if possible, says GrapheneOS

If you are big into password management apps like #KeePass then you can take full advantage of the security of the database by configuring your key derivation settings. KeePass 2.x supports databases encrypted with AES and ChaCha20 and key derivation with AES-KDF or Argon2. Argon2 is designed to be especially resistant to brute forcing which makes it tougher on ASICs, GPUs and memory when performing the derivation. This means to get a similar amount of speed of attempts in a second they would need to have far more expensive resources in comparison to other functions. Argon2d and Argon2id are options in KeePassDX, but Argon2id is generally recommended. In #KeePassDX you can go to Settings -> Security -> Key derivation function to use Argon2 in your database. A good configuration is the default. However if you want to be overkill, then you could make the effort to make it take about 1 second or more to save the database or unlock it. It's up to you to configure these values and go up slowly. Try to keep memory and parallelism around the same as the defaults. Sadly KeePassDX doesn't have an option to calculate how many iterations it can perform in a second unlike the original KeePass2 on Windows or other apps. In my example my Pixel 6a uses 80 transformation rounds, 32MiB memory and 4 threads parallelism. https://image.nostr.build/b2423ce9016b0c00218a4a2c8f22d3c3eed92dd4b3bb58c75e8b196cbe7988b3.jpg#m=image%2Fjpeg&dim=1080x1149&blurhash=%7B34ef%40%25M9FM%7BIUM%7BRjs%3A%7EWt7D%25V%40WBWBRjfkt8jZRjfkt7j%5BWVbHIUt7xuRjj%5BWBjYoL4noK%25Ma%7Dt7WVa%7DWV9FWBxuoft7j%5BofaeIUR*ofofofoft6jZt7RPV%40t7ayt7oza%7DxuRjWBs%3ARjt7ofjZ&x=a70e6f2192b07569e92fc2f43995f406ad0c7356bd490f0341d3fc8f0bcb32e8 https://image.nostr.build/b9a477fe9fbdabd2b0618e1ed58e1746023d1bc2b895974a0be23153afd8422a.jpg#m=image%2Fjpeg&dim=1080x1411&blurhash=_24B%3F%5E_4t7IUITIUIU%25NRjRjWBoft7j%5BxvRjayofkCj%5BWB.8ofRPM%7Bfkt7of%25MWBRjRjoft7j%5BtRayjsayaea%7Dj%5Bt7ayayayfkj%5Ba%7Dxuxut7fkRjRjRjjZs%3At7j%5DWBWBay&x=3b4e9220e0a23ec90a6832d4bfcc9ce2ed85680fd703334bdb8003b9a2a9832d

Our current affair about #GrapheneOS automatic reboot and our project's disclosed vulnerabilities on Fastboot firmware to Google has reached some media outlets. It appears BleepingComputer received a statement from Google confirming the reported issues and will be taking steps to review it. The GrapheneOS project once again is leading the forefront of mobile security research.

BleepingComputer

GrapheneOS: Frequent Android auto-reboots block firmware exploits

GrapheneOS, a privacy and security-focused Android-based operating system, has posted a series of tweets on X suggesting that Android should introd...

GM! #GrapheneOS version 2024011300 is out! With an improved autoreboot implementation and reduced autoreboot timer and the addition of Night Mode support in the Camera app for Pixel 6 and above! Full changes: - replace auto-reboot implementation with a new more hardened implementation based on a timer in the init process which also avoids rebooting when the device hasn't been unlocked since boot reduce default auto-reboot timer from 72 hours to 18 hours - add log viewer available at Settings > System > View logs to avoid needing developer options for making useful bug reports and inspecting the device for issues - reimplement our user-facing crash reporting infrastructure with our new log viewer app - Settings: add links to log viewer in app info and system settings - show report button in sandboxed Google Play crash report UI - adevtool: integrate support for Pixel Camera Services (currently provides Night mode for GrapheneOS Camera and other apps on Pixel 6 and later) - adevtool: improve and clean up infrastructure for device support - adevtool: drop devices not supported with Android 14 - adevtool: remove unused default permissions configuration - Contact Scopes: add handling of malformed contact data subtype names to avoid crash show notification after hardened_malloc detects memory corruption via a direct check (does not cover memory corruption detected via memory protected address space) - kernel: disable sysrq by default rather than waiting for init to disable it - kernel: disable unused sysrq serial support - kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision including update to 5.10.206 - kernel (Pixel 8, Pixel 8 Pro, Generic 5.15): update to latest GKI LTS branch revision including update to 5.15.145 - kernel (Generic 6.1): update to latest GKI LTS branch revision including update to 6.1.69 - GmsCompatConfig: update to version 91 - Vanadium: update to version 120.0.6099.210.0 - System Updater: use sentence case for notification channel names

Releases | GrapheneOS