n2gwtl If you enable network location by itself, it will work when Wi-Fi enabled. If you enable Wi-Fi scanning, it will also be able to do Wi-Fi scans when Wi-Fi is otherwise disabled. Read the description of Wi-Fi scanning. Bluetooth and Wi-Fi scanning toggles are standard Android toggles enabled by default on the stock OS. They are not specific to our network location implementation but rather impact any apps granted the required permission to do scans.
Nn2gwtl
- Online
- Joined Feb 18, 2024
But at least you can see what the app does
People can see what closed source apps do too. It's a misconception that source code is required to look at what the code is doing. Either way, the code is available for review. It's much more convenient to review it as source code than compiled code, but the gap depends on the language. It's quite easy to review compiled Java code with basic tools, while reviewing compiled C or especially C++ code is significantly harder.
n2gwtl 8th/9th generation Pixels are ARMv9 devices and have the optional hardware memory tagging feature (MTE). GrapheneOS began using hardware memory tagging on 8th generation Pixels shortly after they were released. It's still not deployed by other general purpose operating systems in production, let alone with a comparable implementation to ours.
ryrona QubesOS doesn't protect against USB exploits while locked to the same degree as GrapheneOS because the USB controller and USB guest can be exploited. Containing the attacker to the USB controller and to a virtual machine for handling USB isn't comparable to eliminating most of the attack surface. The attacker getting code execution in the USB controller or a virtual machine is much more than not having something to exploit.
GrapheneOS provides much stronger protections against USB drivers being exploited. QubesOS provides much better containment and access control for USB. We do plan to add USB peripheral access control for users but it needs to avoid destroying usability. It's lower priority than a desktop/laptop due to how they're used.
Laptops / desktops don't have serious physical security so USB exploits are really not needed for exploiting them after the encryption passphrase is entered.
- Edited
GrapheneOS is just now releasing a nework location feature which offers an opt-in toggle for detecting location using nearby Wi-Fi networks, providing a more power-efficient and faster alternative to soley satellite-based location (GNSS) with release 2025022700 (they had to fix some issues - if I'm not mistaken the feature is hitting stable with release 2025030100) .
You can choose between Apple's services and a GrapheneOS service proxy.
GrapheneOS is also building its own database service which will also include cell towers and offer offline support in the future.
So you don't depend on Google Play's network location any more.
source and additional infos: https://discuss.grapheneos.org/d/20369-grapheneos-version-2025022700-released/78
n2gwtl Fedora on a Framework laptop will provide essentially zero physical security with no protection against data extraction after you've entered the encryption passphrase. It will only protect your data while the device is powered off. macOS on a Mac will provide far better physical protection. macOS will also be harder to exploit.
TPM 2.0, systemd-boot, and secure boot
The implementation of secure boot and attestation by both that hardware and the OS (Fedora) is incomplete and insecure. It provides no real world security benefits. It neither provides against attacker persistence after exploitation or physical attackers. It's work towards real security features without getting to the point that it actually works. It's similar to locking your front door on a house where there are no walls, just a wooden frame people can step through. It does not deter an attacker.
n2gwtl Having native debugging disabled without enabling hardware memory tagging was triggering the alert due to Chromium 132 adding code to log debug information when memory tagging is enabled for Chromium as Vanadium does but not enabled by the OS. It has been resolved in the latest Vanadium release.
On the Pixel 9 Pro you can switch from a secondary profile to the owner profile via biometrics without issue.
- Edited
n2gwtl
Its being polished ready for public release. As with most new features we can not give a potential release date.GrapheneOS version 2024102000 released:
https://grapheneos.org/releases#2024102000
See the linked release notes for a summary of the improvements over the previous release.
GrapheneOS version 2024101801 released:
https://grapheneos.org/releases#2024101801
See the linked release notes for a summary of the improvements over the previous release.
As I understand, Bluetooth supports authentication and encryption, and supports fallback to less secure protocols. I would like a feature that would identify if my connection to a bluetooth device is encrypted and authenticated and whether it is the strongest encryption possible.
GrapheneOS version 2024101600 released:
https://grapheneos.org/releases#2024101600
See the linked release notes for a summary of the improvements over the previous release.
n2gwtl Looking through the OS issue tracker, it looks like developers have suggested that this crash is likely due to a hardware problem. Here are some links that I found:
- Edited
n2gwtl What does "By default, location requests are rerouted to a reimplementation of the Play geolocation service provided by GrapheneOS" refer to?
When software people talk about service, they often mean "something that is behind an API". Two implementations of a service may behave differently internally as long as they are arguably both doing the job.
The inherent job of a location service is to tell you where you are. One way to do that is relying on satellite signals. Another way to do that is relying on satellite signals plus a database of cellular-tower locations and Wi-Fi base-station locations.
The GrapheneOS "reimplementation" of Google's location service is not accessing Google's database or -- so far -- accessing any other similar database.
The sentence after the one you quoted is: "You can disable rerouting and use the standard Play services geolocation service instead if you want the Google network location service and related features". The Google implementation is faster, works better indoors, and also maps locations to street addresses, which the GrapheneOS implementation does not at present.
At present your options are using Google's implementation of the location service, which relies on Google's code and Google's database and may well result in Google tracking you, or relying on the satellite-only implementation.
- Edited
n2gwtl My understanding is that the choices on GrapheneOS at present are:
- the built-in location service, which uses satellites only, or
- Google's location service, which fuses satellite location with Google's proprietary databases of cellular towers and Wi-Fi SSIDs
I further believe that the GrapheneOS project hopes to work with beaconDB on an open-source/open-data/non-tracking fused location provider for GrapheneOS (and presumably other AOSP variants).
This relates to all apps that you want to go outside of the VPN tunnel. You cannot use the VPN apps' split tunneling features when "block connections without VPN" is enabled. The VPN app might not inform you of this, nor try to detect whether or not its split tunneling feature is working correctly on your device.
