releases.grapheneos.org

e. https://grapheneos.org/faq#default-connections But yes, I do believe that he's obliged to do some research before putting out such absurd claims entirely based on speculation with no technical knowledge or understanding.

lds. It takes around 40 minutes to do a full build of the OS portion of GrapheneOS on a recent 16 core AMD gaming CPU and half as many cores won't actually take twice as long since scaling isn't linear. It takes under a minute to do most incremental builds for testing changes after the initial build. If you make your own builds, you don't have to modify anything to have root access via ADB. A userdebug build has root access in the Android Debug Bridge (ADB) shell via a su executable along with support for adb root to run ADB itself with root access so every command has it available including the shell, push and pull. You should enable ro.adb.secure=1 for a userdebug build if you intend to use it in production to enable USB-based ADB authentication like a regular user build. You should be aware userdebug reduces security through poking a lot of holes in SELinux policy in order to provide root access and the ability to disable dm-verity while unlocked. Your own builds will not connect to releases.grapheneos.org for updates. If you want updates, you need to enable the Updater app by exporting OFFICIAL_BUILD=true after changing the URL to point at your own static web server. It's very easy to set up an update server and we publish official documentation and the sources for our services. We don't outsource our update systems to mirrors for privacy and security reasons. The app releases, OS releases and app repository metadata are signed with downgrade protection but that doesn't mean a mirror system is a good idea. Here's a list of all default connections made by GrapheneOS: https://grapheneos.org/faq#default-connections Here's where you can get what you need to host all of this yourself, which is quite straightforward and easy: * https://github.com/GrapheneOS/releases.grapheneos.org * https://github.com/GrapheneOS/apps.grapheneos.org * https://github.com/GrapheneOS/grapheneos.network You can choose to host only the network services and use our official app repository. If you rebuild one of the apps we update through there, just change the app id so it won't try to update it. The services need to be updated before an OS update depending on changes to the APIs which are documented in the official release notes. For example, Broadcom GNSS moved to a new format for part of the PSDS data. It's all in 1 repository (grapheneos.network) if you don't host app and OS updates. You can host all this stuff on 1 server but we use separate ones for network services and updates since the load is so dramatically different. The approach in the repository you're linked was always a very fragile and improper way of doing things. GrapheneOS is an open source project and you should modify the sources if you want to make changes. GrapheneOS has officially planned support for toggling off secure activities disabling screenshots, toggling off apps detecting screenshots, built-in network-based location with multiple options including fully offline support via scraped data and Location Scopes for per-app location spoofing to go along with our Contact Scopes and Storage Scopes features. We don't understand why this repository is portraying these things as if people need to modify GrapheneOS to obtain them. If people helped us implemented the features in GrapheneOS, they would be available to everyone. Built-in network-based location is one of our top priorities and our implementation is nearly ready to ship in a production release. Location Scopes is a relatively high priority. The screenshot-related ones are low priorities but someone who considers it important can contribute and get it implemented soon. The linked README has many inaccuracies about how things work and why they work the way they do. GrapheneOS has a built-in encrypted backup system which backs up data for every app since it uses the device-to-device backup mode. Play Store requires apps to use a modern API level for both updates and new apps along with unlisting apps not updating their API level for a few years. Therefore, the issue of certain apps not supporting backups due to opting out of cloud backups or excluding their files from cloud backups has been solved. allowBackup is not a thing anymore and neither are the traditional file exclusions. Apps can specifically exclude files from device-to-device backups for security or portability reasons, but few do, and it's almost always for a good reason. Apps can provide a backup service to backup and restore with a portable format. Files are often device or install specific. Logins also usually aren't meant to be cloned and can be made device-specific with the hardware keystore, as can other data. Signal encrypts their whole database with the hardware keystore so ignoring the backup exclusions won't achieve anything. The hardware keystore works as a normal HSM does for good reason and it has attestation to prove keys are backed in a TEE or secure element along with verifying the OS. This gets into their mention of the legacy SafetyNet Attestation API and the current Play Integrity API. We had a feature filed about spoofing Play Integrity, but only spoofing the software device integrity level is possible and they require hardware attestation on devices properly supporting it. Pretending to be a Pixel with stock OS requires leaked keys. Pretending to be another device with the stock OS is easy for them to block via their extensive fingerprinting including GPU fingerprinting. Any attempt to do spoofing at scale can be blocked by them. It would be a black hole for development effort, and users would not have a reliable way to use apps banning using any aftermarket OS or non-Google-certified device. Apps which want to forbid something like Mock Location such as Pokemon Go can and will use the Play Integrity API to require a Google-certified OS. Since GrapheneOS supports hardware attestation, they can check that it's unmodified GrapheneOS and permit it too, which we've convinced a few app developers to do: https://grapheneos.org/articles/attestation-compatibility-gu... Hiding that Mock Location is active simply means apps will not permit using GrapheneOS. It's pointless to trick apps about this when they won't permit using an OS tricking them. We haven't decided what to do for Location Scopes. Our approach will likely be making a new API so apps banning Mock Location will be compatible but apps which want to ban spoofing location don't have to ban GrapheneOS. That way, apps unaware of GrapheneOS will work with it if they don't ban it and apps aware of it don't have to ban it. What's a better option? We're not doing anything anti-user. Preserving the security model in the regular production releases is not anti-user but rather pro-user. Most people aren't ever going to be using CLI commands while understanding and truly consenting to what they're doing by reading the documentation. App-accessible root is not something we think is at all pro-user and the apps using it are taking a shortcut to implementing something without following the principle of least privilege, etc. By definition, it's not a secure way to implement functionality. It inherently gives root to a massive portion of the OS and can't truly be revoked. Users having root themselves via ADB is a different story but it doesn't mean it's a good idea to have that in regular production builds for everyone. It has a cost.