os-issue-tracker

can't be used. They can still be used by apps and provided by apps to other apps such as how it works with the Play services location APIs. We also aren't going to be sending real time location information to that kind of network service, especially if it's a proprietary service from Apple/Google/Mozilla rather than something we can self-host. We don't particularly want to host a server receiving that kind of sensitive data though. We want a robust and secure local implementation respecting the OS security model for location providers. We'll need to set up generating databases for different regions, signing them and hosting them on a server. A new client needs to be developed for this. > At the same time they use SeedVault which is developed by Calyx. I guess they need to add some notes on this into their FAQ. GrapheneOS came up with the overall design/concept of SeedVault and it was implemented by a member of our community long before CalyxOS existed. They started funding development work on it but they didn't create it and it isn't inherently their project. We fully intend to fund development on improving backups and will be splitting away from what SeedVault has become for various reasons including their actions against us. The developer they're funding to work on SeedVault is NOT hostile towards us but their involvement is concerning to us nonetheless. > So, while I think that Graphene has a lot of good properties (e.g. sandboxed Play Services are MUCH better than microg) and is somehow superior to Calyx https://grapheneos.org/features explains what it provides. > I won't recommend Graphene to a regular user who is privacy concerned but doesn't want to trade too much for privacy It has much broader app compatibility, so what are you trading away for better privacy and security? Is this entirely about the OS itself not feeding your location to Mozilla to get back a location estimate based on their proprietary Wi-Fi data and the openly available cellular data? The cellular data would be put to much better use by via regional databases distributed from a first party server, with a first party location service locally consuming them while respecting the security model for this. > For such people CalyxOS (probably a self-build) looks like a better option. All simply because we don't do include a network location service? Really? > Also there is some strange conflict between Graphene and Calyx, for some reason unknown to me Graphene guys consider Calyx as "malicious project" (see https://github.com/GrapheneOS/os-issue-tracker/issues/632#is...). It comes down to the CalyxOS project and community spreading misinformation and attacks on GrapheneOS and GrapheneOS developers across platforms along with engaging in substantial harassment. Our project members have been regularly impersonated by clearly fake sockpuppet accounts too, which were then used to engage in ridiculous false flag attacks such as https://github.com/bromite/bromite/discussions/1186 and the Monero incident brought up below although with the spin that we did something wrong when we were impersonated. It has become ridiculous, with this misinformation spread whenever GrapheneOS is brought up and with our developers subjected to substantial bullying and harassment. You're a member of the CalyxOS community doing exactly the kind of thing that has led to this situation, including what you did on our issue tracker. It may seem small, but you started a whole pile on from the usual suspects lying about it here and you're representing CalyxOS whether you like it or not. They welcome you in their community, as they do others, and encourage you to attack us. Nick himself has directly engaged in vicious bullying and harassment.

I won't recommend Graphene to a regular user who is privacy concerned but doesn't want to trade too much for privacy. For such people CalyxOS (probably a self-build) looks like a better option.

tackle privacy concerns today, but most of the 2B+ Android users don't really want to root devices let alone flash ROMs. Most Chinese OEMs (Vivo, Oppo, OnePlus, Realme, Xiaomi) do bundle in (pretty decent though limited) firewalls but they do not let one visualize or block individual network requests. It'd be quite sometime before the Android/Fuchsia-iOS duopoly is displaced from its perch, but technology-wise, my longer-term hopes are pinned on Linux-based phones (PINE64, Librem) for now. Of course, laws and regulations upholding digital privacy are the real end-game, and it remains to be seen how much headway is made on that front in the coming decade. [0] https://youtu.be/e9yK1QndJSM?t=1261 [1] https://github.com/GrapheneOS/os-issue-tracker/issues/389 [2] https://web.archive.org/web/20110506050715/http://www.whispe... [3] https://security.googleblog.com/search/label/android

for accessing it. > 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 It is clear to us and I've explained it here. There is nothing that needs to be rationalized away but rather you grepped through the code and your confirmation bias + lack of research led you to make bad assumptions. You didn't submit issue reports, patches or even make an attempt to talk about this. If you had, it could have been explained that you were making mistakes. Perhaps you could have done something useful instead of wasting your time. Perhaps you could have informed yourself instead of leading yourself astray with your confirmation bias and assumptions. It doesn't really matter now. Please stop spreading misinformation about GrapheneOS and myself though. Leave us out of it. I think it says a lot that your post was the highest voted and that spreading misinformation and making false claims is how you folks choose to operate. You do not do useful work, but rather try to hurt projects that do, in order to promote something else. Maybe you should promote it based on the merits instead of with false claims about us. I'm not sure why you're comparing our privacy and security hardening work with a hardware project which it could be used on in the first place. If a 'strong personality' means an intolerance for dishonesty then that's certainly the case. Unfortunately, certain companies focused entirely on marketing / branding take the approach of spreading misinformation about others because they do not have any substance themselves. Producing an incredibly insecure product but branding it as secure and attacking others is par for the course. That's pretty much the whole privacy and security industry. GrapheneOS is a non-profit open source project and we'll continue doing our work regardless of these kinds of continued attempts to spread misinformation about it and cause harm to us. Companies and products will come and go. We'll still be working on genuine privacy and security improvements across the software and hardware world in one way or another. We are not trying to sell a product and we don't have this motivation to tear down others with misinformation. If it's bad, then we'll say so. Our documentation is very honest about what we provide and what we don't provide in the various projects we work on. It is very open about the trade-offs of the design choices, etc. We're confident that the project will succeed on the merits without needing to make up a lot of BS about it and about others. We intend to work with hardware partners and others with the same kinds of goals and approach: providing a high level of privacy and security alongside usability, with an approach that's open and honest. We won't attach our name to a device that did not meet a high level of privacy and security by shipping a modern, properly configured SoC for production use with proper support for firmware, etc. for years and all the standard hardware security features (verified boot, HSM-based attestation, HSM-based keystore, strong hardware encryption / key derivation support, proper IOMMUs, modern exploit mitigations, and all the other stuff we expect). We'll happily include minor bonuses like a Sensors Off kill switch that truly works as a mitigation for a device compromise based on a clear threat model for that (i.e. if it's meant to do something like stopping audio recording, then the speakers and all the sensors usable for that have to be dealt with too). We're 100% open to working with a vendor sharing those kinds of goals.

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.

[2] now and is only called as part of an on-click handler [3], so again, requires explicit user interaction. As far as I know, there isn't even a way to access the screen that triggers this. I did it manually (adb shell am start -n com.android.settings/.wifi.WifiStatusTest) and the UI makes it clear that clicking the button will cause network traffic to go to "www.google.com", as that hostname is listed explicitly in the UI. > external/webrtc/webrtc/p2p/stunprober/main.cc I think you're talking about [4], which is example code. When I was searching for it, I stubmled across Google's search tool [5], which I used to search for other references to those hostnames. There don't appear to be any outside of example code and unit tests. > packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java (calls to the play store) If you follow the code further, it appears that no network traffic is sent to the Play Store. The code just creates a Play Store URL for an app package, presumably when you try to share an app with someone over NFC. > 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. But what exactly is everywhere? It'd be nice to get rid of the code you've mentioned but there are no connections to Google going out without user interaction. I'm not convinced that there's a problem here to be fixed. [0]: https://github.com/GrapheneOS/os_issue_tracker/issues/96#iss... [1]: https://android.googlesource.com/platform/packages/apps/Gall... [2]: https://github.com/GrapheneOS/platform_packages_apps_Setting... [3]: https://github.com/GrapheneOS/platform_packages_apps_Setting... [4]: https://chromium.googlesource.com/external/webrtc/+/HEAD/exa... [5]: https://cs.android.com/search?q=%22stun.l.google.com%22&ss=a...

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 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.