Security researcher focused on forensics, mobile security, and other cypherpunk grounds. Helping out at #GrapheneOS. Enjoy typos and senseless security babble. Posts made express own views and is my only npub. #privacy #security
Public Key
npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Profile Code
nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspp4mhxue69uhkummn9ekx7mqpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqm79n2l
Show more details
Published at
2025-06-03T20:58:41Z Event JSON
{
"id": "b5391ea6d2bdfd770d97b4479843b3277c89023030a381e86226d3ed9d538ed1" ,
"pubkey": "b98ded4ceaea20790dbcb3c31400692009d34c7f9927c286835a99b7481a5c22" ,
"created_at": 1748984321 ,
"kind": 0 ,
"tags": [
[
"alt",
"User profile for Final"
]
],
"content": "{\"name\":\"Final\",\"display_name\":\"Final\",\"picture\":\"https://image.nostr.build/38752e41d5c34a92bb49082d62af57bf67b6dc4ae15b2e7c53055d3084d0d914.jpg\",\"website\":\"https://discuss.grapheneos.org/u/final\",\"about\":\"Security researcher focused on forensics, mobile security, and other cypherpunk grounds. Helping out at #GrapheneOS. Enjoy typos and senseless security babble. Posts made express own views and is my only npub.\\n\\n#privacy #security\",\"nip05\":\"[email protected] \",\"lud16\":\"[email protected] \"}" ,
"sig": "2fa85d8fb886072f6d8d837ba0398018828de55ede3ff3029113333b4ed3568862185bae7bd2a4ed12cc8fbb6b75566daa048daad1869ceac5e974ca65322216"
}
Last Notes npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Our initial port to Android 16 has been completed and can be built for the emulator from our 16 branch. All of the device-independent #GrapheneOS code has been ported. There are some parts of the port which will be redone better and a lot of testing and fixing regressions to do. Normally, we would have announced the availability experimental releases based on Android 16 already. Unfortunately, Android 16 dropped device/hardware support from the Android Open Source Project and we're going to need to put it together ourselves without being prepared for it. We'll be starting from the Android 15 QPR2 device support code and stripping it down to a bare minimum. Pixel 9a is a special case and will be more work. Our hardware-based USB-C port control feature will no longer work with this approach and we need to replace half of the code. We received early notice of Android 16 removing the device support code from AOSP but were unable to confirm it or determine the details. We have existing automated tooling for this we can significantly extend to generate what we need. It will be difficult and a major regression. Paying an ODM to make a Snapdragon device for us is increasingly appealing. We would have all the device support code we need, could build it with compiler-based hardening and would be able to harden a lot of the device's firmware. We could also make secure element applets. We want to be building privacy and security features. We don't want to be wasting our efforts on adding device support and other basic functionality to AOSP. It appears the only way we're going to be able to do that is paying millions of dollars to an ODM to have a proper base. As an example of what we would be able to do even with an entirely standard reference device, we could add hardware support for our duress PIN/password feature to the secure element so that successfully exploiting the OS could not bypass it. We could do a whole lot with firmware. Pixels meeting our requirements is why many of them were and are being purchased. We've reported MANY vulnerabilities over the years which have been fixed for Android and Pixels. We've proposed hardware, firmware and many software level security enhancements they've adopted. We would prefer not having to pay millions of dollars to have a phone produced for us. It's entirely doable but we would need to repeat it every few years. We'd rather work with an OEM with aligned goals and willing to provide first class GrapheneOS support to sell more devices. Pixels have substantially benefited from meeting our requirements and having GrapheneOS available for them. We know there's a significant market for an OEM working with us to make a more secure device with hardware-based security features not available on Pixels or iPhones. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run #GrapheneOS (https://grapheneos.org/faq#future-devices) and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost. In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early. We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release. Due to AOSP no longer having device support, we need to build it ourselves. We can start from the Android 15 QPR2 device support, remove the outdated code and update the configurations. We have tooling to automate generating device support setups which will need major expansions. Since our port to Android 16 is going to be delayed by a week or more, we're in the process of backporting the Android 16 firmware/drivers released on June 10 to the previous releases. This is not something we can do in general so we still need to port to Android 16 this month. Despite our lead developer who has done 90% of the ports for several years being conscripted into an army, we were still able to complete the initial port to Android 16 in under 2 days, but without device support. Our extensive preparation in April and especially May paid off. It's important to get an experimental release out quickly to begin extensive public testing. There are usually many issues found in testing. For a yearly release, we usually get out an experimental release in a day, an Alpha channel release in 2 days and need 4-6 more releases. Google has released a statement claiming AOSP is not being discontinued. This should be taken with a grain of salt, especially considering that they made similar public statements recently followed by discontinuing significant parts of AOSP on June 10. https://x.com/seangchau/status/1933029688202703062 Google is in the process of likely having the company broken up due to losing an antitrust lawsuit from the US government and being in the process of losing several more. There's a high chance of Google losing control of Android in the next couple years. https://www.nytimes.com/2025/04/21/technology/google-search-remedies-hearing.html The leaked information we received in April 2025 indicates that the reasoning they're making substantial cuts to Android is primarily cutting costs, perhaps in anticipation of it being split from Google. The courts should investigate Google's recent changes and cuts to Android. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final We've made a lot of progress on porting to Android 16 already. If things hadn't been made harder for us, we would likely be able to publish an experimental release tomorrow and quickly get a release into the Alpha and then Beta channels to start ironing out the bugs in the port. We have early builds of #GrapheneOS based on Android 16 booting in the emulator. We would usually be working on quickly porting over device support and getting the kernels ready including doing the production kernel builds now. Unfortunately, that will be harder than usual. Our speculation about this is that a result of Google losing a US antitrust case and likely losing several more soon, they're preparing for Android and Chrome being split into separate companies. If Android gets split off, they want to retain Pixels. https://www.nytimes.com/2025/04/21/technology/google-search-remedies-hearing.html Google seems to be in the process of splitting up Android and Pixels along with moving towards treating other Android-based platforms as their competitors instead of their partners. Pixels retain first class alternate OS support with Android 16 firmware so it's not about that. #nevent1q…g5qz npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final I was aware of Frostr and intended to send it, although I don't know anything beyond the idea, zero testing. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final A lot does actually come from Fediverse, but the bridge doesn't show everything. Even in my end the threads break apart. What most people here reply to usually aren't directed towards Nostr users and is just a bridge. Nostr has always been a thought, but it's worth understanding some team members know little to nothing about it because they come from a different subject matter. At the moment some who are affiliated who are familiar have separate keys to represent independently to put the work off. At first, I don't even think it was understood that these posts were bridged from another platform - but now everyone is aware. GrapheneOS can't just "get" Nostr immediately. There is infrastructure that would need to be built to use it in a highly secure manner. Just HODLing a singular private key for a shared project account is unacceptable. It would also be limited to just posting. Rotating npubs is also something to avoid entirely. A hardware signer could fit but you also need a client supporting it and it's costly. It needs to be discussed more. Same also goes for accepting Lightning payments in general. The project would want a secure Lightning node with lnurl and BOLT12. We also need to make sure we have proper accounting for all the money the node is receiving, inbound capacity and backups. Last I remember the project couldn't figure out a good way to set up lnurl without using sketchy or excessive software. We want to set it up ourselves on top of the usual server setup we use rather than using a premade OS or container setup, and with channel backups. We'd need to set high fees for routing and figure out getting inbound capacity regularly. At the moment there's a lot of work on the table with other stuff though. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable. Android 16 launched today and porting is going to be significantly more difficult than we were expecting. We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports. Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making #GrapheneOS devices sooner than we expected. We don't understand why these changes were made and it's a major turn in the wrong direction. Google is in the process of losing multiple antitrust cases in the US. Android and Chrome being split into separate companies has been requested by the DOJ. They may be preparing for it. We're hard at work on getting the port to Android 16 done but there's a large amount of additional work we weren't expecting. It can be expected to take longer than our usual ports due to the conscription issue combined with this. It's not good, but we have to deal with it. Having our own devices meeting our hardware requirements (https://grapheneos.org/faq#future-devices) would reduce the time pressure to migrate to new releases and could be used to obtain early access ourselves. Based on talks with OEMs, paying for what we need will cost millions of dollars. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final The article is hyperbole made to advertise their so-called "secure" devices. Everything is fine. Play Integrity is something that the app developers are choosing to go out of their way to implement, not forced upon. It's a rare occurrence. As for side loading, it isn't affected and even what they are talking about appears to only have activated for apps with accessibility service permissions or similar. They're extremely dangerous permissions that allow full control of a device, and are used by malware. Most apps should not have them, and most do not install such apps anyway. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS: WebRTC is a peer-to-peer communications protocol for web sites and therefore causes numerous privacy issues through making direct connections between participants. By default our Vanadium browser disables the peer-to-peer aspect by only using server-based (proxied) connections. Vanadium provides a user-facing setting at Privacy and security > WebRTC IP handling policy. From least to most strict: Default Default public and private interfaces Default public interface only Disable non-proxied UDP For Vanadium, "Disabled non-proxied UDP" is the default. The tracking technique described at https://arstechnica.com/security/2025/06/meta-and-yandex-are-de-anonymizing-android-users-web-browsing-identifiers/ is prevented by Vanadium's default "Disabled non-proxied UDP" value. It's also prevented by "Default public interface only", which does permit peer-to-peer connections but won't try to use the loopback interface for it. We have a list of most of the features provided by Vanadium at https://grapheneos.org/features#vanadium. There are dozens of additional privacy and security features planned along with data import/export and improved support for system backups. It takes time to implement these things properly. Vanadium doesn't have billions or even millions of users which limits our ability to prevent fingerprinting. We plan to address this by launching it for use outside GrapheneOS including publishing it through the Play Store. We want to implement more of the planned features first. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Users of #Obtainium may be interested in this web site: https://www.openapk.net/ It appears to have "Add to Obtainium" buttons to add the source of the app for you. Good for searching known apps. Can be saved as a PWA. Obtainium maintainers also keep a list of app configs for more complex apps at https://apps.obtainium.imranr.dev/ A better last resort option should app stores not be sufficient. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final In a Private Space, users can create an isolated environment on their current user profile. It's treated as a separate profile. Apps in the private space show up separately to other apps and are hidden from the recents view, notifications, settings etc. They also have their own network for separate VPN, so it's like another user but not. You could put in anything that you think should be separated from everything else or requires an additional layer of protection. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Check it out https://image.nostr.build/79e7afd4cde2cb5c67ae068ee7617884ded460e212d9c329d8a7c40430694875.jpg https://image.nostr.build/4fd7d8cd5a6f17e798d3398f6958cf366ef0429a92ac6e459071f798ba6bf9dd.jpg #nevent1q…xn0d npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS version 2025051900 released. This update adds support for private spaces in secondary user profiles and the ability to install available apps to private spaces. • add NFC auto-turn-off setting to go along with the existing addition of Wi-Fi and Bluetooth auto-turn-off settings • Private Space: add new setting for disabling delayed locking of storage to make locking work like secondary user end session, similar to the toggle for disabling secondary users running in the background (standard Private Space doesn't work this way to keep fingerprint unlock available after it's locked/stopped) • Private Space: add new setting for blocking sharing the clipboard to and/or from the parent profile and other nested profiles within it • Private Space: add support for the Install available apps feature we currently enable to support installing apps available in the Owner user to secondary users • Private Space: add support for secondary users including all standard features with the exception of auto-locking support since our implementation of that is too complex/invasive to properly review and test while we're focused on Android 16 porting • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.138 • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.89 • Keyboard: move the emoji key to the left of the keyboard for the phone layout instead of putting it behind a long press or replacing the enter key with it when put into the emoji mode by apps like AOSP Messaging • Keyboard: stop replacing the emoji key with the .com key for the email and URL input types • Vanadium: update to version 136.0.7103.125.0 • add support for testing Android 16 Beta 4.1 feature flags for development builds https://grapheneos.org/releases#2025051900 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final A profile within a user with their own apps, settings and files. You can store and run certain apps in this space protected by a separate PIN or password. It is isolated from the rest of the user but you can transfer certain things through it if the user desired. https://source.android.com/docs/security/features/private-space npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Likely to be later today. Private spaces in secondary users, support for installing available apps into it automatically, setting to disable delayed locking of storage (makes locking private spaces work like 'end session') Will also have some other non private space additions. #nevent1q…qgq6 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Next #GrapheneOS update adds support for private spaces in secondary user profiles and the "Install available apps" feature for private spaces and much more. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final The more significant changes (inactivity reboot, USB controls, MTE, controlling JIT in Chrome, cellular network attack surface reduction) was already in GrapheneOS for a long time. It's still good to see the stock OS implement these features, although I wished they gave users more choice and control with it. GrapheneOS has an edge in all of these features compared to the stock OS. The inactivity reboot happens earlier by default and can be configured to happen as early as minutes. The USB control is disabled via hardware for us and you can even disable charging when booted to OS. We implement MTE in far more than just apps. You can have a LTE only option rather than just disabling 2G. The majority of the rest are Google service related and aren't in the scope for us. Users can use a Google service on GrapheneOS if they wanted. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final We did a call on the other platforms that someone who works at an Android partner could get us access to the Android 16 sources to allow us to prepare early for migration to Android 16 in June. If someone can provide that to us, the transition would be much smoother. We had relied on the lead developer who was forcibly conscripted to a military training camp to do a lot of their superhuman work. They are a huge reason why the upgrade to the latest major releases were so fast. All of this is strictly a consequence of losing them. We could move over to Android 16 but not all features would be available. For example, the 2-factor fingerprint could get dropped for the initial release and then added it back later with user configuration being preserved so it works as before. Android 16 changed lock screen code by a lot. We didn't need the access to these sources before then. GrapheneOS are willing to work as independent contractors for OEMs who provide it. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It's a known Android 15 QPR2 bug on the stock OS. Happens here too and it's looking at being resolved. Your mic isn't actually in use. https://discuss.grapheneos.org/d/21054-android-15-qpr2-android-16-beta-microphone-indicator-persistence-bug Currently fixing this wouldn't the top priority because of recent major circumstances. Team are desperate in working towards a smooth port to Android 16 (we don't have early access to the source) and general updates / security patches above all. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final I burned that npub during a device change a while ago. This is my npub. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final That page is a bridge that's reposting from the GrapheneOS Mastodon instance. Currently we don't have a foundation lightning address. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final The developer was conscripted due to where he was born and located. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS Important Statement One of our two senior developers has been forcibly detained and conscripted to participate in a war. When they first went missing, we revoked their repository access as a precaution. We soon learned their disappearance was completely unrelated to GrapheneOS. Our priority has been keeping them safe. We've used our available connections to try to keep them safe. There's no way to get them out of the conscription. However, they're an incredibly talented security researcher and engineer and it would be extraordinarily misguided to send them to front line combat. This seems to be understood now. GrapheneOS development and updates have continued and will keep going. We have substantial funds available to hire multiple experienced developers. We'll need to hire multiple experienced developers to fill their big shoes. They'll hopefully be safe and when they return we'll have a bigger team. If you're an experienced AOSP developer interested in working full time on GrapheneOS in a fully remote position, see the hiring page at: https://grapheneos.org/hiring We can pay people anywhere in the world via BTC, XMR, ETH or Wise (local bank transfers). We need people who can hit the ground running due to the current situation. Our near term focus is going to heavily shift to Android 16 porting, maintenance and continuing to do better patching than standard Android 15 QPR2. An OEM providing us early access to Android 16 sources would help a lot and we wouldn't need to slow down new feature development nearly as much. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Enabling Airplane Mode disables the cellular radio. We recommend using that, rather than this menu. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Best User Profile Setup for #GrapheneOS https://seprand.github.io/articles/best-user-profile-setup/ #nevent1q…8u9c npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Seprand - Security Privacy Android: Guides and articles by the GrapheneOS Community. https://seprand.github.io/ npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final This ^ npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Macarne (https://macarne.com/) has provided a sponsored server to replace our current EU update servers so we can handle current traffic and near future growth. Ryzen 9950X, 128GB RAM, 2x 2TB NVMe and most importantly 25Gbps bandwidth. It's greatly appreciated! We use GeoDNS and round-robin DNS to distribute load across our servers with automatic failover. Ideally, we can find a good 2nd provider willing to provide sponsored/discounted 2x 10Gbps servers to cover each coast of North America. 2x 25Gbps would be great but not needed yet. Our existing setup was 8x 2Gbps OVH VPS instances with 4 in Quebec, 2 in France and 2 in Germany. This was getting increasingly overloaded for the 4 major releases per year, and the largest one (Android 16) is coming up soon. European bandwidth usage is also around 50-60% higher. #GrapheneOS npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Wow!! npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Default option for this setting sends any network location requests through a GrapheneOS proxy. If they don't want that, they can choose to request Apple directly or not use the feature. By default all location requests are routed through GNSS. No other information is submitted beyond the BSSIDs being requested. As discussed in the above post it submits a wide range of access points rather than a small amount which should broaden out the range of the search. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Android has always taken the approach of it being developed in private and then having the full sources and commit history published for each stable release. This approach used to be the norm for open source software many years ago, but now most projects do a lot of their development in the open. Commit history being available also didn't used to be the norm many years ago but rather only tarballs for releases. It's very important for them to provide it, but it would be open source without it. They're still going to be providing it. Certain sub-projects were developed in the open as part of the public Android Open Source Project repositories in the main branch but the bulk of the work was done in private. They maintained both a public main branch and an internal development branch and had to merge back and forth between them. Recently, Google announced they'll be shifting most of the small subset of the OS developed in the AOSP main branch to being developed internally instead. The full commit history will still be available when stable releases are published as it for the majority of AOSP developed that way already. AOSP main was not where most of the OS was developed and would get most of those changes merged into it shortly after each stable release. AOSP main also doesn't correspond to Developer Preview and Beta releases, which are separate branches and what we need for porting before a Stable release. The small subset of the OS developed via AOSP main moving away from it won't have a major impact on GrapheneOS. It did not provide us with early access to the code we need for porting #GrapheneOS to an upcoming release before the day it gets released. That already required having partner access. Android is remaining open source and simply being slightly less open about the development of certain components. We won't be able to see the commits as they're made for that small subset of components anymore but rather need to wait until they publish the full commit history for stable releases. In contrast with Android, Chromium is developed almost entirely in the open and we can port and test all of our changes to the upcoming releases before there's a Stable release. This is very helpful and makes maintenance much easier for us. Doing this for Android already required partner access. We've already been in the process of figuring out how to get partner access in a way that will be reliable and long term. There was only one year where we had early access to a new major release. We haven't had it for several years and we still manage to get the yearly releases out in a couple days. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Should also have clarified that when GrapheneOS do backports for fixes in Beta Android builds, those Android beta builds are already closed source excluding GPL licensed components. We decompile the shipped code from the beta builds and port fixes ourselves. This won't change getting backports from such versions, nor would it affect us. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Our latest 2025032500 release greatly improved our built-in network-based location. It's usually better than Google's network-based location in urban areas where Apple has competitive data. Unlike Google's service, position estimation is done locally by fetching location data for nearby networks. You can enable this feature via the toggle we added at Settings > Location > Location services > Network location. You can optionally enable the standard Wi-Fi scanning toggle in the Location services menu to allow Wi-Fi scans when Wi-Fi is otherwise disabled to keep network-based location working. Our implementation is currently based entirely on Wi-Fi Access Points (APs). Location data for nearby APs is fetched in batches from either Apple's service or a GrapheneOS proxy server. We also ask the service for up to 100 nearby APs which it provides with a reasonable density over a large area. Our implementation caches location data for up to 10000 APs in an in-memory Least-Recently-Used cache with 15 minute expiry after last usage of an AP. This avoids persisting a local location history while enabling semi-offline usage. We can make these parameters user configurable in the future. Most navigation apps use the fused location service providing the best result from GNSS (GPS, Galileo, etc.) or network-based location (when it's enabled). Other apps often prefer network-based location for lower power usage and quicker results not requiring GNSS reception. Some apps can't use GNSS. Most apps on the Play Store use the Google Play services location service instead of the OS provided location service. By default, our sandboxed Google Play compatibility layer reroutes location requests from these apps to the OS location service so there's no need to give Location to Play services. Nearly all users on Google Mobile Services devices have their network-based location enabled. This means some apps assume it's always available. For improved compatibility, our default enabled rerouting emulates the presence of network location with GNSS when the OS network location service is off. In the near future, we'll be making several major improvements to our network location service including Wi-Fi RTT (Round-Trip-Time) for improved distance estimation and cell tower fallback to make it work better outside cities. There will also be a lot more efficiency and other improvements to it. Longer term, we'll be providing our own location service rather than only a proxy along with full offline support via database downloads. It already works offline for a while based on the cache. We'll be using data from Apple's service to bootstrap our service, but we'll also be using other sources. Source code is available here: https://github.com/GrapheneOS/platform_packages_apps_NetworkLocation It's new code and still being built out so it hasn't had much refactoring, optimization or tuning yet. It's a mix of Kotlin and Rust since we wrote position estimation in Rust for significantly better performance. #GrapheneOS npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final This just means we won't submit vulnerability reports or upstream fixes. We've reported many serious vulnerabilities in Android upstream and gotten them fixed, but we gradually reduced how many of the vulnerabilities we report to them after our security partner access was revoked in the past. There are a growing number of serious Android vulnerabilities currently only fixed in GrapheneOS because of them revoking our security partner access. They're hurting themselves more than they're hurting us with their approach. We can get partner access via an OEM. We successfully helped them block Magnet Forensics (Graykey) and MSAB (XRY Pro) from doing AFU exploits on Pixels in 2024 when they shipped a feature we proposed in January 2024 in April 2024. We've helped get a lot of other vulnerabilities closed since we started in 2024 along with some major privacy and security improvements landed. Contributing to AOSP has been a poor experience so them breaking that is fine. We'll focus 100% on defending our users, not Android users. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #nevent1q…l5n5 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It doesn't change much. Most of the stuff we need for porting the OS is from stuff they mostly developed in the internal branch they plan to move the remaining components to, so the main branch was largely unhelpful regardless. Too little is published ahead of time. Some stuff was developed in the open so we could backport some fixes early, but now we won't be able to although that wasn't a common thing we did often. If we had partner access through an OEM, this wouldn't matter -- but we don't. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Won''t be included now. currently breaks an upstream feature with hiding private spaces. #nevent1q…0gh2 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It's intentional that it doesn't do it all the time. It needs to charge to full capacity occasionally to allow recalibration of the feature and the battery capacity. Usually you only need to do this once or twice. When you are fully charged the phone goes into bypass charging, so the device becomes powered by the charger and it doesn't charge the battery at all. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final following on this, my comment shouldn't have meant to downplay his efforts if it ever appeared that way, he is an irreplaceable and extremely talented individual and i'm saying this personally. He has helped a lot with what people don't always see and is an amazing engineer. the vulnerability disclosures to Google being associated with him aren't frills. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Developing a highly private and secure mobile OS is the major motive, with a plus of providing security research and innovation. GrapheneOS as a project is anti-authoritarian, it's strictly focused on digital security and privacy. When it comes to security at a technical we are impartial about it. Too many people feed on conspiracies, what-if scenarios and pop culture to advertise security. I'm unwilling to do that. Some communities choose to adopt GrapheneOS because they identify with it as a tool that helps them live a life of their ideal values, like Bitcoiners or Monero users do here. I and others don't put these labels on, that's their choice. If they question or have doubts for GrapheneOS or think we're running some kind of conspiracy then I'm sorry they feel that way. That's not something I can resolve if dialogues don't work, and usually it doesn't regardless of what and who says it... It's just based on vibes by that point. The project organisation is clear about being upfront about things. This is not a business with a product to sell. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It absolutely doesn't mean to come across as combative, I think it would be totally wrong and out of line to be offended at someone finding this stuff for the first time or getting curious. Unfortunately such content being a top result with good SEO by being created by influencers leads the project having to put words out way more often than the project likes to. We get asked a lot, if we're being asked then answers are needed, else they wouldn't ask us. We, and more specifically I would never let an issue like this distract from the objectives. A lot of the inflammatory responses do however disrupt work, but that's what community mods in the official chat rooms and forums are for. Distraction =/= disruption though. I do this for GrapheneOS because it means a lot to me and it has personally protected me in tough and hostile situations. I'm a forensics person, used Cellebrite and more -- but I love GrapheneOS and I'm absolutely okay with never being welcome in front of another forensic company's face. Some of the work done to GrapheneOS after such content being made have been some of the most significant yet. Duress password feature, VM management improvements, USB port control feature to name a few. The former lead dev had little, and if being honest, no involvement in writing code for these features. I'd say that's pretty evident to keeping the mission going. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It was not long from his first tenure back when they were talking about how Trump was using a Galaxy S3 as his everyday device. https://www.politico.com/story/2017/01/trump-android-phone-security-threat-234226 I don't have any confidence in state leader personal device choices. It's worse across the pond too: https://www.bbc.co.uk/news/uk-67275967 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final JD Vance using Signal for anything Top Secret is ludicrous. Keep it professional. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Signal is an excellent application but security requirements at such a high level mandate an exceptionally high-security device and operating system as well. The weakest link is the device and operating system they're using. I'd be very disappointed to hear if they had been using their personal iPhones or Stock Android devices for this (and it seems like they are, why the hell would you have a random journalist on your phone?). State actors would laugh. Sensitive Compartmented Information are meant to be handled in unique facilities... There's an improvement if they had a high security operating system (shameless plug) but even then it should be more bespoke in my eyes. The whole purpose of the device should be just to communicate over their service and nothing else. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final The downside to such a reply is that it can just be interpreted as avoiding the issue, being unprofessional or uncaring. Brave, as an example gets this issue as well, fortunately they don't receive anything as extreme beyond petty posts from Reddit. For us then it is a lose-lose and it's better to reply contextually and with the transparent approach than to ignore it when it comes to such people. We have helped keep user's trust and restore trust this way, you may not agree with it but it is better overall... the people who seriously dislike this approach wouldn't be moved with anything we said or who said it. The amount of times people just disregard words including my own as being written by video subject just because they don't like them is strange but a frequent happening. We talk because we like to keep our arms open. GrapheneOS has always worked like this because the modern GrapheneOS exists after a response to a hostile takeover attempt from an abusive company. Users expect us to take such major problems like this as it had been done. We just aren't willing to be let bad actors trample over us like this because this industry in general is full of bad actors and scammers. Having privacy and to be protected isn't just a right but a necessity for safety and wellbeing. Our community and users represent our public image, they lead 90% of the public discussion around us. They shouldnt ever brigade or attack others, and we ban people off our platforms for doing this. But as those representatives they deserve an explanation to such situations too. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Stepping in of a sudden here, but we absolutely do try to resolve sticky situations. When all measures have been exhausted, there's nothing much else to do here. It's worse to have extreme content unchecked. There is a lot of things that do happen that aren't talked about, a lot in fact, but this case is something very publicised and facilitated with someone who has a large audience who likely had been exposed to the project for the first time from such people. That's what makes it different here... Their (the other members) responses is absolutely not meant to be hostile. The person it's targeted stepped down as lead developer and moved away from public communication was part of that response for de-escalation. He writes almost no code for all the major new features over several years, if not at all. There's a lot of misinterpretation that GrapheneOS is a one man work and it's really not true nor is it possible to be. People can't read between the lines by themselves and you can't just 'de-escalate' violent or unwell individuals... sympathy doesn't work here because we can't sympathise with acts that have no positive outcome. There have been a serious escalation of attacks and barely any project affiliate wants to have a social presence. It's just me on Nostr here. And despite devs being paid and supported by us, many developers simply aren't comfortable and some prospective individuals didn't want to join the project in a more professional fashion due to concerns of their wellbeing. When situations escalated mods would need to be on watch for hours and report attacks on our social channels including Child Sex Abuse Material or additional threats of violence. That's how I actually started out on representing GrapheneOS in fact. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final People are the weakest link. A good messenger like Signal is nothing if you're talking to someone you don't know or trust. #nevent1q…4guy npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Other than the intensity built in intensity slider, there's no OS feature for it. Other ways would require risky apps with accessibility services that could also reduce performance and not actually do as they say. We allow users to set it high enough to a setting that at least eliminates all blue from blue pixels. It's more noticeable if you use an app like the Clock app for instance. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final noticed that! GrapheneOS is spelled incorrectly npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Hold both the volume up and power button at the same time to force restart. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final The 5a is old, it's unsupported and missing almost all our major new features anyway. The Pixel 9a is on the way and likely will discount the previous generations too. 8a is the cheapest device that has every security feature and is supported for a long time too. The 6a is the cheapest currently supported device and is the second-soonest to be unsupported (July 2027). npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final All donations are without influence or strings attached and anyone donating should expect they will not be given a privilege, the most they'll get is our thanks. We've refused and took matters public against orgs who've tried to do this. We've received far more from others. These donations are from Proton fundraisers paid by users and the targets for the fundraisers are also chosen by users. This post is for the users. Proton gets thanks for setting up that fundraiser and matching theirs as it is common courtesy. Unsure what you mean by compromised. Any time I heard something like this before it's because they previously had to do something compelled by the law of the country they're based in. It's obvious companies follow their local law because they have absolutely no choice in the matter. A conscious user should understand a company's obligations before choosing to tie themselves to an online service. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final If your device is not powering on with no Google logo or OS warning screen at all it isn't related to GrapheneOS. You'd at least get a boot loop. Please check your battery and charger, and if it doesn't work then it sounds like you have a hardware failure. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final GrapheneOS isn't useless because you installed Google services, there's still a lot of security and privacy features you can benefit from using it. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Second donation to GrapheneOS by the Proton Foundation https://discuss.grapheneos.org/d/21033-second-donation-to-grapheneos-by-the-proton-foundation npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS version 2025032100 released. This update enables the new, improved Desktop Mode as a developer option. Feel free to try it all out. • Sandboxed Google Play compatibility layer: improve support for overriding Gservices flags to avoid situations where our overrides aren't used leading to compatibility issues (this should fix a recent Play services crash that's being reported) • Sandboxed Google Play compatibility layer: improve support for overriding phenotype flags and fix flag overrides not being applied in some cases • fix 2 upstream lockscreen layout bugs with split shade used on folding phones (for the inner screen) and tablets • fix upstream lockscreen layout bug with placement of alarm and Do Not Disturb information • fix upstream lockscreen layout bug hiding date text when media is playing • enable support for the new desktop mode as an additional developer option toggle (Pixel Tablet already has this as the main toggle) • Terminal (virtual machine management app): backport upstream improvements • System Updater: raise download buffer size • System Updater: delete update package immediately after completion • System Updater: fall back to downloading and installing a full update if an incremental (delta) update fails initialization which occurs when a firmware or OS image has been corrupted (extremely rare edge case due to verified boot) • System Updater: retry faster if installation fails • System Updater: improve error checking to provide better error messages • System Updater: close update package zip file earlier • Network Location: require TLSv1.3 for GrapheneOS services instead of either TLSv1.2 or TLSv1.3 • kernel (6.6): update to latest GKI LTS branch revision • Seedvault: update to 15-5.4 (will be replaced with a better backup implementation in the future) • stop disabling inclusion of device diagnostics functionality now that it's available in the Android Open Source Project https://grapheneos.org/releases#2025032100 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final If an app loads remote content submitted by other users of the app, then attack surface for remote code execution vulnerabilities could be there. The most common example is instant messenger apps having zero-click exploits thanks to malicious attachments with payloads that the app automatically parses or loads. These attacks are highly sophisticated (the ability to be able to do them is sold on bounty sites for millions of dollars) with the amount of targets usually being in the hundreds. It isn't a concern for most people and you are not a significant target. This also depends on a malicious actor knowing who you are to send an attachment. For the attacks you're talking about, the device is compromised, not the app. All Apps need to be signed by the real developer to be an accepted update on the OS, it would need to have been a phishing app, the signing key of the real app compromised or the developer was intentionally malicious from the beginning. For your example of attack, it wouldn't really be something typical of what someone would try to do with this, and it would show signs of compromise even if subtle. For example, if you're using a password manager to log into a service, why doesn't it recognize this fake web login page as a real one? Native Apps look very different to web pages and webviews. With such kind of an attack they have a lot of access in different areas so there's no need npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Chromium team developed a new font rendering library (Skrifa) as part of their Fontations library written in Rust. Skrifa now provides memory safe rendering for all web fonts since Chromium 133 for Android, ChromeOS and other Linux distributions: https://developer.chrome.com/blog/memory-safety-fonts The above article lists examples of vulnerabilities exploited in the wild contained within the FreeType renderer that it seeks to replace. This is a post from 2022 about Android about the increased use of memory sage languages. https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html > Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language. Android has much more heavily adopted Rust since then. It's nice to see Chromium starting. This provides significant benefits to #Vanadium and #GrapheneOS users. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Companies of this business model are highly secretive and the amount of victims for such attacks isn't fully known since it depends on heuristics or TTPs used by the exploit during that exploit's period of not being exposed, there can always be more and it's not accurate to tell. It is almost certain such malware of its kind exists for iOS and the stock Android distributions. How that exploit is delivered also can vary and has a dependency on a user using a certain service or app, one example being WhatsApp. Majority of GrapheneOS features and exploit protections like hardened_malloc and MTE are designed for protecting the user against memory corruption vulnerabilities. Memory corruption makes up the majority of critical vulnerabilities exploited in the wild because of the capabilities exploiting it can bring. There are many features users could opt into using as well. For an exploit of its class to work on GrapheneOS, it would almost certainly have to be designed for GrapheneOS. This can be difficult to maintain due to regular updates and new features/enhancements of the OS or even the apps. #nevent1q…glvj npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Pebble is Apache 2.0 with proprietary dependencies. https://github.com/pebble-dev/pebble-firmware npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final New #GrapheneOS Vanadium browser release in Alpha supports passkeys without Google Play Services using the Android 15 credentials manager. Not every passkey provider supports it, but you won't need Play if yours does. https://github.com/GrapheneOS/Vanadium/releases/tag/134.0.6998.108.0 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Most of the apps I use are tied to a service, so they're not really something I can recommend unless they like that service. Organic Maps is a good maps app. AppVerifier is a good app to check the APK signing key hash of an installed app. Some app developers put it in their repo as a way of verifying an authentic download. I use this Gallery app: https://github.com/IacobIonut01/Gallery npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Locked and unlocked are specified separately in the docs. The image you are describing is for Stock OS pixels that are locked. BFU extraction type means extractions of data available in BFU state and nothing protected by a user credential. Brute force support isn't a guarantee of breaking the device alone. It just means it is capable of making a quick amount of PIN/password attempts at a short rate of time without throttling or other restrictions. You could use a very secure passphrase that would be impossible to brute force for example. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final I don't recommend this and I don't try this. RethinkDNS allows chaining numerous WireGuard VPNs. One of them with Tor would do it. All I can think of. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Should be possible, it's an entire Debian VM for you to install Docker in. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Sparrow Wallet server running on #GrapheneOS Debian virtual machine. Another great example of desktop Linux software running in GrapheneOS. ** PLEASE DO NOT HOLD FUNDS IN THIS WAY WITHOUT BACKUPS. THIS IS AN EXPERIMENTAL FEATURE. ** #nevent1q…7q34 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final "Full Filesystem" (FFS) Extraction - extraction of all available data including user-inaccessible operating system data, data from apps etc. Generic extractions getting data through typical OS APIs is called logical extraction. That would get your pictures, files, call logs, messages etc. filesystem extractions are the level above. A logical extraction could tell you you had a bitcoin wallet app, while an FFS could clone the whole wallet's data (ignoring wallet backups being saved in user's files). npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final GrapheneOS without a PIN/Password configured or GrapheneOS but the Cellebrite tool owner knows the password to unlock the phone. Basically the expected result for every device. They'd have data access without even having to use the tool in this circumstance. It's just convenience at that point. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final for the record, no OSINT is being done by us on where they originally come from, as we receive copies of them ourselves from people. I am aware the standard, uncracked Cellebrite binaries for this version also leaked, but it's of no use to us. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Graykey's capability is no different or even lesser to Cellebrite Premium and have been disrupted by patches to vulnerabilities in the stock OS that we reported to Google ourselves. Cellebrite's stock OS capability was unchanged and we are confident they lead in Pixel support. Check out: #nevent1q…pnge npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS is still not vulnerable to Cellebrite device exploitation as of the February 2025 support matrix. Appears the documents have leaked online in multiple places. I'll make a larger post summarizing it when I have time. Here is what you came to see: https://image.nostr.build/3a8806c05199436df22e2313f354afd7ef7b32c7cb1f5b3b70c29ed9d5f7f155.jpg Pixels with GrapheneOS remain the only device explicitly mentioned by Cellebrite as being unaffected by their exploits, and remains the only third-party operating system in their documentation entirely. We are the leading contender for mobile security and this is a great real world example. Here is a blog post that summarises the big pages for Android devices already: https://osservatorionessuno.org/blog/2025/03/a-deep-dive-into-cellebrite-android-support-as-of-february-2025/#the-february-2025-support-matrix npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Next update will add the new desktop mode. Pixel 8 and above use DisplayPort Alt Mode so you need a cable supporting it. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It's specifically different with the Pixel Tablet because that device doesn't have DisplayPort alternate mode for external display. The next release enables the new desktop mode with far more features as well. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final This is the desktop mode for GrapheneOS itself, so no. You will be able to run the virtual machines from the desktop mode though including running virtualized Desktop apps in their own windows: #nevent1q…jgj6 It's an upstream developer feature that needs to be refined so this will be a developer option too. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Next release of #GrapheneOS will enable the new Desktop Mode on all devices rather than just the Pixel Tablet. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Yes. VM management with GUI support was added in 2025031300. Past posts on my page should give a rundown. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Yes npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final LibreOffice Calc in #GrapheneOS Debian VM running on an external display in the launcher with 'freeform windows in external display' switched on: https://image.nostr.build/a6cb2fb03a7f584188f2530d0b8e2f1112a6c93a2cf9b20e16a1d3aa9d8ace86.jpg npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final None currently since this is brand new and some tasks and goals will be far more difficult to accomplish. Quality features take a lot of time. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Heard the included Weston setup works with GPU acceleration, but users won't be using that, it's reference software. You could disable the GPU acceleration to keep using GNOME. We haven't tried many different unique software setups yet before release. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final GNOME itself doesn't work well with GPU acceleration. Individual apps like Chrome would do. This is likely an issue with Debian freezing packages and not updating them. One of the reasons wanting to move to another distro is important to us. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Other device manufacturers don't provide the hardware necessary to run the features we want, including this one which needs hardware accelerated virtualization. A lot of people online say it's about lockable bootloaders but it's a lot more than just that. See https://grapheneos.org/faq#future-devices npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final No, this is support of desktop OS virtual machines, but a Samsung DeX style desktop mode for GrapheneOS / Android itself is also in the works and that feature will be important for adopting VMs. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final It's compatible with VPNs, the issue is that the OS is not excluding the local network traffic between the VM and Terminal app from going through the VPN which breaks it. It's something to work on. You can get through this without disabling the VPN everywhere else by making a fresh user profile and enabling the Terminal app there. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final virglrenderer file should be in the Linux directory. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Btw, you may not be using GPU acceleration, if you want to use that then: In the profile you installed the VM, make a directory in the home directory of the profile named 'linux' and a blank file named 'virglrenderer' to try it out. this will cause a toast to appear showing VirGL is enabled when launching the Terminal app AFTER force stopping it run " chromium --ozone-platform=wayland "and then go to chrome://gpu to see you're using the GPU. Should have a performance boost? The virgl server also likely isn't needed and that's just for running a server in the host OS. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Gaslighting Adversarial Network npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Upstream and GrapheneOS feature only does Debian. We are looking into other ARM Linux distros, namely Fedora, and a gold target of running completely operating systems like Windows 11 ARM. To be able to run any OS is something to work towards. More work needed first. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Pixel Tablet clearly has capability for such accessories but they don't make it. It's a very neglected product. The next generation Tablet should have more effort. The Pixel Tablet is the only tablet and doesn't support all the flagship security features like MTE either since it's a 7th generation device... npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final This is Android 15 QPR2 but yes. There are some hidden feature flags for 16 that are enabled to let this happen + some additional patches. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Footage of GNOME, Firefox and Doom running within #GrapheneOS Linux virtual machines. #nevent1q…7zp8 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Awesome footage! npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final obviously this won't be fast or replacing a PC anytime soon, but it's a matter of growing improvement, there's still a hell of a lot to work on with this. We're doing it first and better than other distributions. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Currently it is Debian as that is what the upstream feature uses and downloads. Usage of other, better suited distros would be looked at in the future. It has to be a distribution with ARM support. Potentially Fedora. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Say hello to GNOME on #GrapheneOS (credit tuxpizza) https://image.nostr.build/0b7e3a39a29683beb0f551dcf964b740694519f8a75db34ee98510e9ce8d42f6.jpg KDE Plasma reported not to work in certain situations but ways to overcome being looked at. Here is footage of KDE (credit Bench) https://video.nostr.build/fd24bcf221c80de0fd22733d5081dc5ced26c591fa61bcb023362ed3320ae59a.mp4 https://video.nostr.build/e60008124a521eadc90e04610b740605865f064df49b384937cc3e6218a9979f.mp4 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS version 2025031300 released. This release greatly improves the experimental virtual machine management app with many backports from the Android Open Source Project main branch. You'll need to install Android's latest Debian-based image in order to continue using it. You'll be prompted to do this at startup after it fails to start with the old setup with an opportunity to back up the data. The data inside it should continue to be treated as disposable rather than relying on it not losing it from a bug or a backwards incompatible update. • Sandboxed Google Play compatibility layer: overhaul our default enabled reimplementation of the Google Play location service (location request rerouting) to provide much better compatibility for apps depending on network-based location by always telling apps that the Google Improve Location Accuracy toggle is enabled and providing fallback to GNSS for low power location requests when the OS network location service is disabled as it is by default (unlike Google Play services, which has no fallback, but apps assume users enable the feature) • fix Storage Scopes related null pointer exception in thl • Bluetooth: backport fix for empty adapter name handling in Android 15 QPR2 to avoid crashes when the name is set to an empty value or whitespace • Terminal (virtual machine management app): backport a large set of improvements including terminal tabs, port forwarding, GUI support with opt-in GPU hardware acceleration (ANGLE-based VirGL until GPU virtualization support is available), speaker/microphone support and fixes for a bunch of bugs including overly aggressive timeouts • Settings: add Terminal app toggle to System category when developer options are enabled (requirement will be dropped when it's no longer experimental) so it can be enabled in other users (it's still currently only possible to use 1 instance at a time due to conflicting use of an internal network specific to virtual machine management) • Pixel 8 Pro, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold: fix support for enabling UWB (ultra wideband) radio by adding missing SELinux policy to avoid the UWB service chain crashing and burning CPU • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.130 • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.82 • Seedvault: update to 15-5.3 (will be replaced with a better backup implementation in the future) • Vanadium: update to version 134.0.6998.95.0 • Camera: update to version 83 https://grapheneos.org/releases#2025031300 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final #GrapheneOS version 2025031300 released. This release greatly improves the experimental virtual machine management app with many backports from the Android Open Source Project main branch. You'll need to install Android's latest Debian-based image in order to continue using it. You'll be prompted to do this at startup after it fails to start with the old setup with an opportunity to back up the data. The data inside it should continue to be treated as disposable rather than relying on it not losing it from a bug or a backwards incompatible update. • Sandboxed Google Play compatibility layer: overhaul our default enabled reimplementation of the Google Play location service (location request rerouting) to provide much better compatibility for apps depending on network-based location by always telling apps that the Google Improve Location Accuracy toggle is enabled and providing fallback to GNSS for low power location requests when the OS network location service is disabled as it is by default (unlike Google Play services, which has no fallback, but apps assume users enable the feature) • fix Storage Scopes related null pointer exception in thl • Bluetooth: backport fix for empty adapter name handling in Android 15 QPR2 to avoid crashes when the name is set to an empty value or whitespace • Terminal (virtual machine management app): backport a large set of improvements including terminal tabs, port forwarding, GUI support with opt-in GPU hardware acceleration (ANGLE-based VirGL until GPU virtualization support is available), speaker/microphone support and fixes for a bunch of bugs including overly aggressive timeouts • Settings: add Terminal app toggle to System category when developer options are enabled (requirement will be dropped when it's no longer experimental) so it can be enabled in other users (it's still currently only possible to use 1 instance at a time due to conflicting use of an internal network specific to virtual machine management) • Pixel 8 Pro, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold: fix support for enabling UWB (ultra wideband) radio by adding missing SELinux policy to avoid the UWB service chain crashing and burning CPU • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.130 • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.82 • Seedvault: update to 15-5.3 (will be replaced with a better backup implementation in the future) • Vanadium: update to version 134.0.6998.95.0 • Camera: update to version 83 https:/grapheneos.org/releases#2025031300 npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final BitLocker is fine, it's the best choice of OS disk encryption for Windows users since BitLocker has TPM support. TPMs suck compared to a proper secure element but they are better than nothing. fTPMs are more resistant to physical attacks documented with TPMs. Veracrypt refuses to have TPM support at all. Claims of backdoors are unsubstantiated and a lot of weaknesses come from other problems universal to most desktop disk encryption and awful design choices, such as BitLocker being only available in Pro, Enterprise or Education editions of Windows and the default settings just using a TPM with no additional authentication needed. BitLocker is the best choice when certain settings are configured. You'd need to configure group policies to allow BitLocker to have additional authentication such as a TPM + PIN or USB key (or all three through a hack job), force 256-bit AES encryption, and to make PINs alphanumeric instead of just numbers. Do not use the Windows Device Encryption in the Home edition. It requires a Microsoft account and requires backing up your key to your account's OneDrive. MacOS has FileVault which users should enable if it hasn't been already. ChromeOS uses the same per-user filesystem encryption per user GrapheneOS uses but depends on a Google account to sue it. Macs provide the best OOTB disk encryption. Both VeraCrypt and Picocrypt are fine apps and trustworthy. They're better overall for encrypting files or removable drives though, protect them with very secure passphrases. If the OS provides a disk encryption option then I'd believe you're better with using that. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final They should still need the feature. Forensic experts would be trained in device repair and just replace the port, so it should disable itself even when the port is replaced. It would increase the time before an extraction attempt could be performed though. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final There are some companies who claim BFU Physical extractions, mostly on very insecure MediaTek devices and some Samsung Exynos devices. This extracts everything but the data extracted is still encrypted... so it needs a brute force anyways. There isn't a "master key" because that key is created and derived from the user credential which you need to know. It's advertiser speak. Take a look at this video MSAB made: https://www.youtube.com/watch?v=8Y9PZzHu_3U Notice it says "XRY Pro has allowed me to *BRUTE FORCE* that device" at around 1:20 despite the narrative in the title and the video? Shameless... A good amount of Samsung devices do have brute force support though as documented in our last doc publications and in this video. More reasons why a dedicated secure element like the Titan M2 is very valuable. npub1hxx76n82ags8jrduk0p3gqrfyqyaxnrlnynu9p5rt2vmwjq6ts3q4sg75y Final Example of iOS BFU here: https://blogs.dsu.edu/digforce/2023/08/23/bfu-and-afu-lock-states/