This is how it looks:
New features other than upkeep won't be added to it for a while however as there will be a major rehaul for this in the future.
typst is a simpler alternative to latex and has a simple markdown-like grammar. I propose we use this in some nostr science longform spec. It’s super fast too!
One of our contributors developed a Typst-compatible text editor designed for GrapheneOS users.
You'll still have the 12 digit seed phrase that you backed up, but on the Jade it is stored encrypted after setup and can't be decrypted without the Oracle.
If that happened then you'd insert the seed phrase into the Jade manually / from the stateless mode to access your funds. You'd also need to do this after you typed the PIN wrong 3 times as it clears the Jade and the oracle data as a security measure.
I don't use Liquid and to my knowledge Trezor have zero plans to add support for it. I imagine since it's Blockstream that their own products would be the best choice for anything using Liquid.
(You can also DIY your own Trezor like Jade and SeedSigner but they'd have the same hardware security as the older models - if not less. Would be better if the Trezor ran stateless in DIY models.)
Jade doesn't have a secure element, so a second independent device is involved in decrypting the device's sensitive data to make the wallet resistant to attacks.
Connecting a Jade to a device with a companion app and typing the correct PIN will connect the device to a remote server ran by the manufacturer (called a Blind Oracle) which then sends back a decryption key to decrypt the Jade and make it useable.
The seed phrase in the Jade is stored on the flash storage, but it is encrypted with a key split between the Jade and oracle. The PIN is used and set up during the key exchange with Oracle and you can't test that it's a correct PIN without connecting to the oracle.
Not really a fan of the "virtual secure element" naming but that's my opinion. It essentially makes the device secure by not having the device keep any unencrypted sensitive data such as keys in the same device. Some might say it's jumping hoops, but it works and also keeps the device cheap.
For higher threat models the Jade can run stateless, which is essentially the exact same as a SeedSigner where you scan a SeedQR or a insert a seed phrase and perform the operations. The device clears when powered down. You can also run your own oracle but I don't know much about that.
Jade and SeedSigner run on a threat model that they know their hardware isn't secure enough, so they either never store any seeds, or store them encrypted and involve a secondary source or device in the decryption or access procedure to compensate. Both of those projects depend on commercially available hardware and you can run Jade software on a M5Stack or other product. I don't see anything wrong with Jade but I prefer Trezor above them because of other features.
The big advantage Ledger had for a long time was physical attack resistance with a secure element. Trezor wallets originally didn't use them, and had vulnerability disclosures where a skilled actor could dump encrypted device PINs which could be used to brute force them.
Using an additional passphrase and (on applicable models) a microSD card as a key would mitigate this issue but both the security of the passphrase and the threat actor not having the microSD card is important to make this countermeasure effective.
Trezor didn't use them until the Safe 3 and later. Safe 3 and 5 are far more secure than their predecessors.
Also why fediverse is popular despite its huge flaws. Each instance is oriented to community.
Call your parents. Tell them that you love them. Do it now.
https://dergigi.com/2024/11/15/he-hanged-himself-in-the-morning/
My most sincere apologies from me for your horrible loss. Hoping you have been able to fully find your peace since last month and recover from your bereavement.
Acresccent alpha has added some more apps to the repo.
Some of the new open source apps includes "Inter Profile Sharing" a FOSS third-party app meant for sharing files between other user profiles, "Just Video Player" a video player app with support for tons of encoding and file types, and "FlashDim" a robust configurable flashlight app with brightness controls.
More work needs to be done with Acresscent (as it is maintained by a sole developer) before more apps can be implemented.
Rebooting the device stops non-persistent exploitation and returns the device back to a Before First Unlock (BFU) state when you are not using it.
When a device is BFU, data is encrypted at rest and most OS components are not running which reduces attack surface and increases exploitation difficulty. BFU state is particularly troublesome for physical data extraction attacks that forensics companies like Cellebrite use, as they can't extract encrypted data. When a device is unlocked once after a boot cycle then there is greater attack surface, so we suggest automatic reboots to power the device back to this state when the device is idle or when you can't access your device so it is more secure.
iOS 18.1 added an implementation of the auto-reboot timer for locked devices we've been using in #GrapheneOS since June 2021:
https://chaos.social/@jiska/113447894119816217
This was one of our early generation protections against forensic data extraction. We added a lot more protections this year.
iOS 18.1 was released on October 28, 2024. This has nothing to do with recent news coverage where cops are blaming imaginary features for devices not staying in After First Unlock state. Devices likely crashed due to one of many bugs which exist, including already patched ones.
The fantastical theories about iPhones communicating with each other about being kept without cellular access and rebooting based on what they were told by other phones do not check out. It doesn't make sense. Law enforcement have the capability to host properly signed cellular and produce cloned SIM cards that provide the same metadata but limit cellular network access.
It wouldn't make sense for Apple to deploy such as strange and insecure take on it. They've deployed essentially the same feature we use in iOS 18.1, although we aren't sure when they enable it. We enable our auto-reboot feature by default with an 18h timer, which used to be 72h.
Our auto-reboot implementation builds upon our other hardening which protects the device. We use default enabled hardware-level + software-level disabling of USB-C data while locked, default enabled aggressive use of hardware memory tagging in a hardened allocator and a lot more.
Our USB-C port control feature and hardware memory tagging are examples of features built on hardware-specific features. Hardware memory tagging is near exclusive to Pixels, but the stock OS only has it as a developer option for finding bugs with a weaker implementation and bugs.
We proposed auto-reboot, USB-C port disabling, reset attack mitigation and wipe-without-reboot as features to Google in January 2024. They implemented part of our reset attack mitigation proposal for Pixels in April 2024 and wipe-without-reboot in June 2024, but not the others.
We've made a lot of proposals and vulnerability reports to help improve Pixel and Android security but they don't always listen to us. Perhaps they'll add auto-reboot now that Apple shipped something, although as we said above we don't know if it's lockdown mode exclusive, etc.
Apple and Google have much weaker forms of USB attack surface reduction than our approach. It's also not enabled by default for either. We designed the default balanced security vs. usability mode of "Charging-only while locked" to avoid disrupting almost any real world use case.
We use support in the Pixel USB-C controller for disabling new USB connections but keeping existing ones working. As soon as there are no active connections, data is disabled. People who want more security can make it stricter and even disable charging to block USB-PD exploits.
We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (https://grapheneos.org/faq#future-devices) and we expect it could be implemented for Snapdragon too but it's missing hardware memory tagging and devices using it are missing far more...
It's been confirmed iOS 18.2's automatic reboot triggers in three days, the same as the old #GrapheneOS default. It is good to see other operating systems inherit features we'd been suggesting in the press for years.
HD Moore (founder of metasploit) posted about setting up a Shortcut in iOS to reboot automatically overnight instead and used us in a reference. Really nice to see. This shortcut method may interest some of our iOS users.
Unfortunately not. Maybe nostr:nprofile1qqsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgpzdmhxue69uhhqatjwpkx2urpvuhx2ue0mkqagk knows of something?
Not really. I wrote an article on SN but isn't really everything you're describing. Also a victim of writers remorse, a little bit cringe and I'd like to redo sometime.
The Punkt MC02 phone doesn't run GrapheneOS. It still runs a fork of Android 13 while #GrapheneOS is solely based on Android 15. MC02 is clearly using the LineageOS update client, not the GrapheneOS update client. It's problematic that some people think it's a way to get GrapheneOS.
MC02 appears to use an older version of our sandboxed Google Play compatibility layer, but they haven't kept up with our updates at all so they don't have the full app compatibility of GrapheneOS. We're unsure how much other code they used from GrapheneOS but it's not current.
There are many companies selling devices with GrapheneOS preinstalled. It's also very easy to install it on your own with https://grapheneos.org/install/web from a web browser on another device. MC02 isn't a way to obtain GrapheneOS preinstalled and GrapheneOS can't be installed onto it.
There's a lot of media coverage about the device including reviews where it's portrayed as running GrapheneOS. We weren't contacted by news publications about their stories/reviews. We would have been happy to correct misconceptions if we have been contacted about any of this.
Automatic reboot timer is counted when device is in a locked state and the timer stops when the device is unlocked again
iOS 18.1 added an implementation of the auto-reboot timer for locked devices we've been using in #GrapheneOS since June 2021:
https://chaos.social/@jiska/113447894119816217
This was one of our early generation protections against forensic data extraction. We added a lot more protections this year.
iOS 18.1 was released on October 28, 2024. This has nothing to do with recent news coverage where cops are blaming imaginary features for devices not staying in After First Unlock state. Devices likely crashed due to one of many bugs which exist, including already patched ones.
The fantastical theories about iPhones communicating with each other about being kept without cellular access and rebooting based on what they were told by other phones do not check out. It doesn't make sense. Law enforcement have the capability to host properly signed cellular and produce cloned SIM cards that provide the same metadata but limit cellular network access.
It wouldn't make sense for Apple to deploy such as strange and insecure take on it. They've deployed essentially the same feature we use in iOS 18.1, although we aren't sure when they enable it. We enable our auto-reboot feature by default with an 18h timer, which used to be 72h.
Our auto-reboot implementation builds upon our other hardening which protects the device. We use default enabled hardware-level + software-level disabling of USB-C data while locked, default enabled aggressive use of hardware memory tagging in a hardened allocator and a lot more.
Our USB-C port control feature and hardware memory tagging are examples of features built on hardware-specific features. Hardware memory tagging is near exclusive to Pixels, but the stock OS only has it as a developer option for finding bugs with a weaker implementation and bugs.
We proposed auto-reboot, USB-C port disabling, reset attack mitigation and wipe-without-reboot as features to Google in January 2024. They implemented part of our reset attack mitigation proposal for Pixels in April 2024 and wipe-without-reboot in June 2024, but not the others.
We've made a lot of proposals and vulnerability reports to help improve Pixel and Android security but they don't always listen to us. Perhaps they'll add auto-reboot now that Apple shipped something, although as we said above we don't know if it's lockdown mode exclusive, etc.
Apple and Google have much weaker forms of USB attack surface reduction than our approach. It's also not enabled by default for either. We designed the default balanced security vs. usability mode of "Charging-only while locked" to avoid disrupting almost any real world use case.
We use support in the Pixel USB-C controller for disabling new USB connections but keeping existing ones working. As soon as there are no active connections, data is disabled. People who want more security can make it stricter and even disable charging to block USB-PD exploits.
We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (https://grapheneos.org/faq#future-devices) and we expect it could be implemented for Snapdragon too but it's missing hardware memory tagging and devices using it are missing far more...
It turned out this appears to be an actual feature in the latest iOS based on reverse engineering. However, older outdated devices are rebooting as well (according to a law enforcement document) and that potentially could be caused by other factors.
Latest #GrapheneOS release fixes a contact scopes compatibility issue that breaks apps like WhatsApp caused by the latest Android security patches.
