"We reserve the right to retain your security feet pics indefinitely, but won't use them for advertising purposes. We may use them for other business purposes, subject to change at any time without notification."
--new TOS
Then, a few months later x.ai announces a new SOTA frontier model, FeetGrok.
The prospect of going to a website I've never visited before, getting a captcha, and it saying "we don't think those are YOUR feet, access denied" is a little TOO believable.
> We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
Unfortunately, the EU is currently developing their age-verification-app, and it mandates hardware attestation[1], and it seems that their reference implement those requirements using Play Integrity[2].
Our growing userbase and Motorola partnership will give us a lot of sway to get apps to allow GrapheneOS. We can't realistically convince banks, governments and other companies to stop requiring attestation. We can realistically convince most apps to allow GrapheneOS via hardware attestation since it supports doing it via the standard Android key attestation API. We cannot realistically convince apps to not adopt attestation unless they implemented it without truly wanting what it provides which is unlikely for service-side integration. We've only convinced a couple apps to stop using the Play Integrity API. However, we've convinced a growing number to permit GrapheneOS alongside permitting Google-certified operating systems.
Regulators should force Google to stop further closing up Android and to permit alternate operating systems to pass the Play Integrity API device and strong integrity levels. It should not require certification by Google and complying with their arbitrary requirements based around their business model. There should be another path to obtaining certification without Google's involvement where Google has to respect it and permit those devices and operating systems to pass. Most important is stopping them from closing things down more against the original terms they provided Android and gained market share with it. Next most important is a reasonable path to alternatives passing the Play Integrity API based on security standards which do not block updates while waiting for certification.
We don't think it's realistic to stop apps adopting attestation but people should try regardless. A single country with a large market banning would make a huge difference.
https://grapheneos.org/articles/attestation-compatibility-gu... is our guide for app developers on permitting GrapheneOS via hardware attestation. Other operating systems can publish signed keys in a similar way to enable easily supporting them once this is implemented. An organization certifying operating systems could collect these and sign an overall list. It would also be possible to support a broader hardware ecosystem with alternate roots of trust by providing a signed list of those too. This is not the future we want but it is the future we believe we can obtain through a lot of pressure. We would greatly prefer apps not making an allowlist of operating systems. People should be able to make their own GrapheneOS build and use the same apps.
It's not a very good guide, frankly. It's basically a wall of text without clear instructions on what to do, besides "look at the examples Google gave". And even looking at Google's examples, there are no examples or explanations that tell me how to download the list of allowed signatures, and what should I do with the Json schema.
Yeah, its the "well, legally, we have to provide the source code, but we make it as painful and slow for you as we can without it becoming a blatant violation of the GPL."
GPL requires providing the source code via a medium customarily used for software interchange. Deliberately making it inconvenient by using a medium no longer customarily used for software interchange is a GPL violation. Google Drive is already an unusual way to distribute software.
Google is already failing to provide the Pixel kernel drivers in the preferred form for modification. Their kernel build system uses Git commands but yet they aren't providing the Git repositories it expects to be there. They had to provide a repo metadata file as a workaround but it's not the same since the revisions of the code aren't set properly in the resulting build.
Google is arguably already violating the GPL. They're deliberately making it inconvenient and are adding deliberate delays through requiring manual handling of the requests.
I'm pretty sure there is a lot of code in Android that belongs to Google and is not part of an upstream GPL project. They would be completely entitled to stop sharing it.
* Getting a dev env with `nix-shell -E '(import {}).somePackage'` where I can edit the source and compile it with the various `runPhase` commands[1].
Yes, a bit cumbersome, but it works and it is the same for all packages.
* Integrating the resulting patch into the package manager using overrides[2]. Sure, applying the patch may break at some point, but I am more comfortable reviewing that by hand than rely on an agent that does it for me.
The problem is not that the array is mutable, but that the size of the array may differ for different strings. (In fact, it usually* does differ if the string length is different).
This makes it impossible to flatten - as the VM needs to know the total size when creating the memory layout for a class...
* (with a small exception: if the strings use different coders, one can be twice as long and the backing arrays would still have the same size)
Indeed. At this point you’d need to bring the size of the string into the type system (C++ Templates we meet again!) but then you look at a solution worse than the problem…
You can make it not throw by adding `--add-opens java.base/java.lang=ALL-UNNAMED` or similar to the command line, but breaking things like this is becoming harder.
What is next? Run some arbitrary command? Make photos of your feet?
We really ought to think what is an acceptable way to verify that someone is an actual human.
reply