4 ms·

The GrapheneOS FAQ [0] enumerates all the connections the OS and default apps will make and notably absent is anything Google-related. Your claims seem to cont

by Youden 6y ago

The GrapheneOS FAQ [0] enumerates all the connections the OS and default apps will make and notably absent is anything Google-related. Your claims seem to contradict the FAQ (e.g. you mention connectivity checks which are mentioned explicitly). Have you reported any of these issues (e.g. [1])? What was the response? Can you point to any specifically problematic code? I'm not involved with GrapheneOS in any way but these seem like easily-verifiable claims if true. [0]: https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections [1]: https://grapheneos.org/contact#reporting-issues https://grapheneos.org/contact#reporting-issues

user3939382 6y ago
I regret that I didn’t do a detailed write up at the time, and that since I didn’t I only have some abstract anecdata to offer but for what it’s worth: A couple years ago I rooted Android (Planet Gemini), installed my own root CA, forced all network through USB-C —> ethernet, connected the ethernet to a physical network tap, and decrypted almost all the traffic. With only a handful of common apps installed the (idle state, no UI interaction) phone-home traffic and telemetry was non-stop. A majority of it was to Google, blocking it made the phone basically non-functional. There were also inexplicable calls to strange Chinese IP addresses that would only emerge every one or two weeks that I couldn’t hunt down the source of and Planet said they didn’t recognize. I want network activity to be 100% correlated with my UI interactions including updates. I feel power users should be given that right and option. Windows and macOS (and sadly Firefox) are also miles away from this but Android was ridiculous. I haven’t tested iOS but I assume it’s about the same.
ThenAsNow 6y ago
I have spent time on the IRC channel and it is clear the founder/project lead (whom I'm not criticizing) has a different idea of what privacy means than what I do. He doesn't necessarily view connections to Google servers that take place without explicit user intention/confirmation as problematic. Based on his strong personality, I did not think it likely any patches I wrote would be accepted by him. Indeed, he thinks it best to "blend in" with other Android traffic. He is also, in my opinion, overworked. I'm looking at my abortive patchset against GrapheneOS from last year, which I never bothered to finish up to post, and will just pick a couple of random samples: packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com) packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers) external/webrtc/webrtc/p2p/stunprober/main.cc (uses a Google STUN server) packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java (calls to the play store) That's a random sampling, not trying to assess for "severity". You can rationalize away each of these individually, but I was at 41 patches when I stopped (including changes that address Google connections that GrapheneOS acknowledges). The cockroach infestation analogy is pretty apt. They are everywhere, and if you try to follow the code to assess for severity, it will be hugely time-consuming, so unless you have a team developing the patches, the safest thing is to pre-emptively patch out. I'm not saying any of these is malicious, my point is there are tons of these kinds of things littering the code. It will be extremely time-consuming to find and cut this stuff out of the base applications and libraries underlying installed applications. And BTW again, this says nothing about SUPL, which is still tracked as an issue about which there isn't a lot of clarity: https://github.com/GrapheneOS/os_issue_tracker/issues/96 https://github.com/GrapheneOS/os_issue_tracker/issues/96 You can also see in that issue thread that the project lead does not see the project as focusing on de-Googling which is, in fact, what many of us want, and are wrongly projecting as a GrapheneOS project goal.
- throwawayboise 6y ago
  I mean, it almost sounds like you want a phone that doesn't connect to anything. If I may ask, what's the point. Just don't carry a phone.
  - monocasa 6y ago
    It sounds like they primarily don't want their phone to connect to Google without asking the user, not that they don't want it to connect to anything. Google has not become the whole internet yet.
    - ThenAsNow 6y ago
      Exactly this. I'm not sure how wanting a device that can connect only as per my requests/configuration requires that I instead be OK with it willy-nilly connecting to whatever it wants.
    - strcat 6y ago
      See https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections which is an accurate list of the default connections in the OS. There are no connections to Google made by default. We offer the option (opt-in) to use their connectivity servers instead of ours, contrary to what the person you're talking about has claimed here. They have made false claims about connectivity checks, DNS, SUPL, WebRTC and other things. They have made false claims about what the project provides, what it aims to provide and what it's focused on. It's very clear that they are not acting in good faith and intend to cause harm to it by spreading misinformation. It's quite possible they hold a grudge due to being banned from the channel in the past, which is quite possible, since that kind of behavior would have resulted in a ban. There are some legacy sample apps such as QuickSearchBox (a barebones search app using Google search) which we have listed in our issue tracker as things we need to replace with other apps. Those aren't part of the base OS and exist for testing the OS rather than real world usage. They need to be replaced rather than removed because the functionality will need to be included for compatibility. None of those apps make connections to Google simply by existing or from the user opening them, etc. Using grep to search for Google domains and URLs across a huge source tree with more purposes than building the OS is not a viable way to identify connections that are made by the OS. A huge portion of that code is not used for the OS. A substantial portion consists of tests, sample code and code for other things like the SDK. A major portion is vendored external code (external/) where a small subset that's relevant is being used. For portions that are included, just because it implements functionality does not mean we are including the functionality or enabling it in the build configuration.
strcat 6y ago
The FAQ is accurate. There are no current known issues with what's documented there. Some time ago, we found and fixed an issue in the Vanadium WebView caused by it gaining support for fetching a static file with variations for A/B testing. This is only possible to resolve in the OS because apps do not each ship their own copy of Chromium like Electron apps but rather use the WebView provided and updated by the OS. If there's something undesirable in it, we're in a position to change it. Note that we do not provide an exhaustive list of these kinds of connections for the Vanadium browser once a user opens it and begins using it at this point. It's in an earlier stage of development than GrapheneOS itself. On the other hand, the Vanadium WebView will not make any connections that have not been requested by the apps using it. A normal Chromium WebView would fetch variations. Separately from the default connections by the OS, if you use a carrier choosing to use Google servers for RCS, etc. then you'll also end up with connections to those without disabling the features. That's true outside the Android Open Source Project too. Some carriers host their own services on Google's cloud. There's not much that the OS can do about carriers using their services. Carrier configuration also determines how features like SUPL which provides supplementary location information when location services are enabled. Modern carrier-based calls and texts are data-based which means the OS has to connect to the servers configured by the carrier. That traffic is visible as OS traffic. We plan to add a separate section documenting stuff about carriers but it's beyond the scope of the default connections made by the OS, since it's what happens when you've set it up with a carrier. Our focus in this area right now is on implementing an eSIM activation app to support eSIM in GrapheneOS. It has OS support from AOSP but it doesn't have an activation app since AOSP doesn't include the Google apps and services.

by Youden 6y ago

user3939382 6y ago

I regret that I didn’t do a detailed write up at the time, and that since I didn’t I only have some abstract anecdata to offer but for what it’s worth: A couple years ago I rooted Android (Planet Gemini), installed my own root CA, forced all network through USB-C —> ethernet, connected the ethernet to a physical network tap, and decrypted almost all the traffic. With only a handful of common apps installed the (idle state, no UI interaction) phone-home traffic and telemetry was non-stop. A majority of it was to Google, blocking it made the phone basically non-functional. There were also inexplicable calls to strange Chinese IP addresses that would only emerge every one or two weeks that I couldn’t hunt down the source of and Planet said they didn’t recognize. I want network activity to be 100% correlated with my UI interactions including updates. I feel power users should be given that right and option. Windows and macOS (and sadly Firefox) are also miles away from this but Android was ridiculous. I haven’t tested iOS but I assume it’s about the same.

ThenAsNow 6y ago

I have spent time on the IRC channel and it is clear the founder/project lead (whom I'm not criticizing) has a different idea of what privacy means than what I do. He doesn't necessarily view connections to Google servers that take place without explicit user intention/confirmation as problematic. Based on his strong personality, I did not think it likely any patches I wrote would be accepted by him. Indeed, he thinks it best to "blend in" with other Android traffic. He is also, in my opinion, overworked. I'm looking at my abortive patchset against GrapheneOS from last year, which I never bothered to finish up to post, and will just pick a couple of random samples: packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com) packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers) external/webrtc/webrtc/p2p/stunprober/main.cc (uses a Google STUN server) packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java (calls to the play store) That's a random sampling, not trying to assess for "severity". You can rationalize away each of these individually, but I was at 41 patches when I stopped (including changes that address Google connections that GrapheneOS acknowledges). The cockroach infestation analogy is pretty apt. They are everywhere, and if you try to follow the code to assess for severity, it will be hugely time-consuming, so unless you have a team developing the patches, the safest thing is to pre-emptively patch out. I'm not saying any of these is malicious, my point is there are tons of these kinds of things littering the code. It will be extremely time-consuming to find and cut this stuff out of the base applications and libraries underlying installed applications. And BTW again, this says nothing about SUPL, which is still tracked as an issue about which there isn't a lot of clarity: https://github.com/GrapheneOS/os_issue_tracker/issues/96 https://github.com/GrapheneOS/os_issue_tracker/issues/96 You can also see in that issue thread that the project lead does not see the project as focusing on de-Googling which is, in fact, what many of us want, and are wrongly projecting as a GrapheneOS project goal.

throwawayboise 6y ago
I mean, it almost sounds like you want a phone that doesn't connect to anything. If I may ask, what's the point. Just don't carry a phone.
- monocasa 6y ago
  It sounds like they primarily don't want their phone to connect to Google without asking the user, not that they don't want it to connect to anything. Google has not become the whole internet yet.
  - ThenAsNow 6y ago
    Exactly this. I'm not sure how wanting a device that can connect only as per my requests/configuration requires that I instead be OK with it willy-nilly connecting to whatever it wants.
  - strcat 6y ago
    See https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections which is an accurate list of the default connections in the OS. There are no connections to Google made by default. We offer the option (opt-in) to use their connectivity servers instead of ours, contrary to what the person you're talking about has claimed here. They have made false claims about connectivity checks, DNS, SUPL, WebRTC and other things. They have made false claims about what the project provides, what it aims to provide and what it's focused on. It's very clear that they are not acting in good faith and intend to cause harm to it by spreading misinformation. It's quite possible they hold a grudge due to being banned from the channel in the past, which is quite possible, since that kind of behavior would have resulted in a ban. There are some legacy sample apps such as QuickSearchBox (a barebones search app using Google search) which we have listed in our issue tracker as things we need to replace with other apps. Those aren't part of the base OS and exist for testing the OS rather than real world usage. They need to be replaced rather than removed because the functionality will need to be included for compatibility. None of those apps make connections to Google simply by existing or from the user opening them, etc. Using grep to search for Google domains and URLs across a huge source tree with more purposes than building the OS is not a viable way to identify connections that are made by the OS. A huge portion of that code is not used for the OS. A substantial portion consists of tests, sample code and code for other things like the SDK. A major portion is vendored external code (external/) where a small subset that's relevant is being used. For portions that are included, just because it implements functionality does not mean we are including the functionality or enabling it in the build configuration.

strcat 6y ago

The FAQ is accurate. There are no current known issues with what's documented there. Some time ago, we found and fixed an issue in the Vanadium WebView caused by it gaining support for fetching a static file with variations for A/B testing. This is only possible to resolve in the OS because apps do not each ship their own copy of Chromium like Electron apps but rather use the WebView provided and updated by the OS. If there's something undesirable in it, we're in a position to change it. Note that we do not provide an exhaustive list of these kinds of connections for the Vanadium browser once a user opens it and begins using it at this point. It's in an earlier stage of development than GrapheneOS itself. On the other hand, the Vanadium WebView will not make any connections that have not been requested by the apps using it. A normal Chromium WebView would fetch variations. Separately from the default connections by the OS, if you use a carrier choosing to use Google servers for RCS, etc. then you'll also end up with connections to those without disabling the features. That's true outside the Android Open Source Project too. Some carriers host their own services on Google's cloud. There's not much that the OS can do about carriers using their services. Carrier configuration also determines how features like SUPL which provides supplementary location information when location services are enabled. Modern carrier-based calls and texts are data-based which means the OS has to connect to the servers configured by the carrier. That traffic is visible as OS traffic. We plan to add a separate section documenting stuff about carriers but it's beyond the scope of the default connections made by the OS, since it's what happens when you've set it up with a carrier. Our focus in this area right now is on implementing an eSIM activation app to support eSIM in GrapheneOS. It has OS support from AOSP but it doesn't have an activation app since AOSP doesn't include the Google apps and services.