SECOND MEASUREMENT SM-001

Google's Pixel ledger promised every release. January went missing, and stayed missing for eight months

Markovian ProtocolMeasured 2026-09-15Rechecked 2026-09-30Updated 2026-10-05Status: confirmed and fixed by Google · replied and fixed in 7 days · fingerprint backfill done 15 OctDOI: 10.5281/zenodo.23070510

Every Pixel update is supposed to land in a public ledger, so anyone can prove their phone got the same software as everyone else's. In September we went looking for January 2026 and found an empty month: all 29 factory images, missing from the record for eight months. We told Google. Within a week they'd traced it to a skipped update run and written the month back in, without disturbing a single earlier entry. One loose end is still dangling: 128 newer entries filed under a label phones never report, so those phones can't find their own.

Round trip. The operator replied, fixed what we measured, and the recheck confirmed it. The seal records that; it links here and to the log leaf that pins this page.

Disclosure: Markovian Protocol holds no financial position in any organisation named here, was paid by no one for this work, and showed it to no one before publication except the organisation measured. How we work.

What Google says, what we found

Why a log can look complete and still have holes

A signed log proves Google committed to everything that's in it.⁴ It can't prove nothing was left out. The only way to test that is to hold it up against an outside list of what should be there. Google's own download page is that list.² It's published separately from the log, so we fetched both and matched every image on the page, for all 25 Pixel 6-and-newer phones, against the log.

The missing month

The log had December 2025. It had February 2026. January wasn't there at all: build BP4A.260105.004 (versions .E1, .A2, .B2 and .C2) for 15 devices, from the Pixel 7a and Pixel Tablet to the Pixel 10 Pro Fold, 29 images.

Matching by name can miss an image that's filed under a different name, so we checked one by its contents too. We downloaded just the small vbmeta part of the Pixel 9 (tokay) January image and computed its hash with Google's own tool, avbtool:⁶

b1eca34c41d308c91abcea66cf5852814cd526020041a590bd7f865aaa0900b6

That hash appeared 0 times in the whole log. It really was missing, not misfiled.

The other 25 missing images were September 2026 builds (CP3A.260905.009 for 21 phones and CD1A.260905.001.B1 for the four launched that month); the log had last been updated on 21 August, so we reported those as ordinary lag rather than a hole.

15 September 2026, log size 1,109.

The phones that can't find themselves

Every Android 17 image is in the log, 103 of them, but filed under google/generic_system_google/generic:17/… instead of the phone's own name. Take the Pixel 9 build CP2A.260705.006: its hash is entry 1073, under the generic name.

Inside the image, only one field (com.android.build.system.fingerprint) says generic. Everything else, including the fingerprint the phone actually reports (ro.build.fingerprint), says google/tokay/tokay:17/…. Google's own verifier accepts the entry with the generic name and rejects it with the phone's name. So the image is logged, but a phone that checks itself using its own fingerprint comes up empty.

What Google said back

We filed both findings on 15 September as issue #20.⁵ On 22 September the log's maintainer replied:

The cause was a missed run of the log-append step for that release, not a discrepancy in the images themselves. They should now have been appended (backfilled) at indices 1134-1162; the log is at tree size 1163.

The same reply confirmed the Android 17 problem: on an Android 17 phone, a check built from ro.build.fingerprint won't verify even though the image is logged.

On 5 October the maintainer, Billy Lau, answered the rest. The Android 17 entries are being backfilled under the device-specific fingerprints, and he is keeping the issue open until they land. He also explained how the log's checkpoint is published, which settles a question we had raised in the thread: the Pixel log predates Google's Tessera-based logs, its publishing pipeline to developers.google.com is one-way, and it was never built to fold witness cosignatures back into the origin checkpoint.txt. The cosigned copy lives at the transparency-dev distributor, which collects the Armored Witness signatures downstream, and that is where a verifier should fetch it. Moving the log onto Tessera would make the origin witnessable but is not on the roadmap, and he said so plainly rather than leaving it open. That is the full picture of how this log is verified, and it came from the operator in three replies over three weeks, each one answering everything asked.

Did the fix rewrite history?

Adding missing entries is fine. Quietly changing old ones wouldn't be. Our vendor-log monitor⁷ had saved the log's state at 1,134 entries on 18 September. On 23 September it checked a proof that the new 1,163-entry log starts with exactly those 1,134 entries. It does: the 29 were added on the end, and nothing earlier changed. The missing Pixel 9 image from above is now entry 1161:

1161
google/tokay/tokay:16/BP4A.260105.004.E1/14587043:user/release-keys
b1eca34c41d308c91abcea66cf5852814cd526020041a590bd7f865aaa0900b6

Same script both days. The September lag images are in now. The 25 September images were logged by 18 September, all under the generic label, which is why that count went from 103 to 128.

The evidence

Every quote below was checked against a saved copy, fetched 2026-10-02T18:09:27Z. Copies and SHA-256 hashes: SHA256SUMS.

developers.google.com/android/binary_transparency/0
1163
7XhtRE3AhCPZlIedbcQ2fXo4cs21fc15PR+Ahv5lIJc=

Disclosure timeline

What we can't be sure of

• We compared the log against one page. Software sent only as over-the-air updates, images Google has taken down, and images published anywhere else aren't covered.
• The log also holds 71 images the download page no longer lists (63 older Pixel 6a builds, 4 Pixel 6 and 4 Pixel 6 Pro). That's the other direction, and Google's claim doesn't cover it.

Run it yourself

The scripts are also on GitHub: github.com/MarkovianProtocol/second-measurements/sm-001.

The script uses only Python's standard library. It prints any absent images and a summary line.

curl -O https://markovianprotocol.com/measurements/sm-001/check_public.py
shasum -a 256 check_public.py
# fcc67371bd9f8bccbaac25903571aced8bed71234024d716a6209225eb1b522c
python3 check_public.py
# tree size 1163: {'logged': 963, 'logged as generic': 128}

Ran it? Send the number you got and the date to hello@markovianprotocol.com, subject “Rerun SM-001”. We print it on the track record with your name, or just the date if you prefer, and the first outside rerun of each paper gets the same seal the operators get.

The script does not verify the checkpoint signature. Verify it with Google's verifier³ or against the Armored Witness cosigned copy.⁸ The same completeness check runs daily and publishes signed results.⁷

Corrections

23 September: in a follow-up on issue #20 we told Google that nobody was cosigning the Pixel log. Three Armored Witnesses had been cosigning it the whole time. We had knocked on eight witnesses' front doors and found no Pixel checkpoint at any of them; the signatures were in the mailroom, the transparency-dev distributor, which served checkpoint.3 at size 1,163 with three Armored Witness signatures and the same root as Google's.⁸ The maintainer pointed us there the next morning, we posted the correction in the same thread, and his 5 October reply (Exhibit 4) explains why the distributor is the place to look. Rule we now follow: ask the distributor before announcing an absence.

Reproduced from the public repository on 3 October 2026 on a clean machine: exact (tree size 1,163, 963 logged, 128 under the generic label). Full table on the track record.

What you can do with this

• If you own a Pixel 6 or later, the factory image you install should be findable in the log by its build number; the verifier in Google's repository does this, and the January 2026 builds now resolve.
• If you run a binary transparency log, publish the fingerprint phones actually report; 128 entries here still carry one they don't, and Google is adding the device-specific ones.
• If you verify the Pixel log and want witness cosignatures, fetch the checkpoint from api.transparency.dev, not from developers.google.com.⁸

References

1. Google. Pixel Binary Transparency overview. developers.google.com/android/binary_transparency/pixel_overview. Accessed 2026-09-30.
2. Google. Factory Images for Nexus and Pixel Devices. developers.google.com/android/images. Accessed 2026-09-15 and 2026-09-30.
3. Google. android-binary-transparency (verifier and log files checkpoint.txt, image_info.txt). github.com/android/android-binary-transparency.
4. B. Laurie, A. Langley, E. Kasper. Certificate Transparency. RFC 6962, 2013. rfc-editor.org/rfc/rfc6962.
5. Markovian Protocol. Pixel log: January 2026 factory images are missing, and Android 17 entries use the system fingerprint. android/android-binary-transparency#20, 2026-09-15; maintainer replies 2026-09-22, 2026-09-23 and 2026-10-05. github.com/android/android-binary-transparency/issues/20.
6. Android Open Source Project. Android Verified Boot 2.0, avbtool. android.googlesource.com/platform/external/avb.
7. Markovian Protocol. Vendor log monitor and signed statements. markovianprotocol.com/bt/.
8. transparency-dev. Distributor API, Pixel log checkpoint.3. api.transparency.dev/distributor/v0/logs. Accessed 2026-09-23.

Cite as

@misc{markovian-sm001,
  author = {{Markovian Protocol}},
  title  = {Completeness of the Pixel Binary Transparency log
            against Google's factory images page},
  number = {SM-001},
  doi    = {10.5281/zenodo.23070510},
  year   = {2026},
  month  = sep,
  url    = {https://markovianprotocol.com/measurements/sm-001.html}
}