Isn’t graphene having a challenging future because they have vendor locked themselves into pixel phones and said vendor is pulling the rug by not providing drivers going forward?
GrapheneOS has largely worked around this by automating creating device support themselves using “adevtool”. The current Pixels’ hardware supports installing third-party OSes and will continue to do so, they will support those Pixels until EOL. For future Pixels (Pixel 10 series has not yet launched, only available for pre-order), it remains to be seen whether they still fully support installing third-party OSes. If they do, GrapheneOS will also support them, but it might take much longer to implement device support because they need to make this by themselves and this is more difficult doing it from scratch than being able to use the old Android device support for it as a base, like they could do for the existing devices when Google did their rugpull.
They have not really vendor locked themselves for the future. They have hardware requirements listed in their FAQ: https://grapheneos.org/faq#device-support
Google just happened to be the only company meeting those requirements, which weren’t even that strict, becuase other OEMs just didn’t prioritize security.
But, there is good news. GrapheneOS is currently in active talks with a major Android OEM right now in order to help them meet the security requirements for a subset of their future devices. They are very optimistic about that.
Google just happened to be the only company meeting those requirements
I don’t know. They designed the requirements in a way that only Google met them. It didn’t “happen” to meet them after the fact.
It’s like demanding yellow hard hats on a construction site. Sure, they are safe and highly visible. Would it make sense to allow black hard hats as well if it means not locking into a single vendor and try pushing for high vis while having a stronger base? And also working around the issue with a vest? I don’t know the answer to that but it’s clear that they have made a conscious decision to move into the situation that they now find themselves in.
They are literally talking with a major OEM right now to help them meet their requirements so what you say does not make any sense. They aren’t purposefully making requirements so only Pixels would fit them. The current hardware ecosystem is just bad with regard to security. Many GrapheneOS features depend on certain hardware security features being present, if they would also support lesser secure deivces, they would have to rip out too many fundamental features of GrapheneOS. That would go against the purpose of GrapheneOS, which is delivering a secure, private and usability mobile OS.
I didn’t say they need to rip something out. I didn’t say their current efforts to open up weren’t valid.
I specifically said that I don’t know whether it would have made sense to start with reduced requirements.
I just stated that they didn’t “happen” to only support Google. I simply acknowledged how they knew exactly that the standard they were writing would only be matched by one vendor as they were writing it.
They were written at some moment in time and major vendors often have multiple moments during the year when they release new phones. Even if GrapheneOS, while writing down the requirements, realized that only 1 brand met them at that time, they were still assuming and hoping other brands could also easily meet them in the time following. The main problem here was that other brands didn’t seem to care. After hardware memory tagging was added to the ARM platform and Pixels immediatelly adopted this, GrapheneOS added it to the requirements, because it was such a subsantial feature that could outrule a large number of vulnerabilities. But, they have communicated multiple times across social media that they were willing to be much less strict about that requirement because earlier phones also didn’t have to meet them and because Qualcomm didn’t add ARM yet to their SoCs. They said back then they would be willing to support a Samsung phone if it would meet everything except for memory tagging (the main problem for Samsung is lack of proper third-party OS support). So, I think they’ve tried their best, to be honest. The current talks with the OEM I was talking abour earlier, also aren’t the first time they do those efforts. They’ve had contact with OEMs in the past to try to push them towards meeting the requirements, but the efforts happened to fail. The negligence of other brands is just really that big. In the tech space, sadly, only Apple and Google seem to truly care about security, spending money on it, and hiring sufficiently large teams of security researchers. I really hope, together with you, that this will change 🙏 .
I agree, the ecosystem seems to be focusing too much on hype and not enough on a strong and secure foundation. I’m still hoping for the best but I feel must more hopeful towards Linux on mobile devices. They are moving at an excruciatingly slow pace, though. Not enough resources and hands.
Would be nice to have secure SoCs in phones that cut costs with regards to camera and screen, but there is not a market for it I guess because people think they don’t care about security. Android is Linux of course since the Android kernel is a Linux kernel. I’m aware you are probablly referring to using traditional Linux OSes that are typically used on desktops on mobile phones. That would, however, be a significant regression for security. Android and iOS are both modern mobile OSes with an in-depth security model which includes a mandatory app sandbox with a sane permission model. This is not present on traditional desktop OSes. This is not meant to diss on those OSes, they are just children of their time, they were created much earlier, security practices have evolved. I can see why it would be a fun experience though to tinker with, it would just not be a secure experience and it’s unlikely to get there because the improvements in traditional Linux distros go much slower than they go on Android and Android is already massively ahead.
Isn’t graphene having a challenging future because they have vendor locked themselves into pixel phones and said vendor is pulling the rug by not providing drivers going forward?
GrapheneOS has largely worked around this by automating creating device support themselves using “adevtool”. The current Pixels’ hardware supports installing third-party OSes and will continue to do so, they will support those Pixels until EOL. For future Pixels (Pixel 10 series has not yet launched, only available for pre-order), it remains to be seen whether they still fully support installing third-party OSes. If they do, GrapheneOS will also support them, but it might take much longer to implement device support because they need to make this by themselves and this is more difficult doing it from scratch than being able to use the old Android device support for it as a base, like they could do for the existing devices when Google did their rugpull.
They have not really vendor locked themselves for the future. They have hardware requirements listed in their FAQ: https://grapheneos.org/faq#device-support Google just happened to be the only company meeting those requirements, which weren’t even that strict, becuase other OEMs just didn’t prioritize security.
But, there is good news. GrapheneOS is currently in active talks with a major Android OEM right now in order to help them meet the security requirements for a subset of their future devices. They are very optimistic about that.
I don’t know. They designed the requirements in a way that only Google met them. It didn’t “happen” to meet them after the fact.
It’s like demanding yellow hard hats on a construction site. Sure, they are safe and highly visible. Would it make sense to allow black hard hats as well if it means not locking into a single vendor and try pushing for high vis while having a stronger base? And also working around the issue with a vest? I don’t know the answer to that but it’s clear that they have made a conscious decision to move into the situation that they now find themselves in.
They are literally talking with a major OEM right now to help them meet their requirements so what you say does not make any sense. They aren’t purposefully making requirements so only Pixels would fit them. The current hardware ecosystem is just bad with regard to security. Many GrapheneOS features depend on certain hardware security features being present, if they would also support lesser secure deivces, they would have to rip out too many fundamental features of GrapheneOS. That would go against the purpose of GrapheneOS, which is delivering a secure, private and usability mobile OS.
I didn’t say they need to rip something out. I didn’t say their current efforts to open up weren’t valid. I specifically said that I don’t know whether it would have made sense to start with reduced requirements.
I just stated that they didn’t “happen” to only support Google. I simply acknowledged how they knew exactly that the standard they were writing would only be matched by one vendor as they were writing it.
They were written at some moment in time and major vendors often have multiple moments during the year when they release new phones. Even if GrapheneOS, while writing down the requirements, realized that only 1 brand met them at that time, they were still assuming and hoping other brands could also easily meet them in the time following. The main problem here was that other brands didn’t seem to care. After hardware memory tagging was added to the ARM platform and Pixels immediatelly adopted this, GrapheneOS added it to the requirements, because it was such a subsantial feature that could outrule a large number of vulnerabilities. But, they have communicated multiple times across social media that they were willing to be much less strict about that requirement because earlier phones also didn’t have to meet them and because Qualcomm didn’t add ARM yet to their SoCs. They said back then they would be willing to support a Samsung phone if it would meet everything except for memory tagging (the main problem for Samsung is lack of proper third-party OS support). So, I think they’ve tried their best, to be honest. The current talks with the OEM I was talking abour earlier, also aren’t the first time they do those efforts. They’ve had contact with OEMs in the past to try to push them towards meeting the requirements, but the efforts happened to fail. The negligence of other brands is just really that big. In the tech space, sadly, only Apple and Google seem to truly care about security, spending money on it, and hiring sufficiently large teams of security researchers. I really hope, together with you, that this will change 🙏 .
I agree, the ecosystem seems to be focusing too much on hype and not enough on a strong and secure foundation. I’m still hoping for the best but I feel must more hopeful towards Linux on mobile devices. They are moving at an excruciatingly slow pace, though. Not enough resources and hands.
Would be nice to have secure SoCs in phones that cut costs with regards to camera and screen, but there is not a market for it I guess because people think they don’t care about security. Android is Linux of course since the Android kernel is a Linux kernel. I’m aware you are probablly referring to using traditional Linux OSes that are typically used on desktops on mobile phones. That would, however, be a significant regression for security. Android and iOS are both modern mobile OSes with an in-depth security model which includes a mandatory app sandbox with a sane permission model. This is not present on traditional desktop OSes. This is not meant to diss on those OSes, they are just children of their time, they were created much earlier, security practices have evolved. I can see why it would be a fun experience though to tinker with, it would just not be a secure experience and it’s unlikely to get there because the improvements in traditional Linux distros go much slower than they go on Android and Android is already massively ahead.