<unnamed>

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qz9thwden5te0wfjkccte9ekk7um5wgh8qatzy4vwt2

Publishing to

relay.ditto.pub

relay.mostr.pub

Last Notes

2026-03-06 22:40:08 CET

Vanadium version 146.0.7680.65.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/146.0.7680.65.0
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:
https://discuss.grapheneos.org/d/32825-vanadium-version-14607680650-released
#GrapheneOS #privacy #security #browser

2026-03-05 18:52:30 CET

- reply

@nprofile…43nz It has to start with those because they'll be the first meeting our update and security feature requirements. Lower end devices can gradually be supported as the improved updates and security features trickle down to those.

2026-03-05 15:50:46 CET

quasselkopf.de is a single user Mastodon where the sole user is heavily using an LLM to generate posts. They're using AI generated concern trolling to annoy and harass people.
Here's an example of them bothering someone else with AI generated replies:
https://quasselkopf.de/@kranzkrone/116176600327746998
Here's where they began doing it towards us:
https://quasselkopf.de/@kranzkrone/116176504616907351
We posted a constructive reply with useful information so they doubled down on trolling. We called it out and got targeted with abuse.
#fediblock

2026-03-05 13:24:55 CET

- reply

@nprofile…2ert No, only future devices meeting our update and security requirements will be supported. It will start with their next generation of flagship devices and then trickle down as the lower end devices improve to meet the requirements. The initial support will likely be for the 2027 equivalents of the Motorola Signature (2026), Motorola razr fold (2026) and Motorola razr ultra (2026).

2026-03-05 13:22:08 CET

- reply

@nprofile…07gq Those hardware details aren't up to us but for future devices we could gain more influence. It's still going to be unlikely we could get them to make such a substantial change with major tradeoffs for their regular devices. It's more realistic to be able to get more hardware security features added to future versions of the devices after the initial 2027 generation. It can keep getting better with time.

2026-03-05 03:11:08 CET

- reply

@nprofile…2ert No, only future devices meeting our security requirements starting with ones launching in 2027.

2026-03-04 16:45:51 CET

- reply

@nprofile…lqhl Pixel Camera supports RAW DNG and has more aggressive HDR+ for the regular photo mode. The main benefit would be that it has a stabilization UI to help with Night mode by having you hold the camera more steady but it works around the camera moving around regardless. We plan to add support for RAW DNG and various other features but it hasn't been one of our priorities partly since Pixel Camera can be used by people who want it to get the best that's available.

2026-03-04 16:43:50 CET

- reply

@nprofile…lqhl Don't generally recommend using wait for focus lock. You should just take a bunch of pictures instead. In practice, the use highest photo resolution toggle won't make a difference on Pixels yet since they always output images based on pixel binning even when asking for the full image sensor resolution. It would only make a difference when heavily zooming into the image or heavily cropping it but it would be nice if they added the necessary support to the camera hardware/HAL stack.

2026-03-04 08:36:35 CET

- reply

@nprofile…xpz3 @nprofile…0qar AOSP has support for flip and fold devices. We only need to do a small amount of special work for the Fold variants of Pixels.

2026-03-04 08:21:40 CET

- reply

@nprofile…0qar What do you think about the moto razr ultra? We can realistically support their 2027 flip device.

2026-03-04 08:20:40 CET

- reply

@nprofile…lqhl It has Night mode if you want to capture a lot more data in a way that looks as if it was brighter out than it actually was. You can also use Pixel Camera on GrapheneOS too which has extra features especially on Pro devices. Don't have particular recommendations beyond that.

2026-03-04 08:19:09 CET

- reply

@nprofile…n0uw @nprofile…wgun We're making the operating system, not them. We aren't concerned about whatever they decide to do in their own OS where they want to integrate GrapheneOS features.

2026-03-04 04:17:23 CET

- reply

@nprofile…n0uw @nprofile…wgun There's no reason GrapheneOS for Motorola devices would be less open source than GrapheneOS for Pixels especially with the direction Pixels have headed away from gradually open sourcing more and more of the firmware and userspace driver support to providing increasingly less of it to where it's becoming the same as supporting non-Pixel devices without OEM help. Pixels will be way harder to support than the planned devices.

2026-03-04 04:16:04 CET

- reply

@nprofile…n0uw @nprofile…wgun It has been a goal for a long time to get OEMs on board implementing the requirements for GrapheneOS, helping us with support for their devices and ideally making substantial contributions to GrapheneOS. Finally having this isn't a change in direction but rather the existing direction achieving something we've worked towards for a long time. If you want to keep using Pixels then you can keep using Pixels.

2026-03-04 04:14:33 CET

- reply

@nprofile…n0uw @nprofile…wgun It's not in any way an exclusive partnership and support for Pixels is continuing. Why is it a problem for us to support more devices? Motorola is actively working on improving their updates and security to meet our requirements. They'll be doing a lot of the work to support GrapheneOS. GrapheneOS can support more devices in the future based on it as a blueprint.
GrapheneOS will remain a non-profit open source project.

2026-03-04 04:00:31 CET

- reply

@nprofile…k3ke @nprofile…ytq5 @nprofile…n0m3 @[email protected] See https://grapheneos.org/faq#future-devices for our list of requirements. Cellular modem isolation has been present on even the first device we supported (Nexus 5). It predates having proper isolation for Wi-Fi / Bluetooth.

2026-03-04 01:23:54 CET

- reply

@nprofile…wgun The initial supported Motorola devices will be flagships. Expect those to be more expensive to start rather than cheaper. Longer and more frequent updates along with better hardware security features will need to trickle down to the more budget devices before we can support those too. We do fully intend to support non-flagship devices but the flagships are going to be the first meeting our requirements. Qualcomm segments security features and non-Pixel OEMs give flagships better updates.

2026-03-04 01:22:20 CET

- reply

@nprofile…wgun Pixel 8a meets all of our current generation security standards and still has over 5 years of updates remaining. A used Pixel 8a is currently one of the best budget options. Since the devices have 7 years of support from launch, very low end budget devices aren't really necessary to have competitively priced options since the 'a' series budget devices will age into those price tiers with more support remaining than new devices in those price tiers never getting proper updates from day one.

2026-03-03 23:57:12 CET

- reply

@nprofile…apuj The initially supported ones will be expensive flagships but we do want to have budget devices eventually. It's harder to meet our update and security feature requirements for those. Look at the Motorola Signature (2026), Motorola razr ultra (2026) and Motorola razr fold (2026) for an idea of how the next gen devices will likely be. These current gen ones are way closer to our requirements than previous devices but not quite there yet.

2026-03-03 21:59:30 CET

- reply

@nprofile…9hy3 Fixed it to stop listing March 2026 patches as being from the security preview now. They're in the regular release now. They didn't push tags yet so we just used the finalized signed security preview release which is the same thing.

2026-03-03 21:58:49 CET

- reply

@nprofile…9hy3 Fixed it saying the March 2026 patches are from the security preview now.

2026-03-03 21:49:55 CET

GrapheneOS version 2026030200 released:
https://grapheneos.org/releases#2026030200
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/32708-grapheneos-version-2026030200-released
#GrapheneOS #privacy #security

2026-03-03 21:49:48 CET

- reply

@nprofile…urxz The Location permission is disabled by default for all user installed apps including sandboxed Google Play. Sandboxed Google Play has no special access or privileges and can't access location unless you explicitly grant the Location permissions to it.

2026-03-03 20:47:31 CET

- reply

@nprofile…pv0f It will heavily prefer Wi-Fi over cellular data unless it detects the Wi-Fi network is unreliable via either the Wi-Fi hardware's information on the connection or the OS connectivity checks. If the Wi-Fi network is blocking or otherwise breaking connectivity checks then it's not going to use it and will tell the user it lacks reliable connectivity. You don't need a toggle to make Wi-Fi preferred over cellular and turning off cellular is different than not letting apps use data.

2026-03-03 20:11:18 CET

- reply

@nprofile…ayew The UI and application layer which is largely closed source is in fact a huge portion of what they've made and is not the only part of SailfishOS which is closed source.

2026-03-03 20:10:36 CET

- reply

@nprofile…ayew No, not many companies based in Europe directly partnered with the Russia government starting after they invaded Ukraine. That's not business as usual, that's directly working with authoritarians. No amount of your lies about when the partnership and ownership ended or the extent of it is going to successfully cover it up. Jolla is run by people not aligned with individual rights and certainly not aligned with the well being of the EU. Their marketing is as hollow as their values.

2026-03-03 20:06:00 CET

- reply

@nprofile…ayew
> And they wanted to get out of Russia before 2022 invasion.
Jolla began their close partnership with Russia AFTER they invaded Crimea and the Donbass, not prior to it. The entire partnership which contrary to your claims lasted long after 2021 took place after the invasion and many sanctions were placed on Russia.
You're posting a bunch of misrepresentations and outright lies about their close partnership with Russia to downplay their ownership of the company and involvement in it.

2026-03-03 20:02:36 CET

- reply

@nprofile…ayew They didn't choose the licensing for the portions of SailfishOS not developed by them. They didn't make the Linux kernel or choose the GPLv2 license it uses. For the majority of what they've developed themselves rather than taken from others, the code is closed source. The project itself is largely closed source. you're trying to present it as if code they took from elsewhere should be credited to them while meanwhile the portions they actually made which is mainly the UI are closed.

2026-03-03 20:00:25 CET

- reply

@nprofile…ayew Nothing we posted about is a lie. It's you who is desperately trying to spin the fact that the folks at Jolla lack basic human decency and integrity. Jolla's team members and community regularly demonstrate the same thing with their relentless attacks on our team with fabrications and harassment. On the SailfishOS forum, their community freely posts Kiwi Farms harassment content and Jolla stands behind it. All you achieve by continuing to lie about us is we'll make a top level thread.

2026-03-03 19:59:32 CET

- reply

@nprofile…ayew Nothing we posted about is a lie. It's you who is desperately trying to spin the fact that the folks at Jolla lack basic human decency and integrity. Jolla's team members and community regularly demonstrate the same thing with their relentless attacks on our team with fabrications and harassment. On the SailfishOS forum, their community freely posts Kiwi Farms harassment content and Jolla stands behind it. They'll do anything to get rich whether it's supporting Kiwi Farms or Putin.

2026-03-03 19:57:21 CET

- reply

@nprofile…ayew Jolla began closely partnering with Russia in 2015, a year after their invasion of Crimea. They were fully aware they were partnering with an authoritarian regime engaging in assassinations, invasions and ethnic cleansing. Jolla demonstrated their values with this partnership and they're absolutely not people who believe in personal freedoms, privacy or who have any backbone to stand up to authoritarianism. They chose that partnership and chose to be largely owned by Russia.

2026-03-03 18:55:54 CET

- reply

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.

2026-03-03 18:47:50 CET

- reply

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.

2026-03-03 18:42:02 CET

- reply

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.

2026-03-03 18:23:08 CET

- reply

@nprofile…9la2 Wi-Fi scanning toggle has no impact on whether Wi-Fi scans can be done when Wi-Fi is enabled, only whether Wi-Fi being disabled prevents doing scans. An app with the Location permission granted by the user can do Wi-Fi scans, but it can't do that while Wi-Fi is actually off since it would be unavailable. Wi-Fi scanning just changes the meaning of Wi-Fi being off to meaning it won't use any of the functionality for associating with networks but can still support scans.

2026-03-03 18:21:18 CET

- reply

@nprofile…9la2 Apps require the Location permission to perform Wi-Fi scans so disabling the global Location toggle will avoid Wi-Fi scans. Apps including our Network Location app cannot perform Wi-Fi scans if Location is toggled off globally or if they don't have the Location permission in the first place. Network Location also won't be actively doing anything if Location is disabled since there won't be requests to it.
Wi-Fi scanning toggle only determines if Wi-Fi being off prevents scanning.

2026-03-03 18:18:35 CET

- reply

@nprofile…fc97 Yes, but unlike Organic Maps or CoMaps most apps implement this via the OS service which is a free version of Google's geocoding service on Google Mobile Services devices. On GrapheneOS, that's unavailable until users opt-in to it by choosing between the GrapheneOS proxy to OpenStreetMaps or OpenStreetMaps. Our self-hosted server will replace our proxy entirely since the proxy is pointless if we're self-hosting it and avoids the problematic OSM rate limiting impacting it.

2026-03-03 18:15:36 CET

- reply

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.

2026-03-03 18:15:30 CET

- reply

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.

2026-03-03 18:15:26 CET

- reply

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.

2026-03-03 18:15:17 CET

- reply

Settings > Location > Location services provides these settings.
Our added "Geocoder" setting provides a choice of using the GrapheneOS proxy or directly using the OpenStreetMaps service. It will soon change to choosing between our self-hosted service and the OpenStreetMaps one.

2026-03-03 18:04:58 CET

- reply

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.

2026-03-03 18:00:09 CET

- reply

@nprofile…fc97 The search bar at https://www.openstreetmap.org/ is based on Nominatim and is the same software and data we're now self-hosting for use in GrapheneOS. In Settings > Location > Location services we added entries for Network location and Geocoder to opt into our implementations of those. Both network location and geocoding are currently provided via a choice of using our proxy or using the service the proxy uses directly but we're going to be self-hosting implementations of both.

2026-03-03 17:58:02 CET

- reply

@nprofile…fc97 Yes, the forward search portion is equivalent to search in Google Maps. The majority of Android apps using geocoding are using the OS geocoding service because Google provides a free implementation on Google Mobile Services devices. Geocoding is normally offered as a very expensive metered service meaning paying for each request. Google's pricing for the regular service starts out around $5 per 1k requests and gradually drops as the volume goes up. Most apps will use what we ship.

2026-03-03 17:35:11 CET

- reply

@nprofile…3y5u Each of the sponsored servers comes from a reputable server provider but that's not critical because they're not trusted due to cryptographic verification of updates with downgrade protection. We care a lot about providing high reliability and a good user experience which necessitates having control over the servers to properly monitor how well they're working and investigate issues reported by users such as poor connectivity from a certain region or ISP. It's quite important for updates.

2026-03-03 17:33:12 CET

- reply

@nprofile…d5ey The cost for the update servers is currently $0 due the server sponsorships. It would be around $3000/month if we had to pay for it ourselves. Torrents would add a huge amount of attack surface compared to a simple TLSv1.3 HTTP/1.1 download. The updates are cryptographically verified with downgrade protection so the security considerations are mostly low attack surface, signature verification and verified boot as a 2nd layer.

2026-03-03 17:30:32 CET

- reply

@nprofile…3y5u No, that's not how updates work for either the OS or apps. The servers aren't trusted by either System Updater or App Store.
OS updates, APKs and APEXes are cryptographically signed and verified with downgrade protection based on a timestamp within the signed packages. There's also an additional layer of signing and downgrade protection for the OS and APEXes via verified boot which GrapheneOS also extends to system APKs.
Traditional distros use largely sketchy third party mirrors.

2026-03-03 17:27:08 CET

- reply

You can try out our new self-hosted geocoding server at https://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.

2026-03-03 17:27:03 CET

- reply

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.

2026-03-03 17:26:58 CET

- reply

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.

2026-03-03 17:26:52 CET

- reply

Cherry Servers also provided a 2nd sponsor 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.

2026-03-03 17:26:39 CET

- reply

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.

2026-03-03 17:26:21 CET

- reply

In addition to the primary purpose of updates, we use these servers as a subset of our 11 locations for website/network services.
We moved our mail server to a system container on the Xenyth server where we're using our own AS and IP space via BGP to avoid spam filtering issues.

2026-03-03 16:54:19 CET

- reply

We have a full list of our public-facing servers at https://grapheneos.org/articles/grapheneos-servers including details on the sponsored servers with links to the websites of the sponsors. All the update servers are sponsored since paying for the amount of traffic we'll be using would be very expensive.

2026-03-03 16:45:49 CET

- reply

We now have a total of 5 sponsored update servers:
20Gbps from Cherry Servers in Amsterdam
10Gbps from Zare in London
10Gbps from Xenyth in Toronto
10Gbps from ReliableSite in Miami
10Gbps from ReliableSite in Los Angeles
Cherry Servers also provided a 2nd server for geocoding.

2026-03-03 16:44:14 CET

We recently asked for additional sponsored 10Gbps dedicated servers in Europe. We received over a dozen offers and are still looking into and following those up. So far, we've received a 10Gbps update server from Zare in London and a 20Gbps one in Amsterdam from Cherry Servers.

2026-03-03 14:41:14 CET

- reply

@nprofile…30n5 @nprofile…mcmj A large portion of the GrapheneOS hardening is device specific and having device specific builds is inherently more secure due to lower attack surface and being able to specialize the builds with features like RANDSTRUCT for each device model. Aside from that, most of their devices aren't going to be able to meet our requirements. It will initially be several flagships meeting our requirements and then more over time.

2026-03-03 14:27:00 CET

- reply

@nprofile…5pms Do you mean a flip style folding device? We already support the Pixel 10 Pro Fold, Pixel 9 Pro Fold and the original Pixel Fold. We plan to start with a regular flagship Motorola device and we can also support both their flip and folding flagships too. Lower end devices meeting the requirements is what's more difficult to get done.

2026-03-03 14:25:12 CET

- reply

@nprofile…2gay SoC licensing is very expensive especially for the latest and greatest. No one really wants to use a flagship SoC in anything but a flagship device.

2026-03-03 14:12:30 CET

- reply

@nprofile…2gay We're not going to lower our standards to expand device support so if they can't or won't meet the requirements then there's not much to talk about. That's why most of the smaller OEMs are ruled out because they can't afford or are at least unwilling to invest in the required security including long term updates and a high end SoC. The device itself doesn't have to be high end as a whole but the SoC needs to be high end to get long term support and the current era security features.

2026-03-03 14:11:09 CET

- reply

@nprofile…2gay Our partnership is Motorola is not exclusive and we're fully allowed to partner with other OEMs. However, we don't currently have the resources to partner with additional OEMs and it will likely be a while before we do.
Partnerning to make smartphones with a company which recently discontinued their smartphones doesn't sound workable. The point is also mainly getting an OEM to raise their security to meet our requirements rather than getting an OEM to sell devices with GrapheneOS.

2026-03-03 01:02:04 CET

- reply

@nprofile…crz0 It's a device management feature for enterprise devices for their own operating system. It isn't relevant to GrapheneOS unless they want to support device management for GrapheneOS itself via apps people can install for it and that wouldn't be bundled with GrapheneOS but rather something people would need to set up. We plan to make an open source device management system for enterprise use so it likely makes sense to do our own thing. The 3 things aren't connected.

2026-03-02 22:49:43 CET

- reply

@nprofile…q49y Pixel 8 and later have 7 years of support from launch. There are already great budget devices for GrapheneOS via used Pixel 8a and used Pixel 9a devices. Pixel 10a is about to launch and 10th gen flagships have been out for a while so there are good deals for those but plenty of support left. The concept of budget devices isn't really necessary if enough people keep moving to new devices and putting their old ones on the market as used devices in good condition. Battery replacements help.

2026-03-02 22:47:54 CET

- reply

@nprofile…q49y Snapdragon 8 Elite Gen 5 is currently the only SoC meeting our security requirements on paper and would need a LOT of work to meet them in practice. It has MTE support on paper but that's different from it being properly integrated and all the issues with it for broad usage in the kernel and userspace resolved.
MediaTek doesn't have everything we need and also has a very poor track record on security compared to Qualcomm. It wouldn't really be usable any time soon for GrapheneOS devices.

2026-03-02 22:40:28 CET

- reply

@nprofile…q49y 7 years of support enables used devices to act as great budget devices with far better support and security than actual budget devices. That's what's already happening with Pixels where the Pixel 8 and later have 7 years of support. Pixel 8a and Pixel 9a are past gen budget Pixels so there are great deals but there's plenty of support remaining. People who can't afford the devices new can get the same devices after a few years with plenty of support left. It sidesteps a lot of issues.

2026-03-02 22:38:08 CET

- reply

@nprofile…q49y They'll be flagship Snapdragon devices. Look at the Motorola Signature (2026), Motorola razr fold (2026) and Motorola razr ultra (2026) for examples of the current generation devices which don't quite meet our requirements yet but are very close. They moved to providing some level of updates for 7 years for these. The next gen will be better and meet all our requirements. One of those requirements is getting everything we need to match or exceed Pixel updates for drivers/firmware, etc.

2026-03-02 22:36:16 CET

- reply

@nprofile…x43n We could eventually have other OEM partnerships as there's nothing exclusive about it but they have the huge advantage of being first. No other major Android OEM has gotten in touch with us and we're going to have our hands full with this for a while now. The reason for them wanting to have more secure devices with far better updates and GrapheneOS support is to make money. It's quite straightforward and everyone benefits. Showing how viable it is will get more OEM interest in GrapheneOS.

2026-03-02 22:35:53 CET

- reply

@nprofile…x43n We could eventually have other OEM partnerships as there's nothing exclusive about it but they have the huge advantage of being first. No other major Android OEM has gotten in touch with us and we're going to have our hands full with this for a while now. The reason for them wanting to have more secure devices with far better updates and GrapheneOS support is to make money. It's quite straightforward and everyone benefits. Proving it's good business will get interest from more OEMs too.

2026-03-02 22:32:48 CET

- reply

@nprofile…x43n It's a non-exclusive partnership and we're going to continue supporting Pixels. It's going to result in us getting early access to code which will substantially help us beyond this. They're going to be doing a lot of the work on supporting the devices so it's going to be far easier than if we did it all ourselves. We negotiated a good agreement where we both benefit a lot from it. They're going to sell a lot of devices because of having GrapheneOS support and won't be losing anything.

2026-03-02 21:23:56 CET

- reply

@nprofile…398a We no longer care much about getting improvements upstream or broadly adopted outside GrapheneOS. We'd happily start using GPLv2 for more code. We're not going to include GPLv3 code in the OS itself though. We have no problem with GPLv3 code in apps we can include in our app repository but packaging a bunch of stuff is not a focus and we prefer having a separate project handle most of it right now.
What is the problem with us choosing the licenses which are the best fit for us?

2026-03-02 21:22:23 CET

- reply

@nprofile…398a
> The problem is grapheneos is militantly anti-copyleft
We're hardly anti-copyleft but rather mostly choose to use permissive licensing for our projects. We've chosen to use GPLv2 with certain required additional permissions (similar to the Linux kernel) for Vanadium to protect it against something which was happening. We mostly use permissive licensing since we wanted our security improvements to make their way upstream and to be broadly adopted. We care a lot less about it now.

2026-03-02 20:44:28 CET

- reply

@nprofile…8pz0 You seem to be missing that the reason we need a partnership is because there isn't a single non-Pixel OEM providing what we need on their own which we could simply use without collaboration as we do with Pixels. We need them to work with us and give us what we need to provide the level of updates and security GrapheneOS is expected to provide. We can't support their devices without this because we need more than what's available without a partnership. That's the whole point.

2026-03-02 20:43:26 CET

- reply

@nprofile…8pz0 No, that's not how it's going to be at all. GrapheneOS is going to have our own updates and we won't have to depend on the stock OS updates being released. We already provide security updates months before Pixels. You know we already had all of the March 2026 updates for a while before today's release, right? We have a lot of the June 2026 and later patches already. We're shipping them way earlier than anyone else and will continue it. We'll ship Qualcomm, etc. stuff on time.

2026-03-02 20:41:52 CET

- reply

@nprofile…8pz0 It's not the very low end devices with low quality components, low build quality and short support time which are relevant to us at this time. Those are too far from meeting our requirements. It's a partnership which will be initially focused on the devices comparable to the flagship Pixels. Once the better security and updates trickle down to lower end devices we can begin supporting those but we won't start doing it until it does. If people go with budget they know it's worse.

2026-03-02 20:39:43 CET

- reply

@nprofile…8pz0 Subreddits where people go to complain and obtain help with problems are filled with that. Pixel subreddit is filled with it and it doesn't mean they're bad devices or that people have significantly more problems with them than other devices. You can't compare it to somewhere like the Apple subreddit where it's heavily downvoted or even not allowed. It's not a meaningful way to obtain information about it. Pixels/iPhones also don't have the very low end budget devices...

2026-03-02 20:39:16 CET

- reply

2026-03-02 20:36:33 CET

- reply

@nprofile…8pz0 Motorola Signature (2026) is one rank ahead of the Pixel 10 Pro XL in https://www.dxomark.com/smartphones/ and has far better CPU and GPU performance via the 1 step from highest end Qualcomm SoC. The future devices we end up supporting have a high chance of using the highest end Qualcomm SoC.
It's not their ultra low-end budget devices which are being worked on. Their high end flagships for 2026 are close to meeting our requirements but not quite there yet so the next gen is what's relevant.

2026-03-02 20:31:17 CET

- reply

@nprofile…8pz0 Motorola's high end phones are well received including having top tier CPU, GPU and camera performance. They already started providing lengthy support and the GrapheneOS support will have better updates than the stock Pixel OS similarly to what we already provide for Pixels. The whole point of the partnership is that no existing non-Pixel devices meet our requirements and an OEM needs to work with us to improve their devices to meet all of our standards for us to support them.

2026-03-02 20:27:54 CET

- reply

@nprofile…6kdq @nprofile…qjgw You can see we're talking about Motorola Mobility from the linked page. Motorola Mobility was purchased by Google and then sold to Lenovo which is a Chinese company. Motorola Mobility is still largely based in the US. They moved to using Lenovo's semi-in-house manufacturing as part of them integrating it rather than fully outsourcing it to a separate Chinese manufacturer as Apple and Google do with Foxconn.

2026-03-02 20:20:06 CET

- reply

@nprofile…m0rx Motorola Mobility, which was split off in 2011 then bought by Google in 2012 and then sold to Lenovo in 2014.

2026-03-02 18:41:31 CET

- reply

@nprofile…n0m3 That's about mobile device management software, not anything in GrapheneOS or relevant to it. It isn't relevant to the hardware, kernel, drivers or firmware. It's just an MDM app.

2026-03-02 18:39:04 CET

- reply

@nprofile…gxu3 There are essentially no European manufacturers. Their phones are white labelled Chinese ODM devices where they have little input into it. That stops them from meeting our requirements in practice unless the ODM happens to meet all of them on their own since the OEMs selling those devices don't get much input into the low-level development. They're stuck using the platforms which are available with surface level changes such as choosing a display and the enclosure design.

2026-03-02 17:02:27 CET

- reply

@nprofile…mr97 2027

2026-03-02 17:01:59 CET

- reply

@nprofile…s862 @nprofile…mcmj Probably not initially but eventually there should be cheaper options.

2026-03-02 16:59:50 CET

- reply

@nprofile…dk5w Their past and current generation (2026) devices won't be supported. It will be the next generation launching in 2027. You can look at the current Motorola Signature, Motorola razr fold and Motorola razr ultra for a basic idea of what the initially supported devices will resemble. Those 3 devices are close to meeting our requirements but weren't quite there yet and more time is needed. Perhaps if we started 6 months earlier.

2026-03-02 16:54:27 CET

- reply

@nprofile…erlv That's unrelated.

2026-03-02 15:04:10 CET

- reply

@nprofile…skpy It will be 2027 so you might still want to buy an older Pixel to use GrapheneOS in the meantime.

2026-03-02 15:02:41 CET

- reply

@nprofile…tg4z We plan to support the Pixel 10a (we ordered one) and future Pixels.

2026-03-02 15:02:05 CET

- reply

@nprofile…f62e We knew you weren't saying that but that's the answer we have for people who are.

2026-03-02 15:01:37 CET

- reply

@nprofile…cwqv You'll need a new device since their current devices and upcoming 2026 devices don't meet our requirements. It will be 2027.

2026-03-02 14:22:22 CET

- reply

@nprofile…e0ps 2027 if you're waiting for this.

2026-03-02 14:18:32 CET

- reply

@nprofile…zr8z GrapheneOS is based on the Android Open Source Project which doesn't have Google apps and doesn't use their regular services. It only uses Google as a provider for very basic standard services which we replaced in GrapheneOS.
The purpose of GrapheneOS isn't specifically avoiding Google apps and services but rather providing a high level of privacy and security in general. Using Pixels is not in any way counter to our goals. We want official OEM support, lower level hardening, etc. though.

2026-03-02 14:16:14 CET

- reply

@nprofile…f62e We'll continue to have Pixels as an option.

2026-03-02 14:13:30 CET

- reply

@nprofile…2d2w The analytics feature is for their mobile device management system and their own operating system, not GrapheneOS. GrapheneOS is a separate thing from their operating system. They're both adding official support for GrapheneOS and using a small subset of GrapheneOS features to improve their own operating system. They could add support to GrapheneOS to their MDM but that wouldn't involve us adding any invasive integration for it in GrapheneOS. We wouldn't do something like that.

2026-03-02 14:12:16 CET

@nprofile…27z3 That's about their mobile device management system and their own operating system, not GrapheneOS. GrapheneOS is a separate thing from their operating system. They're both adding official support for GrapheneOS and using a small subset of GrapheneOS features to improve their own operating system. They could add support to GrapheneOS to their MDM but that wouldn't involve us adding any invasive integration for it in GrapheneOS. We wouldn't do something like that.

2026-03-02 14:08:28 CET

- reply

2026-03-02 14:06:47 CET

- reply

@nprofile…6n7u It will start with flagship devices but their flagships tend to be priced cheaper than flagship Pixels. More devices will be supported over time. It should be expected it will start with only flagships though. Look at the Motorola Signature (2026) and Motorola Razr Fold (2026) for an idea of the kind of future devices it would start out supporting.

2026-03-02 14:04:49 CET

- reply

@nprofile…2d2w Devices with official GrapheneOS support will be available to individuals. Look at the Motorola Signature (2026) which was close to meeting our requirements but not quite there yet. Motorola Razr Fold (2026) is another example. It has to be 2027 because not everything was ready yet and a lot of work is needed on support for GrapheneOS too.

2026-03-02 14:02:05 CET

- reply

@nprofile…7860 @nprofile…82zk Motorola Signature (2026) already has a 7 year update commitment but doesn't quite meet our requirements yet. The future devices with GrapheneOS support will be even better than the improvements they already made for their 2026 flagships.

2026-03-02 14:01:50 CET

- reply

@nprofile…7860 @nprofile…82zk Motorola Signature (2026) already has a 7 year update commitment but doesn't quite meet our requirements yet. The future devices will be even better than the improvements they already made for their 2026 flagships.