os_issue_tracker

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] (by GrapheneOS)

Os_issue_tracker Alternatives

Similar projects and alternatives to os_issue_tracker based on common topics and language

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better os_issue_tracker alternative or higher similarity.

os_issue_tracker reviews and mentions

Posts with mentions or reviews of os_issue_tracker. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-04-09.
  • I have been FACEBOOKED without ever owning a Facebook account. How could I have avoided it? Facebook needs to pay for this.
    2 projects | /r/privacy | 9 Apr 2021
    I did not say it is Google-free, I said that it can be made as Google-free as you want it to be without too much difficulty. In what way is Graphene more Google-free than LineageOS? [Graphene advertises]("No Google apps or services") - LineageOS doesn't have any either, by itself. If you're talking about connectivity check / captive portal detection, LineageOS can easily be switched away from Google's servers. Are you talking about A-GPS / SUPL? I'm not sure what Graphene does these days, but it has apparently used Google in the past. (Note also the statement here that "The project does not aim to avoid Google services in particular but rather privacy issues in general."
  • Pine64 Februrary Update: Show and Tell
    5 projects | news.ycombinator.com | 15 Feb 2021
    > 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#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...

    5 projects | news.ycombinator.com | 15 Feb 2021
    > 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

    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.

    5 projects | news.ycombinator.com | 15 Feb 2021
    > 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.

    5 projects | news.ycombinator.com | 15 Feb 2021
    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, 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 there 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.

  • GrapheneOS doubts (compartmentalization, PWA... )
    3 projects | /r/privacytoolsIO | 25 Dec 2020
    See https://github.com/GrapheneOS/os_issue_tracker/issues/88 about a feature that's planned to make the user experience better by adding support for displaying the lockscreen censored version of notifications from other profiles if desired.
  • A note from our sponsor - WorkOS
    workos.com | 29 Mar 2024
    The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning. Learn more →

Stats

Basic os_issue_tracker repo stats
9
101
1.0
almost 3 years ago
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com