Update: Still not received majority of the sats (50k). The withdrawal has been pending on stacker news for 4 days. I've been able to send batches of 3k no problem. I'm likely going to assume those sats are lost after a week and only withdraw in smaller amounts.
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.
Worth noting FlorisBoard *does* get updates now but they only just started to. They are missing swipe typing and word suggestions and plan to reimplement. If it's not an issue to you then it's still a very good choice.
That OpenBoard fork has more and is maintained more often.
Personally I use the official Google keyboard and disable the internet access with the Network permission, but those two keyboards both are excellent.
I've heard of MoneroSigner but it's far from complete or ready for public use yet.
Also heard stories of some users using two GrapheneOS devices, one meant to be offline and one online for handling XMR to replace a hardware wallet. I mean I don't see why not... but the cost can be pretty heavy. Trezor Safe 3 would involve far less cost for a similar experience.
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.
Have you tried FlorisBoard or the maintained fork of OpenBoard? They are well received among users.
In addition, #Vanadium version 120.6099.230.0 is now available. This release adds the upstream fixes of 4 (3 high) CVEs, one allegedly being exploited in the wild.
Here is information by Google on these vulnerabilities for the Desktop equivalents:
https://chromereleases.googleblog.com/2024/01/stable-channel-update-for-desktop_16.html
As noted in the article, many of the Chromium security bugs are detected thanks to a variety of security technologies like Control Flow Integrity. While CFI is not enabled on almost all platforms, Vanadium enables it. In addition, Vanadium remains one of the only actively maintained browsers inheriting this feature on Android.
While the details of these CVEs are not entirely public yet, the fact they effect V8 could indicate a vulnerability incorporating JIT. Vanadium disabling this by default would have made their users already unaffected by this vulnerability if this turns out to be the case.
#GrapheneOS
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
AOSP maintain their apps in regards to security issues or bugs.
Even Messages, which they say isn't actively supported and may be removed:
https://android.googlesource.com/platform/packages/apps/Messaging/+log
The features, however, are lacking - they mainly serve as reference implementations with just the core features. This is a big reason why GrapheneOS maintains forks or replaces the apps entirely (like the Camera). It would be best to replace more in the future.
Android Police have now made following corrections to the article regarding these two claims.
That's a great addition, however they do not support withdrawing beyond lightning addresses yet and the SN address is the only one I have. I prefer wallets that are non-custodial like Phoenix, Strike appears well received but I try to avoid custodial. I also separate funds to other wallets for real life etc.
I'll need to set up an address with an own domain in my own time, and favourably also my own node. Hopefully I can do that sometime this year.
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.
https://www.androidpolice.com/new-exploit-shows-google-pixels-auto-reboot-option/
By the way, serious error:
"The company plans to introduce more features that make physical exploits like this harder, such as blocking new USB peripherals while the device is locked."
Correction: GrapheneOS is not a company, we are a nonprofit. Blocking USB peripherals is already a feature.
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.
https://www.androidpolice.com/new-exploit-shows-google-pixels-auto-reboot-option/
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.
#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
#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
We have posted some clarifications regarding the BleepingComputer article on Twitter in response to some Android security experts who have criticisms on how the article is read out. The reporting is not as accurate as it should be. While the article is positive there are still some mistakes.
The mitigation the project is suggesting is a reset attack protection where memory is zeroed to help prevent ramdumps from being taken advantage of in these scenarios. The article suggests the positive use of a auto reboot function, however it reads out like it is our solution to the exploit -- it is not. This is not a primary mitigation, rather a simple countermeasure.
Twitter: https://x.com/GrapheneOS/status/1746585083279028276?s=20
Nitter: https://nitter.cz/GrapheneOS/status/1746585083279028276?s=20
Hell ya. Hey - if im running graphene on a pixel 4a, do i need to stop delaying and upgrade asap ? 🤙
We strongly suggest upgrading to a new device as they become unsupported. This is because you can't get firmware upgrades by the OEM and therefore miss patches. We keep devices supported until the next OS version for harm reduction so users have time and comfort intended to upgrade. Pixel 6a is the cheapest supported option, but Pixel 8 and above have the best security thanks to hardware memory tagging support.
In the case of the recent exploit, this exploited firmware. Even if the OS provided a countermeasure - it would never be fixed on the firmware side for an older device. These companies also trivially talk about breaking into these older, unsupported devices easily. Even if a fix came for a 4a, you have no guarantee for the next.
If for whatever reason you can't upgrade device, DivestOS is a good choice for that once GrapheneOS stops updating.