On an Apple silicon Mac, Chrome sends Sec-CH-UA-Arch: "arm" and navigator.userAgentData.getHighEntropyValues(['architecture']) resolves to "arm", while the User-Agent string beside it still says Intel Mac OS X 10_15_7. That pairing is normal. For a while Mosaic's own profile records said "x86" instead, the browser kept saying arm, and nothing in between had ever read the record.
What Sec-CH-UA-Arch says on a Mac
Sec-CH-UA-Arch is a high-entropy client hint. Chrome does not send it on every request; a site has to ask with an Accept-CH response header, or read it from JavaScript through getHighEntropyValues(). On a desktop it has two values in Chrome's vocabulary, arm and x86. Sec-CH-UA-Bitness carries the 64.
So on a Mac there are two answers, one per processor family:
| Mac | Sec-CH-UA-Arch | User-Agent string |
|---|---|---|
| Apple silicon | "arm" | Intel Mac OS X 10_15_7 |
| Intel | "x86" | Intel Mac OS X 10_15_7 |
The User-Agent column is the same in both rows on purpose. Chrome froze the platform part of the string, so the processor and the macOS version are in the hints and nowhere else. A site that wants the truth asks for the hints, and an Apple silicon Mac answering arm under an Intel User-Agent is simply what Chrome looks like there.
Every profile is drawn from one real computer, not from separate listsIn Mosaic: Machines that exist. GPU, screen, CPU and fonts from one real device. Free holds 3 profiles. Pro is $49 a month for any number.
Mosaic is a desktop app
Email yourself the link and open it on your computer.
How it works: Machines that exist
The field that reached nothing
Every Mosaic profile stores the values its browser will present, and one of them was uaArchitecture. The generator wrote the string 'x86' into it for every desktop profile it ever drew.
On 19 September 2026 we measured one freshly drawn macOS profile through the app:
the profile record uaArchitecture "x86"
navigator.userAgentData architecture "arm"
The record and the browser disagreed, and the browser was right. Tesseract Chrome, our engine, has no --fingerprint-ua-architecture switch, so it answers from the machine it runs on, the same way stock Chrome does. No launch had ever passed the stored value anywhere. All 344 profiles on that install carried the opposite of what their own browser reported, and the editor and the API showed the wrong one.
That is a shape we keep finding: a stored value that reaches no consumer looks exactly like a working one. It is the same fault as a rotation setting that was saved and ignored by three launches, just quieter, because nothing a site saw was wrong.
Why we report arm instead of spoofing x86
The obvious fix was to make the browser say what the record said: add a switch, patch the hint, send x86. We did the opposite and made the record say what the browser says, and that is the right answer, not a concession.
A macOS profile's fonts, its text rasterisation and its GPU already come from the Mac it runs on. On Apple silicon the GPU is an Apple GPU. A browser claiming x86 beside an Apple GPU renderer would be inventing a contradiction, which is exactly what a consistency scanner looks for. Answering arm is coherent with everything else the page can read, and it is the same answer stock Chrome gives on that Mac, so it separates our profiles from nobody.
What the profile must not do is disagree with itself, and the record was the only place it did.
What changed in Mosaic
The generator now asks the computer. hostArchitecture() reads Node's process.arch and translates it into Chrome's vocabulary: arm64 becomes arm, and anything else becomes x86. It does not pass Node's string through, because arm64 is not a value any client hint carries.
The repair reaches the profiles that already existed. A rule that only acts when a profile is drawn leaves every older profile behind, and on that install the older ones were all 344 of them. Repair hardware, whose job is to make a profile agree with the machine it runs on, now rewrites uaArchitecture to the host's value, alongside the other hardware fields it already corrected.
Android profiles are left alone. Chrome on Android sends an empty Sec-CH-UA-Arch and an empty bitness, so a phone profile stores the empty string; answering the desktop value there would be a phone contradicting itself in one field.
Checking it on your own Mac
Open DevTools on any https page and run:
await navigator.userAgentData.getHighEntropyValues(['architecture', 'bitness'])
An Apple silicon Mac in stock Chrome answers architecture: "arm", bitness: "64". Run it in a browser profile you are testing and compare. If the two disagree on the same machine, that is the finding. The full list of hints a page can ask for, and which ones must agree with the headers, is in getHighEntropyValues explained. Another hint we once got wrong, a full version with no build number, is in a full Chrome version no Chrome shipped, and how Mosaic draws the rest of the hardware is on real fingerprints.
