6 ms·

GrapheneOS' approach is to focus more on security than privacy, because they believe increased security leads to increased privacy. Unfortunately, that means th

GrapheneOS' approach is to focus more on security than privacy, because they believe increased security leads to increased privacy. Unfortunately, that means their hardware requirements pretty much limit the hardware that you can run it on (currently only the Pixel phone range). Worse, it also means they stop supporting a device when it reaches End-Of-Life as software security updates stop for it (see How long can GrapheneOS support my device for? - https://grapheneos.org/faq#device-lifetime https://grapheneos.org/faq#device-lifetime ). Sad though - GrapheneOS on Sony Open Devices ( https://developer.sony.com/open-source/aosp-on-xperia-open-devices https://developer.sony.com/open-source/aosp-on-xperia-open-d... ) would have been nice.

stephenr 8mo ago
I'm not sure I fully understand this. Why are GrapheneOS releases dependant on Google releases?
- palata 8mo ago
  They are dependent on the AOSP releases (which Google develops) and on the manufacturer updates (and because GrapheneOS runs on Pixels, then it goes back to Google again).
  - stephenr 8mo ago
    I can understand relying on an OEM to provide hardware support for a given model - but I'm finding it hard to understand why they're unable to continue supporting a release just because the upstream removes support for something. I'm not even really sure what you mean by "manufacturer updates". The more I hear about this project, the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
    - palata 8mo ago
      > why they're unable to continue supporting a release just because the upstream removes support for something. If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software. > I'm not even really sure what you mean by "manufacturer updates". There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone. Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google. > the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest. If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution. I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well). So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.
    - andrewaylett 8mo ago
      They rely on manufacturer support for device firmware, just like anyone else.
      - Aachen 8mo ago
        Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
        palata 8mo ago
        Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do it. That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
        Aachen 8mo ago
        Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
palata 8mo ago
The whole reason why GrapheneOS is superior to its alternative is because they do all that. I also with they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS. My understanding is that there are close to half a million GrapheneOS users. And many potential users don't want to buy a Google phone. So it feels like it is starting to become worth considering for manufacturers... I don't get why Fairphone doesn't look into that. Is it because they are not aware, or is it too hard for them to make hardware that is compliant with what GrapheneOS requires? Hundreds of thousands of devices may not count so much for Samsung, but they must definitely count for Fairphone.
- Aachen 8mo ago
  > The whole reason why GrapheneOS is superior to its alternative is because they do all that. What is "its alternative"? > I also wish they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS. The manufacturers aren't blocking the installing of GrapheneOS...
  - no-reply 8mo ago
    GOS has minimum hardware requirements and most of the available smartphones don't meet them
    - fsflover 8mo ago
      This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
      - Itoldmyselfso 8mo ago
        You are not independent from Google if you purchase an android device from another manufacturer. You're then having your data sent to both Google and that manufacturer, resulting in far worse privacy overall than with just Google, not to mention worse security at hardware level. If you don't want to "support" Google, just buy any used Pixel 6 to 10 series.

stephenr 8mo ago

I'm not sure I fully understand this. Why are GrapheneOS releases dependant on Google releases?

palata 8mo ago
They are dependent on the AOSP releases (which Google develops) and on the manufacturer updates (and because GrapheneOS runs on Pixels, then it goes back to Google again).
- stephenr 8mo ago
  I can understand relying on an OEM to provide hardware support for a given model - but I'm finding it hard to understand why they're unable to continue supporting a release just because the upstream removes support for something. I'm not even really sure what you mean by "manufacturer updates". The more I hear about this project, the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
  - palata 8mo ago
    > why they're unable to continue supporting a release just because the upstream removes support for something. If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software. > I'm not even really sure what you mean by "manufacturer updates". There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone. Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google. > the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest. If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution. I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well). So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.
  - andrewaylett 8mo ago
    They rely on manufacturer support for device firmware, just like anyone else.
    - Aachen 8mo ago
      Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
      - palata 8mo ago
        Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do it. That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
        Aachen 8mo ago
        Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network

palata 8mo ago

The whole reason why GrapheneOS is superior to its alternative is because they do all that. I also with they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS. My understanding is that there are close to half a million GrapheneOS users. And many potential users don't want to buy a Google phone. So it feels like it is starting to become worth considering for manufacturers... I don't get why Fairphone doesn't look into that. Is it because they are not aware, or is it too hard for them to make hardware that is compliant with what GrapheneOS requires? Hundreds of thousands of devices may not count so much for Samsung, but they must definitely count for Fairphone.

Aachen 8mo ago
> The whole reason why GrapheneOS is superior to its alternative is because they do all that. What is "its alternative"? > I also wish they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS. The manufacturers aren't blocking the installing of GrapheneOS...
- no-reply 8mo ago
  GOS has minimum hardware requirements and most of the available smartphones don't meet them
  - fsflover 8mo ago
    This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
    - Itoldmyselfso 8mo ago
      You are not independent from Google if you purchase an android device from another manufacturer. You're then having your data sent to both Google and that manufacturer, resulting in far worse privacy overall than with just Google, not to mention worse security at hardware level. If you don't want to "support" Google, just buy any used Pixel 6 to 10 series.