20. November 2020 | 17:00 Uhr

Rückmeldung von Daniel Micay: GrapheneOS-Entwickler

Daniel Micay hat den Beitrag zu GrapheneOS gelesen. Nachfolgend seine (englischen) Antworten bzw. Reaktionen zu unterschiedlichen Themen aus dem Beitrag.

[1] Ausschließliche Unterstützung von Google Pixel Geräten:

We’re very interested in supporting more than Pixels and are actively working with some companies to influence future hardware and potentially partner with them to get our hands on GrapheneOS versions of the devices.

Current devices that are supposedly privacy-focused have substantially worse security and also privacy regressions. There are mainstream devices meeting our requirements… but only when running the stock OS. The hardware vendors choose not to invest in providing full support for alternate operating systems and cut corners when it comes to making it secure. Only supporting verified boot, attestation and full hardware keystore functionality with the stock OS is the norm. It’s unclear if there are any existing devices we could be using. It is quite possible that some of the Android One phones would be a suitable target comparable to the security of an older generation Pixel. We don’t have the resources to invest in purchasing devices, doing research on them and also communicating with the vendors. We regularly report issues with Pixels and get them resolved, including issues only impacting an alternate OS.

[2] Vanadium- und Captive-Portal-Verbindungen zu Google:

Vanadium implements the same kind of similar connectivity checks as the OS. We document that in the FAQ section on default connections. It doesn’t send any data to Google servers via the connections it makes to check availability. We haven’t removed the Safe Browsing toggle but that doesn’t actually do anything and isn’t enabled by default in Vanadium. We wanted to eventually self-host it and switch it to using the hash prefix approach with a local database so that users could have the option of enabling it. That’s the only reason we don’t
disable it, even though it is a no-op without Play services. Enumerating badness is a very bad approach to privacy and security, but still, it can counter some low-hanging fruit, and we see it as a problem that we don’t have an implementation of Safe Browsing. Similarly, we plan to provide robust content filtering in Vanadium in a way that cannot be used to differentiate
between different Vanadium users, which is a problem with content filters in general. We lack the resources to get all this done in the short term, and these kinds of changes aren’t our priority since users can use Bromite as a browser in the meantime and nearly all of this is irrelevant to the WebView.

We plan to switch to using connectivitycheck.grapheneos.org as the default server. However, as a general rule, we don’t want to make network visible changes without offering a officially supported (not developer tools) and documented way to disable it. This means implementing a toggle in the Settings app for controlling the connectivity checks is a prerequisite for us to change the default. We realize that people don’t like making HTTP(S) GET requests to Google servers. However, those requests are identical to billions of other devices and do not send any data to the servers. Making the requests to any other servers distinguishes the device from regular Android devices, similar to how connecting to the update server identifies it as a GrapheneOS device to the network. It needs to be possible for users to set their device to a mode where it does not announce itself as a GrapheneOS device to the network and cannot be realistically fingerprinted as one.

On the other hand, announcing to the network that the device is running GrapheneOS is something that users need to have a way to avoid. This toggle has been planned for a long time and we already provide the service for it along with making a low-level change to fix a deficiency of the AOSP settings. There simply hasn’t been interest from contributors in helping us with this. It will get done in the near future, perhaps in the next few weeks, or next month, and I’ll let you know when that happens. There is someone that has expressed interest in working on it and I expect them to follow through.

https://github.com/GrapheneOS/os_issue_tracker/issues/198
https://github.com/GrapheneOS/platform_packages_modules_NetworkStack/commit/ef238eef75b95e91791c7f33a7a7faa96137ecce

Dem möchte ich allerdings hinzufügen, dass die von mir bemängelten Verbindungen zu Google nicht in den FAQ genannt werden: clientservices.googleapis.com und accounts.google.com. Darauf hat Daniel wie folgt reagiert:

Chromium uses different domains for connectivity checks. The FAQ states that they are similar but we don’t explicitly list out the domains. We haven’t decided exactly how we want to adjust this for the browser. It doesn’t really make much sense to us for the browser to have separate captive portal and connectivity checks if it can rely on the OS doing it. Similarly, it doesn’t make much sense for the browser to handle DNS itself, especially since Android supports encrypted DNS in the OS. There are a lot of things we’re going to need to address.

Even though we’ve disabled sign-in and variations (seed-based testing of feature flags), we haven’t disabled making the initial connections to check if the services are available. So, we’re grouping those in with the other connectivity checks. Those 2 connections are definitely not necessary, and we plan to remove them, but we want to figure out the cleanest and most minimum way to make these changes while also making sure that it’s not going to regress in the future. Help with this is very welcome. That’s what you’re talking about.

There are also component updates (chrome://components/) which we’ll need to figure out how to provide ourselves, or we need to bundle up-to-date versions with the browser which is already happening in some cases but not others. For example, we need CRLSet (or an alternative) support and the existing server for that is provided by Google. The updates are too frequent to simply update it with the OS. At the moment, component updates are not happening unless you trigger them manually due to not having Play services. So, you won’t see the connections right now, but we do need to deal with this, among other things. Since this doesn’t happen without users triggering an update, we’re not listing it.

Android Open Source Project is easier to deal with in this regard due to Google apps and services being explicitly separate from it and it being set up to support changing all of this easily. A lot of things like supl are also left up to carrier configuration. AOSP tends to prefer letting the network and carrier decide on the service provider.

These are used for offline page connectivity detection:

https://www.google.com/generate_204
http://connectivitycheck.gstatic.com/generate_204

This is the captive portal detection URL:

http://www.gstatic.com/generate_204

The https://connectivitycheck.gstatic.com/generate_204 and http://connectivitycheck.gstatic.com/generate_204 connectivity URLs are also used elsewhere.

The current state of things is definitely not how we want things to be but the browser is more complicated than the base OS because we do need certificate revocation database updates, we probably want Safe Browsing support, etc. so we need to figure out how to host a bunch of things ourselves. Also need to deal with browsers treating themselves as their own OS and deciding to do their own connectivity checks, DNS resolution, etc. It’s really a mess, and we know that. We have limited resources so it takes us a lot of time to get things done, especially since we want to do it all properly in a rigorous and robust way.

[3] Cloudlfare DNS-Server (1.1.1.1) als Fallback:

To clarify something about the DNS fallback, it’s only used when the network fails to provide DNS servers as expected. The sample DNS servers for static IP configuration are a separate thing that we changed alongside this. Since the network provider can see all of the IP addresses involved in connections, using the network provided DNS servers is generally best for privacy. Enabling the Private DNS feature is not necessarily a privacy improvement, particularly when using a VPN, where using the VPN-provided DNS servers blends in with other users of the VPN. It is possible to determine the configured DNS server even for a website without JavaScript enabled. They can generate a random subdomain and include that as the source of a stylesheet, image, etc. They can then identify the DNS server configured by the user from the connection incoming to their authoritative DNS server.

There aren’t that many robust, high-availability public DNS server options available to consider as fallbacks. Most of those have no privacy policies or other important information available. Cloudflare’s service has the best privacy policy among all the options that we looked into and it’s also the 2nd most popular public DNS service after Google which is a good thing to blend in with the crowd. In practice, the fallback isn’t used. A network could fail to provide DNS servers over DHCP as part of fingerprinting a device though. It’s an example of a change that makes the device easier to distinguish from a mainstream OS. Perhaps it should be configurable so that people can set it back to Google Public DNS to avoid this as part of changing the other settings to match AOSP / stock and disabling the update client. This is relevant even when using a VPN since despite the OS using the VPN DNS servers, it still has to bootstrap with the network DNS – or the fallback if it doesn’t provide any DNS servers to use.

[4] CalyxOS vs. GrapheneOS:

In general, GrapheneOS is focused on privacy and security improvements to the OS. We provide a lot more than minor benefits over AOSP. We don’t currently have a very good website and it doesn’t communicate all of the improvements we make to privacy and security. We find this difficult to document because each major release of AOSP provides a lot of privacy and security improvements and our feature set is always evolving. We could provide a list of current changes from AOSP and delete anything that ends up being done upstream.

CalyxOS has a much different focus and doesn’t do the same kind of hardening against exploitation, improvement of the app sandbox, reduction in what kind of information apps can access, etc. We also have different ideas about how to approach things like compatibility with apps that depend on Play services. We really don’t want to have hard-wired support for Google services in the OS with special capabilities and privileges unavailable to other services. An open source reimplementation of a service like FCM is still an implementation of FCM and apps like Signal will detect it is available and use it instead of their own push implementation. We do have a plan for improving compatibility but it involves providing an implementation of the Play services APIs where it pretends Google servers are unavailable, so that apps will work without that functionality, unless they truly cannot work without the servers, which means they don’t work on filtered networks, etc. either. We just don’t have someone to work on this right now.

Similarly, we want to do things like making our own implementation of the WebUSB-based https://flash.android.com/ installer, along with implementing various other apps including our own first party app installation and update system, which could offer F-Droid and Aurora Store as some of the apps with first party builds in our repository to make it more accessible, while not having to bundle it due to licensing and robustness issues with it preventing us from wanting to bundle it again as we did in the past. We can’t give F-Droid automatic app installation privileges without it being a significant security issue. We know that the install process needs to be much easier and it needs to be easier for users to obtain apps after installing, but we aren’t going to take shortcuts on this.

[5] Verbindungsaufbau zu epdg.epc.mnc001.mcc262.pub.3gppnetwork.org (für WiFi-Calling) alle 20 Minuten:

You should be able to disable it in the carrier configuration. Do you see a toggle for it? You should just be able to toggle it off there rather than needing to disable IMS or modify APN configuration. My carrier doesn’t provide either VoLTE or VoWiFi so I don’t have that.

Once 2G/3G are gone there will only be data-based calls (VoLTE/Vo5G and VoWiFi). This is becoming a problem for us because we haven’t yet integrated a bunch of additional carrier configuration (CarrierConfig) beyond APNs so VoLTE / VoWiFi generally won’t work yet.

Leider existiert aktuell kein Toggle.

Ich finde, die Antworten geben nochmal einen tiefen Einblick in GrapheneOS bzw. das Bestreben, das System weiter zu verbessern.

Unterstütze den Blog mit einem Dauerauftrag! Mitmachen ➡