13 ms·

This team is doing "the lord's work". Anyone thinking you can use a "de-Googled" Android distribution, like GrapheneOS, CalyxOS, or LineageOS and actually be d

This team is doing "the lord's work". Anyone thinking you can use a "de-Googled" Android distribution, like GrapheneOS, CalyxOS, or LineageOS and actually be de-Googled in anything but the most superficial way (as I once thought possible) should actually grab the sources and examine them. Android is written with deep and casual connections to Google's systems all throughout the codebase. It's like a cockroach infestation. There's no concept of anyone potentially not wanting to connect to their services regardless of how trivial the "value add". It will take dozens of patches to cut these out, often breaking functionality. To be fair, I haven't looked at /e/ sources to see if they've done all this, but I would be surprised if they got all of them. Then of course, the patches need to be maintained and new ones written as Google continues to relentlessly add more integration points with their servers in subsequent Android updates. Just to name a few: SUPL, WebRTC probing, automatic previews of YouTube in the Messenger, Google maps lookups in Dialer and in Photos, myriad connectivity checks, etc. And this doesn't even consider the unending whack-a-mole that gets played for Chromium privacy by projects like Bromite and un-Googled Chromium. After going down this rabbit hole, it became clear to me the only way to win is to not play. If the Pine64 ecosystem gets to the point of working as well as the Linux desktop (been daily driving some KDE on top of GNU/Linux for 10+ years, with only one major issue due to buggy drivers), it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers.

londons_explore 6y ago
Removing them all is a simple matter of blocking DNS lookups for Google DNS addresses. There are only ~10 hostnames to block. Sure, some features will break, but it won't be any worse than being disconnected from the internet.
- hobofan 6y ago
  Ah yes, the smartphone, the invention that isn't basically entirely based around the concept of being connected to the internet.
  - Erlich_Bachman 6y ago
    I don't see what is so hard to understand. One thing is internet connections that are initiated by user, or in the background from the apps that user voluntarily installed and wants to provide them a specific services. Another thing is when a phone has a bunch of add-on adware (in some cases spyware) ,built-in into the phone, without user's knowledge, without user's consent and most of the time even ability to choose. Adware chosen by the manufacturer or provider, that is serving their purposes. That is a clear existing distinction. It has nothing to do with being a smartphone or having an internet connection in general, or using a smartphone for internet-related tasks.
    - hobofan 6y ago
      The parent comment makes it seem like blocking those Google services will brick all online functionality of the phone (I don't know if that's the case but it wouldn't surprise me), and proposing that as a viable solution. I'm all for de-googling (and de-OEMing) our devices, but giving up all online functionality is not a viable alternative.
- ThenAsNow 6y ago
  This would take out a certain number of them, but there are hardcoded IP references (e.g., to their DNS servers), use of Google systems for things like NTP, and so on. These are findable and patchable, but you will still be building your own image to maintain as most of these are not exposed as knobs in the Android UI. And of course still no answer for SUPL. Going transiently without an internet connection is common, but going semi-permanently without one is not what these systems are designed to do well. Also, is this list of ~10 hostnames readily available somewhere?
  - FDSGSG 6y ago
    >use of Google systems for things like NTP GrapheneOS doesn't use NTP at all, where are you getting your information?
- ocdtrekkie 6y ago
  Google has a solution for this. By using DNS-over-HTTPS, Google can start deploying software that communicates solely with it's own DNS servers over encrypted connections.
  - teekert 6y ago
    I don't know why you are down voted but this is exactly why pihole and adguard have no effect on many devices.
- teddyh 6y ago
  DNS blocking will very soon, if not already, cease to work, with the arrival of DoH.
bisby 6y ago
There are many apps which are very sad when you use the F-Droid version vs the Play store version. Namely push notifications, or in some cases, mere existence. Element.io app for a while there (at least when it was riot.im) was using polling to check for new messages instead of push notifications. Because no google means no google cloud messaging (or firebase, or whatever it is now). Home Assistant is great and open source, but they refuse to publish to F-Droid over a name dispute from years ago (someone had an unofficial app and had refused to relinquish the name and F-Droid let the unofficial app keep it). Which means if you want the home assistant app to control your lights... Play store. However. My ubports pinephone which is running Arch is missing a few key features. Performance is one. And I can't get the replacement mainboard that has the extra RAM because it's been out of stock for the past few months. And the other is Wi-Fi calling. I live in an area with poor reception and need wifi calling.I just flashed my android phone back from LineageOS because lineage wifi calling wasnt working. I really really really want pinephones and librem 5s to work out. I acknowledge it is hard "lord's work" they are doing. but it's still not quite there yet. We're getting close enough that within a few years, I'll be using linux as my daily driver, even if I don't feel comfortable recommending it to my grandma.
- zeta0134 6y ago
  Could you elaborate on the Home Assistant thing? I'm running that app from the F-droid store right now, and I sorta blindly assumed it was the official one. Now I'm worried; is this some outdated clone?
  - bisby 6y ago
    https://github.com/home-assistant/android/issues/42 https://github.com/home-assistant/android/issues/42 > We have no interest in maintaining a branch of the app that doesn't depend on any proprietary services. Developers explain why they wouldn't (naming issues, and "the point of the android app vs just using a browser is to have the location tracking, which requires google services") and then the thread was closed. And then I stopped following the issue and begrudgingly installed from Play store (I'm not de-googled, because like the GP mentioned, it's very hard to do even if you think you have done it, so in some cases I don't even try). There are a LOT of locked threads in their github issues on the same topic. The F-Droid version appears to be a build of the appropriate repo, and the description says "This is the minimal flavor that does not have location tracking or notifications" (so the 2 things mentioned previously, location and push notifications are hard to do without Google). https://github.com/home-assistant/android/pull/682 https://github.com/home-assistant/android/pull/682 here is the PR that adds in a "minimal" flavor without the Google features. I stand corrected. A bunch of neat things have happened since I stopped paying attention, and I'm pretty proud of the HA team for getting around to resolving this amicably, even if they were a bit rough about it in the beginning. edit: ... I just realized I installed Home Assistant from F-Droid when I just re-imaged my phone this weekend. Without even realizing it.
rektide 6y ago
This rather is the important work I agree. Personally I'm not that afraid of Google nor what they are up to. I think they strike a decent balance. I tire of the polemics against them. What I see as critically important, as absolutely key to a vital, alive civilization is progress & exploration. Android is on version 11, and at this point, the mold has set. This world where you buy a phone, run the same OS you've always run, and wait 3 years until you have to throw it out (because it's running an antique kernel & security updates are ending) is an unexciting one, it is less than what human potential has available. PinePhone is one of the forebearers of a better future. Which future? Any of them, all of them. The future that is coming that doesn't look exactly like today that doesn't look exactly like 5 years ago. The future where hardware is supported for more than 3 years. The future where there are multiple different interfaces & operating systems available for devices. The future where people other than giant companies have a chance to build cool hardware. This one is a nod too to Quartz, their new/upcoming very-competent, expandable mid-range option, which they explicitly target as a featureful development kit to make cool hardware on. Battery charging, 12V, ePaper, camera, display, USB, PCIe,... just a lot of good robust well built features. On an open source board. The fact that everyone is so up in arms against Google disguises what a boring, out-of-our-hands, staid, unchanging future we've been lead in to. Google is not the focus. The actual agents that we should be looking at, attending to, are ourselves. We've still spinning endless stories & selling fear of some other, but it is our own slumbering, our own lack of control & competency & creative freedom that defines the last decade of communicative capitalism taking over. PinePhone & Pine64 just want the individual human spirit to have a chance again. (And to band together as they may with other spirited journeyers.) Excited as well by their last bit in the update, embracing LoRaWAN. Not just opening the door to innovation in cellular phones, but blowing open decentralized, user-empowering new means of communication.
- teekert 6y ago
  Yes LoraWAN is so cool, with a couple of enthusiasts you can cover a city with an open network that can handle small messages and many sensors that run for years on batteries.
- asoneth 6y ago
  > What I see as critically important, as absolutely key to a vital, alive civilization is progress & exploration ... Which future? Any of them, all of them. Agreed. I don't like to live in the country of giants because their sheer scale means they end up crushing the delicate innovation that sprouts up around them, usually more out of indifference than actual malice. Depending on your predilections you can pledge fealty or fight them but it's also reasonable to find the niches where the giants don't fit and new ecosystems are able to flourish.
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.
zozbot234 6y ago
> Android is written with deep and casual connections to Google's systems all throughout the codebase. It's like a cockroach infestation. There's no concept of anyone potentially not wanting to connect to their services regardless of how trivial the "value add". Par for the course in embedded development. Tuere are plenty of bad things to be said about AOSP, but it's still way better than any of its Linux-based forerunners. Remember the OpenMoko? (Of course, this is not to say that further improvement is not possible! So, I might well agree with the gist of your comment from that POV.)
- ThenAsNow 6y ago
  > Par for the course in embedded development. It may be, but I don't don't see why it must be that way any more than it must be that way on the desktop. At least give me full exposed control over whether and what connections it makes even if the defaults are what they are now!* I can live with that, if there is graceful degradation. Android is not written with the idea that anyone should have that kind of control over their own device. *I get that Google doesn't owe this to anybody, which leads back to the need for a privacy-first/RYF type of phone HW and SW.
1vuio0pswjnm7 6y ago
"There's no concept of anyone potentially not wanting to connect to their services regardless of how trivial the "value add"." "If the Pine64 ecosystem gets to the point of working as well as the Linux desktop , it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers." There's a value add in not connecting to their services. Who pays the cost of those Google-initiated data transfers to their servers. As an end user, I do not wish to donate the use of my internet subscription and network to a company with billions in cash on hand.
strcat 6y ago
I'm the lead developer of GrapheneOS. The default connections made by GrapheneOS are entirely documented at https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections. No connections to Google are made by default. This is not the result of purging connections from the source code. It's very close to the default state of the Android Open Source Project. Google services are implemented as part of Google Play services. The only way that you would get the impression that there are many connections to Google in the source code is if you look at the test cases, sample code and unused functionality that's not enabled by default. Once you've inserted a SIM card and started using a carrier, there will also be connections for supporting the carriers. Some of those carriers use Google services themselves regardless of which device or OS you choose to run. > Just to name a few: SUPL, WebRTC probing, automatic previews of YouTube in the Messenger, Google maps lookups in Dialer and in Photos, myriad connectivity checks, etc. No SUPL connections are made by GrapheneOS on the supported devices. SUPL is carrier-dependent. The connections are made by the radio based on the carrier configuration. Using Google's service is one of the options. This is part of location services and isn't enabled by default. It's required by regulations to have support for it when making emergency calls, but not beyond that. The configuration is fully in our control. We haven't chosen how we want to approach carriers without their own setup for it. It does have to use something in that case, just like the fallback DNS servers, particularly since this needs to work for emergency calls. Which implementation would you prefer to have as the fallback? The connectivity checks use our servers by default. It is opt-in to use the standard servers to blend in with other devices. That is needed to avoid being trivially identified as a GrapheneOS user to the network, which is why we offer it as an option and document it in https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections. The rest of this is inaccurate too. You're mixing talking about the Android Open Source Project with Google apps and Play services which are not included in it. You're also referring to test cases, sample code and unused code including in AOSP sample apps and the substantial amounts of the source tree that are present for development or opt-in inclusion. Only a fraction of the source tree is actually used to build the OS. The source tree is also used for the SDK and a bunch of SDK packages among other things. You cannot simply search for a URL in the source code and make the assumption that it implies there is a connection to Google in the OS. That's not how it works. > After going down this rabbit hole, it became clear to me the only way to win is to not play. If the Pine64 ecosystem gets to the point of working as well as the Linux desktop (been daily driving some KDE on top of GNU/Linux for 10+ years, with only one major issue due to buggy drivers), it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers. Pine64 is a hardware company. You can run an Android Open Source Project derivative just as you can run an OS not based on the Android Open Source Project on another device. As a final note, I would like to point that the user ThenAsNow has a clear history of spreading misinformation and dishonest claims about GrapheneOS on this website. They have made false claims about the focus and goals of the project, along with presenting many objectively untrue facts about it. They've made attacks on the developers. I'm quite curious what their username is elsewhere because this kind of duplicitous behavior and attempt to undermine the project with misinformation is definitely not acceptable for someone supposedly participating in our community. They have repeatedly made these false and baseless claims on multiple occasions. They claim to have done research and worked on it but at most they've glanced around at the source code and made incorrect assumptions about it.

londons_explore 6y ago

Removing them all is a simple matter of blocking DNS lookups for Google DNS addresses. There are only ~10 hostnames to block. Sure, some features will break, but it won't be any worse than being disconnected from the internet.

hobofan 6y ago
Ah yes, the smartphone, the invention that isn't basically entirely based around the concept of being connected to the internet.
- Erlich_Bachman 6y ago
  I don't see what is so hard to understand. One thing is internet connections that are initiated by user, or in the background from the apps that user voluntarily installed and wants to provide them a specific services. Another thing is when a phone has a bunch of add-on adware (in some cases spyware) ,built-in into the phone, without user's knowledge, without user's consent and most of the time even ability to choose. Adware chosen by the manufacturer or provider, that is serving their purposes. That is a clear existing distinction. It has nothing to do with being a smartphone or having an internet connection in general, or using a smartphone for internet-related tasks.
  - hobofan 6y ago
    The parent comment makes it seem like blocking those Google services will brick all online functionality of the phone (I don't know if that's the case but it wouldn't surprise me), and proposing that as a viable solution. I'm all for de-googling (and de-OEMing) our devices, but giving up all online functionality is not a viable alternative.
ThenAsNow 6y ago
This would take out a certain number of them, but there are hardcoded IP references (e.g., to their DNS servers), use of Google systems for things like NTP, and so on. These are findable and patchable, but you will still be building your own image to maintain as most of these are not exposed as knobs in the Android UI. And of course still no answer for SUPL. Going transiently without an internet connection is common, but going semi-permanently without one is not what these systems are designed to do well. Also, is this list of ~10 hostnames readily available somewhere?
- FDSGSG 6y ago
  >use of Google systems for things like NTP GrapheneOS doesn't use NTP at all, where are you getting your information?
ocdtrekkie 6y ago
Google has a solution for this. By using DNS-over-HTTPS, Google can start deploying software that communicates solely with it's own DNS servers over encrypted connections.
- teekert 6y ago
  I don't know why you are down voted but this is exactly why pihole and adguard have no effect on many devices.
teddyh 6y ago
DNS blocking will very soon, if not already, cease to work, with the arrival of DoH.

bisby 6y ago

There are many apps which are very sad when you use the F-Droid version vs the Play store version. Namely push notifications, or in some cases, mere existence. Element.io app for a while there (at least when it was riot.im) was using polling to check for new messages instead of push notifications. Because no google means no google cloud messaging (or firebase, or whatever it is now). Home Assistant is great and open source, but they refuse to publish to F-Droid over a name dispute from years ago (someone had an unofficial app and had refused to relinquish the name and F-Droid let the unofficial app keep it). Which means if you want the home assistant app to control your lights... Play store. However. My ubports pinephone which is running Arch is missing a few key features. Performance is one. And I can't get the replacement mainboard that has the extra RAM because it's been out of stock for the past few months. And the other is Wi-Fi calling. I live in an area with poor reception and need wifi calling.I just flashed my android phone back from LineageOS because lineage wifi calling wasnt working. I really really really want pinephones and librem 5s to work out. I acknowledge it is hard "lord's work" they are doing. but it's still not quite there yet. We're getting close enough that within a few years, I'll be using linux as my daily driver, even if I don't feel comfortable recommending it to my grandma.

zeta0134 6y ago
Could you elaborate on the Home Assistant thing? I'm running that app from the F-droid store right now, and I sorta blindly assumed it was the official one. Now I'm worried; is this some outdated clone?
- bisby 6y ago
  https://github.com/home-assistant/android/issues/42 https://github.com/home-assistant/android/issues/42 > We have no interest in maintaining a branch of the app that doesn't depend on any proprietary services. Developers explain why they wouldn't (naming issues, and "the point of the android app vs just using a browser is to have the location tracking, which requires google services") and then the thread was closed. And then I stopped following the issue and begrudgingly installed from Play store (I'm not de-googled, because like the GP mentioned, it's very hard to do even if you think you have done it, so in some cases I don't even try). There are a LOT of locked threads in their github issues on the same topic. The F-Droid version appears to be a build of the appropriate repo, and the description says "This is the minimal flavor that does not have location tracking or notifications" (so the 2 things mentioned previously, location and push notifications are hard to do without Google). https://github.com/home-assistant/android/pull/682 https://github.com/home-assistant/android/pull/682 here is the PR that adds in a "minimal" flavor without the Google features. I stand corrected. A bunch of neat things have happened since I stopped paying attention, and I'm pretty proud of the HA team for getting around to resolving this amicably, even if they were a bit rough about it in the beginning. edit: ... I just realized I installed Home Assistant from F-Droid when I just re-imaged my phone this weekend. Without even realizing it.

rektide 6y ago

This rather is the important work I agree. Personally I'm not that afraid of Google nor what they are up to. I think they strike a decent balance. I tire of the polemics against them. What I see as critically important, as absolutely key to a vital, alive civilization is progress & exploration. Android is on version 11, and at this point, the mold has set. This world where you buy a phone, run the same OS you've always run, and wait 3 years until you have to throw it out (because it's running an antique kernel & security updates are ending) is an unexciting one, it is less than what human potential has available. PinePhone is one of the forebearers of a better future. Which future? Any of them, all of them. The future that is coming that doesn't look exactly like today that doesn't look exactly like 5 years ago. The future where hardware is supported for more than 3 years. The future where there are multiple different interfaces & operating systems available for devices. The future where people other than giant companies have a chance to build cool hardware. This one is a nod too to Quartz, their new/upcoming very-competent, expandable mid-range option, which they explicitly target as a featureful development kit to make cool hardware on. Battery charging, 12V, ePaper, camera, display, USB, PCIe,... just a lot of good robust well built features. On an open source board. The fact that everyone is so up in arms against Google disguises what a boring, out-of-our-hands, staid, unchanging future we've been lead in to. Google is not the focus. The actual agents that we should be looking at, attending to, are ourselves. We've still spinning endless stories & selling fear of some other, but it is our own slumbering, our own lack of control & competency & creative freedom that defines the last decade of communicative capitalism taking over. PinePhone & Pine64 just want the individual human spirit to have a chance again. (And to band together as they may with other spirited journeyers.) Excited as well by their last bit in the update, embracing LoRaWAN. Not just opening the door to innovation in cellular phones, but blowing open decentralized, user-empowering new means of communication.

teekert 6y ago
Yes LoraWAN is so cool, with a couple of enthusiasts you can cover a city with an open network that can handle small messages and many sensors that run for years on batteries.
asoneth 6y ago
> What I see as critically important, as absolutely key to a vital, alive civilization is progress & exploration ... Which future? Any of them, all of them. Agreed. I don't like to live in the country of giants because their sheer scale means they end up crushing the delicate innovation that sprouts up around them, usually more out of indifference than actual malice. Depending on your predilections you can pledge fealty or fight them but it's also reasonable to find the niches where the giants don't fit and new ecosystems are able to flourish.

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.

zozbot234 6y ago

> Android is written with deep and casual connections to Google's systems all throughout the codebase. It's like a cockroach infestation. There's no concept of anyone potentially not wanting to connect to their services regardless of how trivial the "value add". Par for the course in embedded development. Tuere are plenty of bad things to be said about AOSP, but it's still way better than any of its Linux-based forerunners. Remember the OpenMoko? (Of course, this is not to say that further improvement is not possible! So, I might well agree with the gist of your comment from that POV.)

ThenAsNow 6y ago
> Par for the course in embedded development. It may be, but I don't don't see why it must be that way any more than it must be that way on the desktop. At least give me full exposed control over whether and what connections it makes even if the defaults are what they are now!* I can live with that, if there is graceful degradation. Android is not written with the idea that anyone should have that kind of control over their own device. *I get that Google doesn't owe this to anybody, which leads back to the need for a privacy-first/RYF type of phone HW and SW.

1vuio0pswjnm7 6y ago

"There's no concept of anyone potentially not wanting to connect to their services regardless of how trivial the "value add"." "If the Pine64 ecosystem gets to the point of working as well as the Linux desktop , it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers." There's a value add in not connecting to their services. Who pays the cost of those Google-initiated data transfers to their servers. As an end user, I do not wish to donate the use of my internet subscription and network to a company with billions in cash on hand.

strcat 6y ago

I'm the lead developer of GrapheneOS. The default connections made by GrapheneOS are entirely documented at https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections. No connections to Google are made by default. This is not the result of purging connections from the source code. It's very close to the default state of the Android Open Source Project. Google services are implemented as part of Google Play services. The only way that you would get the impression that there are many connections to Google in the source code is if you look at the test cases, sample code and unused functionality that's not enabled by default. Once you've inserted a SIM card and started using a carrier, there will also be connections for supporting the carriers. Some of those carriers use Google services themselves regardless of which device or OS you choose to run. > Just to name a few: SUPL, WebRTC probing, automatic previews of YouTube in the Messenger, Google maps lookups in Dialer and in Photos, myriad connectivity checks, etc. No SUPL connections are made by GrapheneOS on the supported devices. SUPL is carrier-dependent. The connections are made by the radio based on the carrier configuration. Using Google's service is one of the options. This is part of location services and isn't enabled by default. It's required by regulations to have support for it when making emergency calls, but not beyond that. The configuration is fully in our control. We haven't chosen how we want to approach carriers without their own setup for it. It does have to use something in that case, just like the fallback DNS servers, particularly since this needs to work for emergency calls. Which implementation would you prefer to have as the fallback? The connectivity checks use our servers by default. It is opt-in to use the standard servers to blend in with other devices. That is needed to avoid being trivially identified as a GrapheneOS user to the network, which is why we offer it as an option and document it in https://grapheneos.org/faq#default-connections https://grapheneos.org/faq#default-connections. The rest of this is inaccurate too. You're mixing talking about the Android Open Source Project with Google apps and Play services which are not included in it. You're also referring to test cases, sample code and unused code including in AOSP sample apps and the substantial amounts of the source tree that are present for development or opt-in inclusion. Only a fraction of the source tree is actually used to build the OS. The source tree is also used for the SDK and a bunch of SDK packages among other things. You cannot simply search for a URL in the source code and make the assumption that it implies there is a connection to Google in the OS. That's not how it works. > After going down this rabbit hole, it became clear to me the only way to win is to not play. If the Pine64 ecosystem gets to the point of working as well as the Linux desktop (been daily driving some KDE on top of GNU/Linux for 10+ years, with only one major issue due to buggy drivers), it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers. Pine64 is a hardware company. You can run an Android Open Source Project derivative just as you can run an OS not based on the Android Open Source Project on another device. As a final note, I would like to point that the user ThenAsNow has a clear history of spreading misinformation and dishonest claims about GrapheneOS on this website. They have made false claims about the focus and goals of the project, along with presenting many objectively untrue facts about it. They've made attacks on the developers. I'm quite curious what their username is elsewhere because this kind of duplicitous behavior and attempt to undermine the project with misinformation is definitely not acceptable for someone supposedly participating in our community. They have repeatedly made these false and baseless claims on multiple occasions. They claim to have done research and worked on it but at most they've glanced around at the source code and made incorrect assumptions about it.