27. November 2020 | 17:30 Uhr

Erneut Rückmeldung von Daniel Micay: GrapheneOS-Entwickler

Daniel Micay hat mich erneut per E-Mail kontaktiert. Meine Kritik wird dort wohl ernst genommen und das Team arbeitet an diversen Verbesserungen. Aber lest selbst:

[1] Zum Thema Captive-Portal-Check:

We’re now using our connectivity check server by default with a configuration option preserving the ability to blend in with other Android devices:

https://grapheneos.org/releases#2020.11.25.22
https://grapheneos.org/faq#default-connections

[2] Zum Thema Vanadium:

We’ve also made some further changes to Vanadium and I’ve started the process of getting an issue we’re now working around fixed upstream:

https://bugs.chromium.org/p/chromium/issues/detail?id=1150817

Vanadium still uses the standard connectivity check URLs. We need a developer to help us integrate support for respecting the system configuration. The Standard (Google) mode should use the standard Chromium configuration, and by default in the GrapheneOS mode it can make use of our connectivity check server including for the offline pages checks.

We plan to add the option of disabling the connectivity checks to the new setting, which is why it’s a list preference instead of simply a toggle for using the standard servers. We’re starting with the simplest way of changing the defaults while preserving the ability to blend in. I don’t think we’ll offer custom configuration in the Settings app. It is too confusing for end users to configure 4 URLs and it will be possible for the network to identify them based on their custom configuration. It will still obviously be possible for advanced users to configure it via the ADB shell.

[3] Zum Thema microG:

We’ve also come up with a good approach to supporting users installing microG as a regular unprivileged app specific to a profile. We’ll be implementing this in the near future to provide the option of using GrapheneOS builds of microG. It won’t be given any special privileged permissions or whitelisting. Instead of a generic signature spoofing permission breaking the permission model, we’ll be adding specific mappings from the app id + signing key to the Google signing keys, Our microG build will appear to have the Play services signature but will NOT be able to bypass signature checks in general and there will be no permission for apps to obtain with or without user consent.

This will be a bit annoying for people to install and keep updated until we’ve implemented and integrated our planned first party frontend to the OS package manager for using a first party repository. This is needed because F-Droid doesn’t meet our standards / requirements. It will be very minimal and not intended to replace using apps like F-Droid, Aurora Store, etc. for obtaining third party apps via third party repositories. However, we could make our own builds of F-Droid and Aurora Store and publish those through it, to make it easier for people to set things up. We won’t include a lot of apps, just ones where there’s a good reason for us to package it, such as providing hardened releases of a best in class encrypted messaging app, etc.

Great news! Finde ich ja klasse, dass Kritik reflektiert wird und Änderungen bewirkt.

Der Kuketz-Blog ist spendenfinanziert! Mitmachen ➡