Our great sponsors
-
os_issue_tracker
Discontinued Issue tracker for GrapheneOS Android Open Source Project hardening work. Standalone projects like Auditor, AttestationServer and hardened_malloc have their own dedicated trackers. [Moved to: https://github.com/GrapheneOS/os-issue-tracker]
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> 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.
You're misrepresenting what I think and the goals / approach of the project.
> He doesn't necessarily view connections to Google servers that take place without explicit user intention/confirmation as problematic.
That's not accurate at all. Those connections also aren't being made by the OS.
> 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 not sure why you got the impression that useful patches fitting the goals of the project would not be accepted. You say that you aren't criticizing me but at the same time appear to be trying to attack my character and misrepresent my views. Quite strange. It's also interesting that you have a bunch of past comments on this site doing the same, including making personal attacks on me and misrepresenting my views and GrapheneOS.
I do not think that what you're saying adds up.
> 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
Grepping through the source code for Google URLs does not provide a list of connections to Google.
The source tree contains far more than the sources used to build the OS, and not all of the code for the OS is used. It's also configured via build configuration. You could also grep around for Google URLs in a large codebase like the Linux kernel and claim that it makes a ton of undocumented connections to Google but that's not how it works.
> including changes that address Google connections that GrapheneOS acknowledges
There are no default connections to Google servers. I recommend reading https://grapheneos.org/faq#default-connections. Your implication that we are hiding something or unaware of some dark secret doesn't have a basis.
> 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.
That's not accurate. Reviewing a large amount of code is certainly time consuming, but there aren't actually there common changes to be made that you're claiming. You grepped around for Google URLs / domains in the code and then assumed that anywhere those were included must be a connection to Google that's used in the OS. That's really not how it works. Not every Google domain or URL referenced in the code is actually used (especially since large portions of the code are not used for an OS build from the source tree), and very few are used by default.
> 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
SUPL is carrier-specific. The server used is determined by the carrier. It's enabled when location services are active and you're connected to a mobile network if configured that way by the carrier. There has to be a fallback configuration. It's required by law. It has to be possible for SUPL to work for emergency calls even when not connected to a carrier. There is an open issue because we need to do research into it and figure out the best approach to it. We need to choose the best fallback provider, which could very well be Google is there isn't one with a better privacy policy. Hosting it ourselves as we do the time server and connectivity check server isn't necessarily realistic. It's not enough to just use some public cell id database.
> 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.
The goal of the project is offering great privacy and security. The focus of the project is implementing a bunch of technical improvements to achieve that goal. When we switched to the GrapheneOS connectivity check server, we made sure that we provided a way to opt-in to using the standard URLs in order to blend in with other devices as explained in https://grapheneos.org/faq#default-connections. Similarly, as explained there, we added a way to fully disable network time updates to avoid standing out as a GrapheneOS device based on using our HTTPS-based time update approach. Most devices do not make network time update requests since they get it from the mobile network, so blending in for that is easy.
It is not a "de-Googling" project because that would not give us any substantial work to do. AOSP does not have Google apps and services. It uses Google servers as a placeholder / default for certain things where a provider has to be chosen like the connectivity (captive portal) checks and time update server.
You claim elsewhere that Google DNS is used which isn't even true for AOSP. It uses the network-provided DNS servers. GrapheneOS also changes the fallback servers, so that claim is so far from reality. Again, I strongly recommend reading https://grapheneos.org/faq#default-connections and using more than grep and unverified assumptions to find things that need to be changed. You actually have to check if the code is used and if that value is actually used. For example, why reference the WebRTC reference implementation? The repositories in external/ are externally developed projects often included to use a small part of them or a tool they provide. A Google URL in source code that's part of the overall source tree does not mean there is a connection to Google being made by the OS.
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 here is the PR that adds in a "minimal" flavor without the Google features.