No lol, they have a list of specific hardware security requirements for a device to have, the biggest one being a secure element. Without a secure element there is no hardware-backed key derivation throttling, so it’s much more possible for an attacker to brute force your phone’s PIN.

Support for using alternate operating systems including full hardware security functionality
Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
Linux 6.1, 6.6 or 6.12 Generic Kernel Image (GKI) support
Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
Hardware memory tagging (ARM MTE or equivalent)
Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn't used or can't be deployed (BTI/PAC, CET IBT or equivalent)
PXN, SMEP or equivalent
PAN, SMAP or equivalent
Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components
Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
Verified boot with rollback protection for firmware
Verified boot with rollback protection for the OS (Android Verified Boot)
Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
StrongBox keystore provided by secure element
Hardware key attestation support for the StrongBox keystore
Attest key support for hardware key attestation to provide pinning support
Weaver disk encryption key derivation throttling provided by secure element
Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
Inline disk encryption acceleration with wrapped key support
64-bit-only device support code
Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that's completed
Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked

Until the collaboration with Motorola produces a device, only the recent Pixels meet the requirements.

Fairphone is also one of the worse OEM’s when it comes to how slowly they patch and releases security vulnerabilities, and they are known to be quite sloppy, in the past they have published their private keys. I wouldn’t trust keeping anything remotely private or sensitive on a Fairphone.

It still sucks for security. If you own this phone you should consider that the authorities and pretty much anyone who really wants to can get into your phone at will. I wish they could meet Graphene’s hardware requirements.

That sounds a bit like it conflicts with the actual job of the LLM.

You’re right. But it’s designed in such a way that it only biases the choice between the statistically most likely candidates, so it’s not forcing a choice to a less optimal token. It’s biasing the choice between equally optimal tokens. So it doesn’t really affect the quality of the LLM’s output.

And the resulting watermark would be way too fuzzy to be actually useful for flagging anything as AI-generated.

It’s actually not that fuzzy. It’s the statistical equivalent to randomly guessing a 256-bit encyrption key. If you consider the algorithm operate on trigrams (sets of 3 words), then a 1000-word document contain 998 trigrams. Let’s say at each trigram the model has a choice between 16 equally likely candidate words, which is usually chosen at random according to the model temperature, now is also biased by the watermark hashing function.

The statistical likelihood of randomly making the same 1/16 choice as the watermark 998 times in a row is so extremely small it’s essentially impossible. Even if you rearrange the document, cut large portions, paste in other portions, rewrite some, you’re likely to leave in enough matching trigrams to make a statistically solid determination.

The main requirement is the text needs to be long enough… just a small sentence or snippet won’t be enough.

Having said that, it’s not that hard to defeat the watermark once you know how it’s done. If you know it operates on token trigrams, then you need to rewrite the document at the trigram level to break up those relationships.

Are they just trying to check a box on some compliance checklist?

Actually yes, this has been prompted by a new EU law requiring AI companies to make LLM output identifiable so that people have a chance at knowing what is generated/fake content.

Facebook splits the text “Ad” in the code so you have an “A” and “d” defined separately and then through some magic make them appear together when rendered… and then they change the exact locations and naming frequently.

Can my agent help me seize the means of production? No? Fuck off Zuck.

Yeah it’s exactly a pattern with token choices, by introducing a statistical bias to the randomness in token generation. Quality isn’t affected because the model is still choosing from the best candidates for the next token. You’re right that to be effective they need a long enough input to get enough matches to be.

Computer code is also going to be less effective because code has a much more rigid structure dictated by language syntax rules, coding conventions, linters and formatters, etc.

These are not watermarks using hidden characters. Their approach is undetectable even with an IDE. For a sequence of tokens, an LLM predicts the most likely next token, with some amount of randomness between equally likely candidates. The “watermark” is to introduce a statistical bias to this randomness, by altering the probability distribution of generated text according some hash function with a secret key, thereby embedding a statistical signature into the text itself.

So if the text is “I like to eat __” the model might have 3 top candidates for the next word (apple/orange/banana) that would be chosen at random. Instead that choice will be biased towards one option according to their hash function. And then again “I like to eat banana __” (cake/pie/tart).

To verify a text, they look for the “watermark” by scanning the text and looking at whether sequences of tokens chocies fits their biased probability distribution or are truly random. Just one match doesn’t tell you anything, but if they see a consistent pattern over a 1000 word document, they can give a very high confidence that their model generated the text.

To a human it looks like nornal generated text, and the output quality isn’t affected much (or ar all). It’s much more effective on generated prose, and not very effective on computer code.