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