Our post links to their official information rather than providing our own interpretation of what happened. We first saw it yesterday when people began asking how we'll avoid this. We explained how we handle signing keys, why we do it that way and future improvements we have planned in this area.
There aren't concrete plans for it yet but we want to have more tablets. We thought there was going to be a new Pixel Tablet but they cancelled multiple generations of successors to it.
It wasn't something people were widely talking about 3 months ago and no one had mentioned it to us so we weren't aware of it. We posted about it after multiple people asked us about it. Our thread links to their official website page and wiki docs on it with us only commenting on what we're doing.
Yesterday was the first time we've seen this ourselves. People were asking us about how we avoid this and we've provided our answer. We haven't even commented beyond explaining what we do to avoid a similar situation. We linked to their official site and wiki docs which say it's partially solved.
Vanadium version 146.0.7680.65.0 released:
github.com/GrapheneOS/V...
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
discuss.grapheneos.org/d/32825-vana...
#GrapheneOS #privacy #security
Supporting budget devices requires the improvements to work their way down to the lower end devices. Pixel 8a is definitely a budget device which we already support. It's 2 generations old and still has over 5 years of support due to launching with 7 years. It still meets our current standards.
We have a formal partnership with Motorola. A subset of future Motorola devices will meet all our requirements and provide official GrapheneOS support which they'll be helping us implement and maintain instead of us having to do a huge amount of additional work. It will start with flagships.
GrapheneOS version 2026030500 released:
grapheneos.org/releases#202...
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
discuss.grapheneos.org/d/32816-grap...
#GrapheneOS #privacy #security
It's future devices meeting our requirements which will be supported, not past devices or the ones being launched this year.
We don't have faith in any available commercial HSM products being more secure than keeping keys encrypted at rest on the primary local build machine. Instead, we're planning to develop software for using the secure element on GrapheneOS phones as an HSM for signing our releases.
Our roadmap for improving security of verifying updates is based on taking advantage of the reproducible builds. We plan to have multiple official build locations and a configurable signoff verification system in the update clients also usable with third party signoff providers.
The official microG OS project (lineage.microg.org) leaked their private keys for logging into their servers and signing releases:
github.com/lineageos4mi...
We make our official builds on local machines. Our signing machine's keys aren't ever on any storage unencrypted.
We can support both fold and flip devices. We already support all 3 generations of folding Pixels.
The initially supported Motorola devices will be 2027 flagships. Their 2026 flagships are the Motorola Signature (2026), Motorola razr fold (2026) and Motorola razr ultra (2026).
It will be for future Motorola devices in 2027 and later, not the 2026 models. It was possible the 2026 models would provide what we needed but it wasn't quite there yet and it will take time to develop support for it anyway.
bsky.app/profile/grap...
Don't have an answer to that yet but we'd like it if they sold devices with it. Google's restrictions are the issue with that.
GrapheneOS version 2026030200 released:
grapheneos.org/releases#202...
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
discuss.grapheneos.org/d/32708-grap...
#GrapheneOS #privacy #security
These server sponsorships are saving a significant amount of money which can go to hiring more developers instead. There are a bunch other offers we need to filter down to the ones which are a good fit and follow those up. Unfortunately we need to avoid France for the time being.
Mullvad will be sponsoring 2 servers for us from DataPacket where DataPacket will bill them for our account under their existing arrangement. We haven't deployed those yet since the locations and specs are more flexible and we want to follow up more less flexible offers first.
We're in the process of getting a sponsored server in Frankfurt from a non-profit with 10G DTAG transit, 10G vodafone and 10G DE-CIX ports in addition to the other transit. DTAG transit is very unique and will be very helpful for serving updates to users in Germany at peak times.
We're waiting to see what else we're able to get because Mullvad's offer is very flexible.
Both network-based location and geocoding are opt-in for GrapheneOS. However, we recently added network-based location to our setup wizard to improve discoverability and are going to be adding geocoding there too once we're self-hosting it. OSM server rate limiting was an issue.
For network-based location, enabling "Wi-Fi scanning" is recommended since otherwise it has to fall back to only using cell towers when Wi-Fi is disabled and can't function if cellular is disabled. Wi-Fi scanning changes the meaning of the Wi-Fi toggle to allow scans when off.
Our added "Network location" setting provides a choice between using the GrapheneOS proxy to Apple, Apple or Apple China. We're going to build our own cell tower and Wi-Fi location databases to provide our own non-proxy network location option including full offline support.
We provide our own implementation of both network-based location and geocoding in GrapheneOS. Network-based location is implemented with on-device positioning but still depends on a service to obtain location data for nearby networks. We're going to be self-hosting both services.
You can try out our new self-hosted geocoding server at ams.nominatim.grapheneos.org/ui/search.html. In addition to OpenStreetMaps data, we've imported the primary/secondary Wikipedia importance data, US/UK postcodes, US house data and OSM special phrases. It should be close to the OSM service now.
We provide geocoding as an opt-in service with a choice between our proxy to the OpenStreetMaps Nominatim server (recommended) or directly using their service. Our proxy will soon be pointed at the server from Cherry Servers and then replaced with a new multi-server GeoDNS setup.
Geocoding means converting the description of a location such as an address or the name of a place to coordinates. It supports many different kinds of searches such as finding a pharmacy or park within a certain zone. There's also reverse search to convert coordinates to names.
Cherry Servers also provided a 2nd sponsored server in Amsterdam for us to use as our first geocoding server via Nominatim. Nominatim is very demanding and calls for at least around 128GB of memory and 4TB fast NVMe storage. The initial data import for Nominatim took almost 2 days.
We're also going to be using a subset of these as additional ns2 anycast DNS locations. We already use the Xenyth server as 1 of our 9 ns2 locations and plan to use the Zare server for it soon too. This depends on BGP support including BGP communities for traffic engineering.
