Some users seem to not know where to find it, but you can add the #GrapheneOS changelog to your feed reader:

https://grapheneos.org/releases.atom

Once there is a greater, functional Desktop Mode it will be considered even further. GrapheneOS enabled DisplayPort output for Pixel 8 when it is disabled in stock, which they'll likely enable elsewhere when a Desktop Mode is finished. Having a GrapheneOS smartphone able to work like a desktop with broad app support via VMs is a serious goal.

Having a Desktop Mode on GrapheneOS alone is a massive benefit and we hope to see it come to fruition with further Android updates.

We have repeatedly discussed our interests in an OS VM manager since 2022, but when this can be done is yet to be decided.

https://nitter.projectsegfau.lt/GrapheneOS/status/1678594436924600325#m

Backup when Nitter shits itself: https://twitter.com/GrapheneOS/status/1678594436924600325

It would also be nice to run a nested variant of GrapheneOS in a VM to isolate apps. Plus Android provides a Chromium layer-1 sandbox as an OS feature to every app via isolatedProcess services. It could be desirable to move this to per-site VM instances using microdroid. It'd be a large and difficult project but with very high impact for web browsers.

Vanadium version 121.0.6167.143.0 released: https://github.com/GrapheneOS/Vanadium/releases/tag/121.0.6167.143.0

#GrapheneOS

Nor did I until recently, big wall of discourse about issues with Nostr entirely by a few people in my feed, mostly around people having an issue with npubs on Nostr showing IPs of users in notes, comparing Nostr to other social media sites, and now people discussing the privacy of using relays and a bunch of other stuff. This post is just my take on this.

I think Nostr is too broad to compare to Twitter or the like in some regards. I didn't feel like posting thoughts in replies in many places and starting a giant thread, so I made it as a single note instead.

Leaving my small rambled thoughts on this since I am seeing this discussion everywhere:

When making a censorship-resistant public network or service the primary objective comes with the relays distributing events with the furthest outreach and as fast as it can to make censorship near-impossible. #Nostr systematically doesn't really care about privacy, and why should it? That's not always the goal...

The entire Nostr ecosystem is designed to be transparent. If you want a communication method that's opaque then you would use a private messenger instead. Using Tor or a VPN should be a given for risky people. The relays are a valid concern but even if the Nostr network or client had proxying then you are just moving the goal posts and trusting that proxy instead. Onion routing by default could help but then it becomes a scalability problem of relays vs. proxies. I really don't know how you could make a system designed for extremely public, far reaching, permanent posting private that also has a scaling as large as Nostr does.

I'm not saying clients shouldn't discuss these privacy caveats though. They should. Especially since not just relays, but other users could see IPs due to all media being hosted remotely. Events on Nostr are also all tied to a persistent, cryptographic pseudonym at the minimum.

We know realistically you can't erase posts. Erasing your own posts can be loosely defined as self-censorship, so why would you have the ability to do so easily on a censorship resistant network? Privacy isn't the objective of a public social network anyone can read. Do you expect #privacy on Twitter, a site where Internet Archive scrapes individual tweets all the time, Bing saving caches of tweets in the search results deleted or not, and where you can do advanced, fine grained searches on tweets with advanced parameters on the platform itself? Why should people expect Nostr to be private when people use it like Twitter?

For those who understand Nostr, that's fine, but there is unfortunately a portion who don't. Is there an issue with people adopting services and technologies without assessing them? I think so sometimes. Being into #Bitcoin doesn't always mean aptitude in technology (and that's fine!) but I guess I stopped being surprised that people are surprised.

Going back to the beginning, Nostr like Bitcoin is more transparent than private and has the goal of censorship resistance, not privacy and you need to use your own setup. Nostr's only objective is distributing media, privacy features is the job of apps integrating Nostr and the users of the apps and the network.

Feel free to discuss this with me. Would like to hear your thoughts.

I consider being able to make a web page something a young person should attempt to do, preferably in school. Learn the basics of HTML, CSS and you can pretty much make a small site about anything. You see a website that looks cool? The markup is your documentation. Read the HTML and look at the styles.

Teens seem to love one-page site links for their social media like Carrd, I think it would be the next level for them. It doesn't matter if it's ass to begin with, you make better pages as you keep making different sites.

After I discovered static site generation then the work flow improvements was marvelous.

Vanadium version 121.0.6167.101.2 released

See changelog:

https://github.com/GrapheneOS/Vanadium/releases/tag/121.0.6167.101.2

#GrapheneOS

Currently it's out now with the new update

Release is now in all release channels.

nostr:nevent1qqsdtfde7w0fwtgpw4xccddntx230dve8mu8cn42fd0h6gcmch2fpqqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qgsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgrqsqqqqqpcjtar4

OpenBoard fork will rename to HeliumBoard or something soon to differentiate between the two. The FlorisBoard UI is better imo but OpenBoard is more functional.

There is the OpenBoard fork:

https://github.com/Helium314/openboard

FlorisBoard hasn't had official updates in ages but beta builds are still worked on:

https://github.com/florisboard/florisboard/releases

I know there are others too. Some also use a real keyboard app and disable Network access.

There is disabling usage of mobile data while the app is in the background, if that helps:

#m=image%2Fjpeg&dim=946x1920&blurhash=%5B77UPIxtD%24aexuWCIUt7D%24j%40%25NWA4mof-%3Df6WYa%23jYof%3FdWAIUWBM_a%7ERiof9EjsxvWA9Eayxuj%40&x=d39b6485d29b99b6470a0f8d77df252e885503ce099c0e5c5daab746089c1845

GrapheneOS socials are ran by multiple people (GrapheneOS Foundation members and developers) and it's difficult to make a single project account trusting multiple users with an unchangeable private key.

A lot of developers just also are not into it, it's up to their individual preferences.

That bridge appears to be offline

It's missing a lot of posts there: https://grapheneos.social/@GrapheneOS

I have all the mastodon relays blocked so I am not sure which one works, sorry!

We aren't willing to add toggles like this because they leak via indirect access. Apps use various OS APIs which apps may then use that cannot get covered by these toggles. An example is DownloadManager:

https://developer.android.com/reference/android/app/DownloadManager

See: "Note that the application must have the Manifest.permission.INTERNET permission to use this class." - The partial toggles do not disable INTERNET permission, while the toggle GrapheneOS and the DivestOS toggle that disables all networks does. That's why DivestOS adds our toggle above the leaky per-network toggles.

If an app does one network only and then calls the OS DownloadManager which chooses to use the other networks, you have leaked traffic towards those networks in that case.

It would be a nice to have if it worked, but we're not going to be adding unreliable features any time soon. You'd be better with an Always On VPN or Tor or disabling the cellular network with Airplane Mode when not using it -- it's up to the user's choice.

Here are some further clarifications regarding the hardening and future anti-exploitation techniques from the team at #GrapheneOS:

Source: https://nitter.cz/GrapheneOS/status/1751097979866624501

"Our latest release provides another enhancement for our protection against firmware-based attacks on devices by forensics companies. We're going to be doing more similar work.

GrapheneOS has zero-on-free for the main allocator used by native code (malloc) along with the kernel page allocator and slab allocator. In particular, zeroing data in the kernel page allocator heavily limits the lifetime of data and clean reboots clear most of the OS memory.

We believe that our zero-on-free features are why forensics companies are announcing support for obtaining data in After First Unlock state for the stock OS via firmware exploits while seemingly not being able to target GrapheneOS yet, but we're rolling our more improvements.

In an earlier release this month, we replaced our auto-reboot feature with a new implementation in the init process to prevent a potential bypass through crashing core system processes. We also made it stop chain in Before First Unlock state to make low timers much more usable.

The default auto-reboot timer was reduced from our initial choice of 72 hours to 18 hours.

GrapheneOS has provided a feature for disabling USB peripherals for years. By default, we disable USB peripherals while locked. USB is very complex and has other uses than this though.

Fast charging and the low-level protocol for USB-C are extremely complex. These are largely implemented by Linux kernel drivers and the core kernel USB support along with another implementation in the non-OS firmware boot modes, not the isolated USB controller hardware/firmware. Android 12 added a device administration setting to supposedly disable USB data and a low level USB Hardware Abstraction Layer (HAL) implementation to go along with it. This does not really work as you would expect and only disables high level USB functionality like peripherals.

It also disables USB gadget support, which is already disabled by default other than device advertising itself as supporting MTP to be detected by computers by default without having MTP enabled until the user enables it. We investigated it near 12 launch but found it lacking. USB gadget support is how MTP/PTP, MIDI, tethering (Ethernet), Android 14 QPR1 webcam support and the developer options Android Debug Bridge function. By default, Android uses MTP mode with MTP disabled until user unlocks and enables it. This adds no significant attack surface.

Attack surface for low-level USB-C and charging is massive. Vulnerabilities being leveraged by forensics companies are often USB bugs. Working reset attack mitigation is barely deployed by devices meaning they can target firmware USB while device is booted into a special mode.

We proposed improvements for Pixels in Android security bug reports we filed recently. They're already working on it and we expect it will be shipped in a few months, ending the ability to get data from After First Unlock mode via special firmware modes, but not the OS itself.

To better protect the OS itself, we're working on a much lower level implementation of disabling USB support by implementing it in platform-specific drivers much lower level than the generic Linux kernel code. This will have some usability impact so it has to be a separate mode. We've also discussed the possibility of offering a toggle for disabling fast charging while locked or as a whole for further attack surface reduction. This would certainly not be enabled by default and our focus is on the always enabled or at least default enabled protections.

Our existing default-enabled USB protection disables adding new peripherals while locked. Peripherals you add while unlocked work after locking. Android's standard USB gadget control is based around approval while unlocked, which is similar. We just need to make this lower level."

Now available!

nostr:nevent1qqsdtfde7w0fwtgpw4xccddntx230dve8mu8cn42fd0h6gcmch2fpqqpz3mhxue69uhkummnw3ezummcw3ezuer9wcpzps26tfjesmn6ksf5mm36hpf9fkjut49sfeutfutvs2phrykn25v9qvzqqqqqqydsl6g3

GM! 🔥

#GrapheneOS version 2024012600 is out with several #security enhancements and improvements to eSIMs.

See the changes!

- isolate eSIM activation app from non-system apps to avoid it sharing data with sandboxed Google Play

- make eSIM activation toggle available without sandboxed Google Play installed

- make the eSIM activation app toggle persistent instead of it being disabled at boot

- remove misleading message about device info being sent to Google message before eSIM download

- hardened_malloc: use tag 0 for freed slots instead of reserving a tag to allow using 15 of 16 possible tag values for random tags (there are 3 dynamic exclusions of the random values for the previous tag along with the 2 current or previous adjacent tags)

- Settings: prevent disabling Camera2/CameraX extension provider app (Pixel Camera Services for Pixels) since it breaks apps using CameraX

- kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro): use a normal reboot on overheating instead of an emergency reboot to harden against physical attacks

- kernel: enable reset attack mitigation for UEFI systems supporting it (Tensor Pixels use minimalistic littlekernel-based boot firmware rather than UEFI and the previous Snapdragon Pixels using UEFI didn't implement this but we may need this for future devices)

- 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.208

- kernel (Pixel 8, Pixel 8 Pro, Generic 5.15): update to latest GKI LTS branch revision including update to 5.15.147

- kernel (Generic 6.1): update to latest GKI LTS branch revision including update to 6.1.73

- Launcher: disable gradient at the top of the home screen again (change lost with Android 14 QPR1 due to it being reimplemented upstream)

- rewrite HTTPS network time implementation to make it much more maintainable and robust along with providing better debug output via ADB

- Vanadium: update to version 121.0.6167.101.1

- GmsCompatConfig: update to version 93

Seedvault: update to latest revision (will be replaced with a better backup implementation in the future)

https://grapheneos.org/releases#2024012600

Next #GrapheneOS update now includes some hardening against reset attacks to prevent potential ways of bypassing our memory zeroing features.

This is a response to the exploit we previously reported to Google of forensics companies exploiting a RAM dump from fastboot firmware to brute force OS credentials in Pixels running the stock OS. While not suggested to affect GrapheneOS nor should a user be concerned, this will be an additional security enhancement for our users anyways.

Thermal reboots are unsafe reboots that don't erase memory safely. They have now been changed to perform safe shutdowns instead. It stops a threat with physical access and RAM dump capabilities from overheating the phone to force an unsafe reboot into fastboot. A reset attack protection mechanism has been enabled for supported UEFI systems. While we don't support devices using UEFI or the UEFI reset attack protection mechanism, it could come useful in later devices.

These protections will be one of multiple to kill the capability for good.

Read about the original exploit on my post on stacker news: https://stacker.news/items/385351