5 ms·

Ask HN: Why did anti-FOSS move by GrapheneOS not receive more attention?

• strcat 4y ago
  Using GPLv2-only licensing to prevent a GPLv3 project from taking our code while disallowing us from using their code (since we can't use GPLv3) is hardly anti-FOSS. GrapheneOS can't use GPLv3 for Vanadium because it's incompatible with the WebView being loaded into other applications and GPLv3 has restrictions which would result in GrapheneOS being less free, by disallowing valid usage of GrapheneOS to make devices with an immutable root of trust. We want GrapheneOS to be friendly to people making downstream projects/products based on it and therefore stick to permissive licenses and GPLv2. GPLv2 is an open source license. We continued allowing them to take our code and continued contributing to their project ourselves despite the general inability to use Bromite's code. We already didn't find the situation to be fair. There are also issues with proper attribution not being given for our code and the downplaying of the impact of our contributions. For example, a contributor to Vanadium wrote a new ad-blocking implementation which was adopted by Bromite before it was ready for Vanadium, which led to a negative impact on development of the feature for Vanadium. Almost no credit is given for the stuff submitted by GrapheneOS project members / contributors to Bromite. It's actively downplayed. Bromite began working with people involved in a severe misinformation and harassment campaign directed at GrapheneOS developers. Combined with the inability to use their code due to GPLv3, we chose to change our licensing. This was done in advance of substantial work that's going to be done on Vanadium. Having our code taking by a project not giving us proper credit and not allowing us to use their work in return was having an actively negative effect on Vanadium development. Personally, I think engaging in spreading misinformation about open source projects across platforms including via sockpuppet accounts like this one along with harassment and libel targeting our project members is extremely anti-open-source. GrapheneOS does not spread misinformation about other projects this way, and we don't tolerate our community members doing it either, and similarly don't tolerate them engaging in harassment or libel.
  • strcat 4y ago
    Separately from this, it's a misconception that CalyxOS and GrapheneOS are similar projects or that they're working on similar things. They are not. GrapheneOS is a hardened OS with substantial privacy and security improvements: https://grapheneos.org/features https://grapheneos.org/features CalyxOS is not a hardened OS. It substantially reduces security. It recently went 2 months not shipping standard security patches. Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer: https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach. https://blog.privacyguides.org/2022/04/21/grapheneos-or-calyxos/ https://blog.privacyguides.org/2022/04/21/grapheneos-or-caly... is a 3rd party article explaining some of the substantial differences between GrapheneOS and CalyxOS. It's a common misconception that they're similar. CalyxOS is far more similar to LineageOS than GrapheneOS. There are many other alternate OSes available. https://privsec.dev/posts/android/choosing-your-android-based-operating-system/ https://privsec.dev/posts/android/choosing-your-android-base... is another article about privacy and security differences between alternative Android-based operating systems. Talks about other alternate operating systems including DivestOS. Unlike most content, these are based on real experience and technical details.
    • jtode 4y ago
      This seems like a pretty good couple of answers to OP's question.
    • throwaway_graph 4y ago
      I said that the goal of the projects is the same. It seems they're not equally effective in their efforts of reaching that goal, but that's besides the point.
      • strcat 4y ago
        The goals of the projects are not the same. CalyxOS is not a hardened OS and it doesn't aim to be a hardened OS. They don't work on the kinds of privacy and security features we do. For the most part, they work on much different things with very little overlap. Their approach is incompatible with ours. As an example, since they took over the Seedvault project and are running it in a similar way as their OS, it has blatant security issues. It uses privileged permissions it shouldn't and violates multiple aspects of the security model including bypassing app install rules. Encryption is not as opaque as it should be either. We aren't going to be able to use it anymore. We have to start over with a new backup service. Seedvault was originally written by a GrapheneOS community member for inclusion in GrapheneOS, based on the design that we laid out for it but it has deviated so far from that now and their goals / approach is incredibly incompatible with ours. Not even something like this can be shared. We had to drop F-Droid in 2018 because it has such huge security, usability, robustness and functionality issues. It still targeting Android 7 is the tip of the iceberg. It hasn't kept up with the platform at all and doesn't respect / follow the security model.
• 94427 4y ago
  Another example of GrapheneOS perpetuating anti-FOSS/anti-user behavior that goes beyond stupid licensing drama and has the potential to do real harm if implemented by developers: https://grapheneos.org/articles/attestation-compatibility-guide https://grapheneos.org/articles/attestation-compatibility-gu... (https://archive.ph/ZqCqA https://archive.ph/ZqCqA) TLDR: Rather than encouraging app developers to abandon the plainly anti-FOSS/anti-user technology that is SafetyNet hardware attestation, GrapheneOS instead encourages developers to continue locking down their apps such that they only work on specific operating systems, but also kindly asks them to add the official releases of GrapheneOS to the list of "approved" Android builds (in addition to proprietary "Google-approved" Android, of course). The above link is a handy implementation guide for developers that GrapheneOS has published to their website and actively encourages its users to share with developers. SafetyNet hardware attestation is an anti-FOSS/anti-user technology that has no legitimate use case. It allows apps to arbitrarily refuse to run on "un-approved" versions of Android. Apps have absolutely no business policing the operating systems that users are allowed to run on their device. If this technology is adopted by a large number of applications that people rely upon, we are left with no option other than to use an "approved" OS. We cannot fork GrapheneOS if the project goes in a certain direction that we disagree with, because then we would be unable to run the apps we need. Strcat's response to anyone ideologically opposed to this is "don't use GrapheneOS": > If you have an ideological issue with GrapheneOS providing working attestation and preserving the app security model, i.e. allowing apps can perform checks that cannot be faked without an exploit, my recommendation is using something else. If you consider this capability to make it a "walled garden" then GrapheneOS is happily a "walled garden" https://old.reddit.com/r/GrapheneOS/comments/du23la/rooted_or_root/flqf3lx https://old.reddit.com/r/GrapheneOS/comments/du23la/rooted_o... Tragically GrapheneOS doesn't tend to view any Google decisions through a critical lens, which would allow them to see through some of Google's "security features" for what they really are: user-control features implemented solely to ensure that most people do not switch away from the stock OS and continue to consume Google services, handing over their user data in the process.
  • strcat 4y ago
    GrapheneOS does not support SafetyNet or Play Integrity hardware attestation and there isn't a way to use them on GrapheneOS. The whole point of that article is encouraging developers to move away from those Google services to the standard Android Open Source Project hardware attestation API which includes support for alternate operating systems. Once developers switch away from the Google attestation API to the Android attestation API, they can freely add support for alternate operating systems by adding their signing keys to an allowlist if they meet the requirements. They can have an application process for operating systems to be approved by their risk/anti-fraud/anti-cheat departments. Starting by adding GrapheneOS would make sense since it's the most widely used alternate mobile OS with properly signed releases supporting attestation. Our article does not recommend only supporting GrapheneOS and if developers change their implementation as we recommend, they can easily add support for many other operating systems. Convincing developers not to unnecessarily lock down which operating systems can use their apps is a separate thing from convincing them to support alternate operating systems meeting their standards. Some apps are required to check for this due to expectations from financial services or even governments, and while most usually do a poor job today they will eventually mostly move to the Play Integrity API and will eventually enforce the strong verification level requiring hardware attestation. It would be much better if they instead used the Android attestation API supported by the Android Open Source Project which is also available in any alternate OS based on AOSP. Basic hardware-based attestation is available on every device launched with Android 8. An alternate OS such as GrapheneOS disabling the feature for user installed apps simply means it won't pass checks based on it. Disabling it would not accomplish anything useful. It doesn't leak any information that can't be otherwise obtained but rather provides a way to cryptographically verify the information that's available including verified boot mode, OS signing key, OS hash, OS patch level, device model and also non-hardware-based things verified by the OS like the app id and signing key. GrapheneOS contributed to upstream hardware attestation improvements by making a proposal for much better pinning support which was accepted and implemented in the Android 12 attestation API. Our proposal makes attestation work much better as a user-oriented feature for securing devices with our Auditor app. Pinning has no use when using this feature for anti-cheat, anti-fraud, DRM, etc. since those simply depend on verifying based on the root certificate which will always be vulnerable to bypass via leaked keys from insecure devices. Supporting verified boot and hardware-based attestation is not anti-FOSS or anti-user. GrapheneOS uses attestation as one of the major included security features via our Auditor app. Other apps can also use it to protect user security. What users see as hostile is not universal. Most users want to play competitive games without having other people using software/hardware to cheat. Hardware-based attestation can be used to build much stronger anti-cheat, and some games are doing exactly that with the feature. It's unfortunate that they're currently doing it with the Play Integrity API (or legacy SafetyNet attestation API) since it locks out users on alternate operating systems. If they used the Android attestation API instead, they could avoid locking out users on operating systems like GrapheneOS and others. It's entirely possible for those games to implement this in a way where people with hardware attestation are placed in games together and people without it are kept separate, which is one of the ways this is being implemented. That means at the moment, GrapheneOS users will have a worse experience due to being grouped with nearly all of the people using cheats. We want to get this fixed. It is not anti-user to want a better experience and broader app compatibility for GrapheneOS users. It is not GrapheneOS choosing to use attestation to lock anything down. GrapheneOS only uses attestation if the user chooses to use our Auditor app and that's entirely based around the user protecting their device. It is other developers who want to use attestation in ways that can be seen as hostile to users, and that will be the case regardless of what GrapheneOS does. GrapheneOS does not have significant influence over Android app developers. If we can get a single major app to switch to the Android attestation API and support GrapheneOS and other alternate operating systems, that will be a major accomplishment. PayPal seems to be gradually adopting using Play Integrity attestation and perhaps we can convince them as a starting point. Our users are certainly not going to be unhappy if PayPal continues working on GrapheneOS instead of breaking. Not clear how you get the idea that this is anti-user. > Tragically GrapheneOS doesn't tend to view any Google decisions through a critical lens, which would allow them to see through some of Google's "security features" for what they really are: user-control features implemented solely to ensure that most people do not switch away from the stock OS and continue to consume Google services, handing over their user data in the process. There have been massive privacy and security improvements in each major release of Android for many years. The hardware attestation API released prior to Android 8 is a single feature. SafetyNet attestation and the Play Integrity API are not part of Android itself but rather Google Play. Those were ported to using the hardware attestation API when available but they mostly aren't based on it and don't take much advantage of it. GrapheneOS itself is one of the only projects using Android's hardware-based attestation directly via our Auditor app. We're likely the ONLY software project using the app-generated attest key feature introduced in Android 12 based on our proposal and first shipped on the Pixel 6 because we found issues making it unusable at first which had to be reported and fixed. App-generated attest keys are a different approach to attestation based around generating hardware backed attestation signing keys and pinning those instead of verifying based on a trusted root certificate. This pinning-based approach is not useful for user hostile features and can be supported even on a device not including a trusted attestation root certificate in the secure element. We helped to make hardware-based attestation into a feature that's much more useful for protecting users and which can exist without the part that allows building user hostile features. The attestation root is still useful for verifying the initial pairing for our Auditor app or other use cases based on Trust On First Use via pinning.