Daniel Micay

Apple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too. Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition. The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it. Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web. Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems: support.google.com/recaptcha/answ… Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web. Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more. Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive. Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on FreeBSD instead. You'll just be more locked out. Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it. It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source. Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them. Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security. reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that. This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere. Services shouldn't ban people from using arbitrary hardware and operating systems in the first place. Google's security excuse is clearly bogus when they permit devices with no patches for 10 years but not a much more secure OS. It's for enforcing their monopolies via GMS licensing, that's all.

This post is needed to debunk misinformation from a charlatan (@hackerfantastic) masquerading as being a legitimate security researcher. They used to be quite successful at duping people into believing they were legitimate by taking credit for other people's work and fabricating vulnerabilities, which hasn't held up for them in the long term. They have historical follows from actual researchers from before their credibility disintegrated which is part of why people still fall for it. They are not a legitimate researcher and many of their past claims of exploits including phony systemd exploits have been debunked. Lennart Poettering is one of several people to debunk their made up vulnerabilities and had their replies hidden along with being blocked, which is the same approach they just took with us (see the hidden posts at x.com/hackerfantasti… for an example). The many unsubstantiated claims they make should not be believed. We can't reply at all within those threads anymore due to the new way blocking works so we're replying here instead. Their main attempt at attacking us is making the ridiculous and downright desperate false claim that somehow the only purpose of GrapheneOS is using OpenBSD heap allocators, which it hasn't even used since before we made hardened_malloc in 2018: x.com/hackerfantasti… x.com/hackerfantasti… x.com/hackerfantasti… Our hardened_malloc project is an important sub-project protecting very well against the majority of remote code execution exploits in the userspace part of the OS. However, it's a tiny portion of our overall work and only one of many major privacy and security features we provide. Even if we did still use OpenBSD malloc for 32-bit apps on older devices still supporting them, that wouldn't be a significant part of the project at all. They're promoting that people use a highly insecure device without the most basic hardware, firmware and software security features where data can be trivially extracted from the device without even using exploits and where far more vulnerabilities are exposed with negligible protection against them being exploited: x.com/hackerfantasti… GrapheneOS is a Linux distribution based on the Android Open Source Project (AOSP). Compared to a traditional desktop Linux distribution, AOSP is already very hardened and provides dramatically better privacy and security. It's a night and day difference. Traditional desktop Linux distributions struggle to deploy exploit protections from the early 2000s and lack proper app sandboxing. They lack systemic privacy and security work throughout the OS as a whole. They're really a bunch of largely anti-security projects glued together into a frankenstein OS with the development direction set by these individual projects, not the distributions. They ship what's provided to them, and the result is not a particularly secure OS. iOS and AOSP are far more secure than these operating systems. A bunch of companies having badly maintained forks of AOSP does not reflect on AOSP itself, but even those are far more secure than traditional desktop operating systems if they're doing the bare minimum of providing security patch backports. Android Open Source Project without our improvements is far more secure than desktop Linux distributions. It already has a far more hardened kernel with a huge amount of attack surface reduction via the kernel configuration, very advanced use SELinux and to a lesser extent seccomp-bpf. The differences in userspace are far more dramatic. It has a well designed mandatory app sandbox and sandboxing heavily used throughout the OS. It has strict full system SELinux MAC/MLS policies which the OS is developed around rather than being added on afterwards. The majority of new code is being written in memory safe languages (Rust, Java, Kotlin). It was always focused on memory safety, sandboxing, etc. from the start. Privacy and security are a major focus throughout it and many design compromises are made for them rather than being an afterthought. Backwards incompatible privacy and security changes are made to the app sandbox on a yearly basis. Our features compared to the latest release of the standard Android Open Source Project are documented at grapheneos.org/features. This page only covers our improvements and does not cover the standard AOSP privacy and security features. The subset of our features which have been landed upstream by us such as FORTIFY_SOURCE for the Linux kernel string library have been removed from our features page. Our hardened_malloc project provides great protection against heap corruption vulnerabilities in userspace but that's just one small part of the overall GrapheneOS project. Prior to making our hardened_malloc project in 2018, we used our own fork of OpenBSD malloc ported to Linux and extended with significant additional security features. This had to be replaced as a whole to provide substantially better security against heap vulnerabilities. This charlatan (@hackerfantastic) is spreading misinformation about GrapheneOS because they had a business deal with Copperhead after the failed takeover attempt on GrapheneOS. They were trying to sell devices with their insecure, closed source fork of legacy GrapheneOS versions. They hold a grudge against us based on their business venture failing and are trying their best to spread misinformation about it. Unfortunately for them, they don't have the faintest clue about what we work on and what we provide in current generation GrapheneOS. They responded to us responding with polite, accurate information by hiding our posts, blocking us and doubling down on blatant misinformation which we already pointed out. If you want to go down a deep rabbit hole, look into how the company they co-founded, Hacker House, got money through government corruption. If they keep going down the road of supporting harassment content targeting our team, we can make a post about this.

UPDATE: The US has stopped sharing "all" intelligence with Ukraine, a Ukrainian source has said.  Previously the source, with knowledge of the situation, said the halt in the follow of intelligence had been "selective", only affecting information that could be used for attacks inside Russia.  "A few hours ago, the exchange of all information was stopped," the source said.  With @safarov_