Dziennik przejrzystości aplikacji Google korzysta z technologii dziennika przejrzystości.
Użyteczność dzienników przejrzystości została potwierdzona w projektach takich jak Pixel Binary Transparency i także Certificate Transparency.
Dzienniki przejrzystości są implementowane za pomocą drzew Merkle. Na tej stronie zakładamy ogólną znajomość drzew Merkle i przejrzystości binarnej. Więcej informacji o drzewach Merkle znajdziesz w artykule Verifiable Data Structures, a o działaniach związanych z przejrzystością binarną w Androidzie – na stronie głównej.
Implementacja dziennika
Dziennik przejrzystości aplikacji Google jest implementowany za pomocą Tessera i jest zgodny ze specyfikacją tlog-tiles z wysokością kafelka równą 8 (każdy kafelek lub pakiet zawiera maksymalnie 28 = 256 elementów).
Katalog główny zawartości dziennika jest dostępny pod adresem:
https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/entries/
Katalog główny zawartości kafelka jest dostępny pod adresem:
https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/
Pamiętaj, że nie są to zwykłe strony internetowe. Wpisy w dzienniku znajdujące się w
podkatalogach należy odczytywać programowo za pomocą biblioteki klienta tlog-tiles (np. Tessera lub biblioteka Golang SumDB Tlog), a nie
w przeglądarce. Podajemy tutaj link w celu uniknięcia wątpliwości.
- Kafelki drzewa: skróty wewnętrzne i liściowe drzewa Merkle są dostępne pod adresem
tile/<level>/<path>(np.tile/0/000,tile/1/000). - Pakiety wpisów: ładunki liści dziennika są uporządkowane w pakiety wpisów pod adresem
tile/entries/<path>(np.tile/entries/000,tile/entries/001), a każdy pakiet zawiera maksymalnie 256 połączonych wpisów.
Opis zawartości poszczególnych wpisów znajdziesz w sekcji Zawartość dziennika.
Skrót główny drzewa Merkle dziennika, zawarty w punkcie kontrolnym, jest dostępny
pod adresem https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/checkpoint
w formacie punktu kontrolnego.
Źródło punktu kontrolnego to android.transparency.goog/google1p/apk/2026/1.
Podpisy punktów kontrolnych są generowane za pomocą algorytmu podpisywania Ed25519.
Podpis punktu kontrolnego można zweryfikować za pomocą tego klucza publicznego
w formacie weryfikatora notatek (zgodnie z definicją w golang.org/x/mod/sumdb/note)
lub w standardowym formacie PEM:
- Format weryfikatora notatek (
<name>+<key_hash>+<public_key_bytes>):
android.transparency.goog/google1p/apk/2026/1+fc654374+ATr9NQE0gvOtVfj5cCStUzdlflEp3oZoNHD8pImzPj5O
- Format PEM (SubjectPublicKeyInfo):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAOv01ATSC861V+PlwJK1TN2V+USnehmg0cPykibM+Pk4=
-----END PUBLIC KEY-----
Zarchiwizowany dziennik (wersja 1)
Przed aktualizacją w 3 kwartale 2026 r. dziennik działał w starszej implementacji w wersji 1, która używała podpisów ECDSA (NIST P-256 z SHA-256). Dziennik w wersji 1 jest zarchiwizowany i tylko do odczytu, ale nadal jest publicznie dostępny do weryfikowania wpisów historycznych:
- Rozmiar drzewa: 1 797 152 wpisy (w momencie archiwizacji)
- Skrót główny:
IkmuYB2xKKEOLiaQkIho1o9/uGjrKDbk8xa3xXaFeHY= - Punkt kontrolny: https://gstatic.com/android/binary_transparency/google1p/apk/2026/01/checkpoint.txt
- Liście danych: ze względu na ograniczenia rozmiaru pojedynczego pliku i miejsca na dysku w
gstatic.com(które ograniczają rozmiar pojedynczych plików statycznych do 200 MiB) ładunki liści dla całego zarchiwizowanego dziennika są podzielone na 2 kolejne pliki:- Część 1 (wpisy 0–1 714 860): https://gstatic.com/android/binary_transparency/google1p/apk/2026/01/package_info.txt
- Część 2 (wpisy 1 714 861–1 797 151): https://gstatic.com/android/binary_transparency/google1p/apk/2026/01/package_info2.txt
- Katalog główny kafelków:
https://gstatic.com/android/binary_transparency/google1p/apk/2026/01/tile/ - Klucz publiczny (format PEM, ECDSA P-256):
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaP7xodTP5/teDOUYFAUHF0MqvOXt
+jamtcDYWxTjY99hyYczpB/cF2fxHhIqEznNpLcI2Vorl+iEchWhZ0y3Mg==
-----END PUBLIC KEY-----
Weryfikowanie roszczeń w dzienniku
Na stronie weryfikacji znajdziesz szczegółowe informacje o tym, jak poszczególne komponenty dziennika są używane do weryfikowania roszczeń w modelu zgłaszającego.