Yes, the project affirms these statements.
Aeroplane modes are designed to turn off the cellular radio - they are a benefit for avoiding communication with the cellular network, however, you can still do network connections in other ways such as WiFi even with Aeroplane mode on.
You shouldn't just rely on a single option. It's up to the user to connect to networks that they trust, the services they trust and use features GrapheneOS already provides in regards to that.
GrapheneOS provides features to disable Wi-Fi and Bluetooth to after a set time of no connections, disabling new USB accessories when locked, and more. The OS reduces attack surface in several components.
If a user needed to use the cellular network, there is also an LTE only mode to reduce attack surface by not using legacy 2G/3G code and bleeding edge 5G code.
That and not every foundation member, developer, moderator is versed in services like Nostr or technologies like Bitcoin, Monero etc. It's up to their preferences and range of expertise.
The project uses cryptocurrencies internally to move funds and most of the projects paid developers are paid with Bitcoin, however.
I'd likely wouldn't put my hopes up, sorry. Most we'll probably get is single moderators.
With how user authentication on Nostr works it wouldn't be feasible for a Foundation account since they would need to share keys between other developers who comment on socials, and of course that would be a terrible idea. Yes we could use the NIP-05 to verify, but that still wouldn't move all interactions to new keys.
There also isn't much of a way to keep the Nostr nsec keys cold while keeping usability to allow posting regularly at the moment. I've seen nostr signing devices but I'd like to see support and security of them expand first - I would adopt one individually if that was the case instead of using a dedicated GrapheneOS profile.
Security is a massive requirement for anything the Foundation does, which is also why Lightning donations haven't been fully adopted yet. I personally choose to offramp almost all the Lightning payments myself to the foundation wallet, while keeping a small amount.
It should be worth noting however, that the automatic reboot is not the fix for these vulnerabilities we are suggesting. We suggested a reset attack protection mechanism by forcing RAM to be cleared after an unsafe reboot or during Fastboot.
The article could have put more focus into that component, but this publicity is good publicity.
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.
Enjoy your time on the bright side! âĄ
Are you using the stock AOSP keyboard? Hold the Enter key and swipe up to the emoji icon and you should have an Emoji menu. You are free to use a different keyboard app too.
What's the purpose of the auto-reboot feature? Is there a blog post about it? Thanks for all you do!
Automatic reboot is used to restart the device after a user-determined period of time where the device is inactive.
When a device (and user profile) have been unlocked once by the user, sensitive derived encryption keys run within memory to allow the disk encryption/decryption while in use. People determine this state as After First Unlock (AFU) while a state where the device has not been unlocked at all as Before First Unlock (BFU). These descriptions are common amongst exploit developers and forensics analysts. Automatic reboot is an overall security improvement but for most people they use it as an anti-forensics feature.
When a device or profile is in a BFU state - the attack surface is much less, there is no keys in memory, less OS components are running, the device runs in a limited state among many other details. For an exploit to work against a BFU device they'd need an extremely sophisticated and unlikely to be performed attack, an example being to brute force the device's PIN would involve exploiting the tamper-resistant secure element before even attempting the brute force process.
The recent affair involving the project discovering exploits used by forensic companies is directly related to this. The exploit involved bypassing protections in Fastboot firmware to perform a RAM dump after an unsafe reboot, allowing a company to brute force the encryption keys from that dump without any throttling, completely avoiding the secure element's protections. This attack is only possible in AFU. Many forensics companies rely on phones being AFU to extract data, although some companies may be able to get data BFU depending on device manufacturer, OS version and many other circumstances.
We always had the autoreboot, but for the current affair - it was decided to reduce the timer from 72 hours to 18.
If a user sets automatic reboot to a time low enough that suits them, they can keep the phone at the most secure state when they aren't around it but need to keep it on. This does come with the cost of notifications for apps, except for alarms and default calls and texts (providing you don't use a SIM pin). Manually restarting and powering off in sticky situations is always the best choice though.
GrapheneOS also takes additional steps in User Profile improvements, as user profiles run with their own separate encryption keys, and can be purged from memory at any time with the End Session button unlike the Owner profile, which needs a device power off or restart. This is why users of GrapheneOS working in high security setups make the owner profile empty and just manage everything in separated profiles, as if someone breaches the Owner profile, they can't breach the other users if they haven't been unlocked once or had their session ended.
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
Thank you, nostr:npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c !
It will be good to interact with users on #nostr and help grow project support through other channels.
Please let me know if you have any questions ð
#GrapheneOS
GM!
Thank you to everyone for the support (likes, zaps, follows etc.), it really means a lot! Seeing interactions from developers of #security and #privacy technologies is a massive bonus.
This is a personal account so I will not always be discussing GrapheneOS, but I will be working the best I can with you all.
Users of open projects and software like #nostr , cryptocurrencies and other privacy and security projects make up some of the most loyal users of #GrapheneOS and support of the project (such as social media growth, content creation and donations) helps to keep project development stable and add improvements at a faster rate by having funds for developers. It will be great to interact with other users and assist with questions and answers.
GrapheneOS' objective is to have the best mobile security and privacy operating system with #Android app compatibility. Examples of this work is adding leading hardening and privacy features that haven't yet been implemented by OEMs (like integration of MTE, additional app permission controls, hardened kernel and memory allocator) and designing features that come with lack of utility or the sacrifice of your security. We avoid security theater.
Likewise, the project's developments have helped open source software in various ways, such as some of the work being moved upstream to projects like AOSP or to related operating systems like DivestOS, or in disclosing security issues to OEMs. We hope users of outside #nostr continue their overwhelming support where GrapheneOS has helped you, the same way our various software projects helps others.
Ah, I was late! Luckily you got it working now. Enjoy working with #GrapheneOS!
Click the settings icon in the top left of your navigation bar in Vanadium while on the site to enable JavaScript JIT. This should allow for the Mutiny Wallet app to work.
Mutiny Wallet uses WebAssembly which requires the enabling of Just-in-time (JIT) compilation of JavaScript in Vanadium. This feature is typically disabled for security by default but you can turn it on per-site if it requires it.
Denizens of Nostr, please give a warm welcome to a fellow GrapheneOS Community Team member:
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm
Give them all your GMs GNs and PVs ðĪŠ
Thank you, nostr:npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c !
It will be good to interact with users on #nostr and help grow project support through other channels.
Please let me know if you have any questions ð
#GrapheneOS