4 ms·

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

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.
Youden 6y ago
> He doesn't necessarily view connections to Google servers that take place without explicit user intention/confirmation as problematic. I'd just go for his own words [0] since they're so easily available. > Based on his strong personality, I did not think it likely any patches I wrote would be accepted by him. I think it's best to give him a chance rather than assume. From my interactions with him, he seems fairly open to contributions since as you've pointed out, he also seems overworked. > packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com) I think you're talking about [1], which only happens upon explicit user interaction (the user clicking a button to show on a map). > packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers) This code seems to be here [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#issuecomment-511383707 https://github.com/GrapheneOS/os_issue_tracker/issues/96#iss... [1]: https://android.googlesource.com/platform/packages/apps/Gallery/+/refs/heads/master/src/com/android/camera/MenuHelper.java#294 https://android.googlesource.com/platform/packages/apps/Gall... [2]: https://github.com/GrapheneOS/platform_packages_apps_Settings/blob/11/src/com/android/settings/wifi/WifiStatusTest.java https://github.com/GrapheneOS/platform_packages_apps_Setting... [3]: https://github.com/GrapheneOS/platform_packages_apps_Settings/blob/41d4b98e652e13393d39138027dfc9e9c30f43bf/src/com/android/settings/wifi/WifiStatusTest.java#L170-L173 https://github.com/GrapheneOS/platform_packages_apps_Setting... [4]: https://chromium.googlesource.com/external/webrtc/+/HEAD/examples/stunprober/main.cc https://chromium.googlesource.com/external/webrtc/+/HEAD/exa... [5]: https://cs.android.com/search?q=%22stun.l.google.com%22&ss=android%2Fplatform%2Fsuperproject https://cs.android.com/search?q=%22stun.l.google.com%22&ss=a...
strcat 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. 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 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 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 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 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.
strcat 6y ago
> He is also, in my opinion, overworked. It would certainly help if people like yourself were not prolifically spreading misinformation and false claims about the project and myself. Luckily, I am not writing most of the GrapheneOS code at this time. > packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com) Not used. > packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers) This is a developer / debugging UI with ping buttons doing what they say on the tin. > external/webrtc/webrtc/p2p/stunprober/main.cc (uses a Google STUN server) Code is not included in the OS. > packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java The code is not used, and it doesn't do what you say. It's code for creating and sending a link to an app on the Play Store. It isn't code 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 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.

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.

Youden 6y ago

> He doesn't necessarily view connections to Google servers that take place without explicit user intention/confirmation as problematic. I'd just go for his own words [0] since they're so easily available. > Based on his strong personality, I did not think it likely any patches I wrote would be accepted by him. I think it's best to give him a chance rather than assume. From my interactions with him, he seems fairly open to contributions since as you've pointed out, he also seems overworked. > packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com) I think you're talking about [1], which only happens upon explicit user interaction (the user clicking a button to show on a map). > packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers) This code seems to be here [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#issuecomment-511383707 https://github.com/GrapheneOS/os_issue_tracker/issues/96#iss... [1]: https://android.googlesource.com/platform/packages/apps/Gallery/+/refs/heads/master/src/com/android/camera/MenuHelper.java#294 https://android.googlesource.com/platform/packages/apps/Gall... [2]: https://github.com/GrapheneOS/platform_packages_apps_Settings/blob/11/src/com/android/settings/wifi/WifiStatusTest.java https://github.com/GrapheneOS/platform_packages_apps_Setting... [3]: https://github.com/GrapheneOS/platform_packages_apps_Settings/blob/41d4b98e652e13393d39138027dfc9e9c30f43bf/src/com/android/settings/wifi/WifiStatusTest.java#L170-L173 https://github.com/GrapheneOS/platform_packages_apps_Setting... [4]: https://chromium.googlesource.com/external/webrtc/+/HEAD/examples/stunprober/main.cc https://chromium.googlesource.com/external/webrtc/+/HEAD/exa... [5]: https://cs.android.com/search?q=%22stun.l.google.com%22&ss=android%2Fplatform%2Fsuperproject https://cs.android.com/search?q=%22stun.l.google.com%22&ss=a...

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

strcat 6y ago

> He is also, in my opinion, overworked. It would certainly help if people like yourself were not prolifically spreading misinformation and false claims about the project and myself. Luckily, I am not writing most of the GrapheneOS code at this time. > packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com) Not used. > packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers) This is a developer / debugging UI with ping buttons doing what they say on the tin. > external/webrtc/webrtc/p2p/stunprober/main.cc (uses a Google STUN server) Code is not included in the OS. > packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java The code is not used, and it doesn't do what you say. It's code for creating and sending a link to an app on the Play Store. It isn't code 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 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.