Dziennik przejrzystości aplikacji usług Google

Dziennik przejrzystości aplikacji Google korzysta z technologii dziennika przejrzystości.

Przydatność dzienników przejrzystości została potwierdzona przez projekty takie jak Pixel Binary Transparency i Certificate Transparency.

Dzienniki przejrzystości są implementowane za pomocą drzew Merkle. Ta strona zakłada ogólną znajomość drzew Merkle i przejrzystości plików binarnych. Omówienie drzew Merkle znajdziesz w artykule Verifiable Data Structures (Weryfikowalne struktury danych), a omówienie działań związanych z przejrzystością plików binarnych w Androidzie – na stronie głównej.

Implementacja logów

Dziennik przejrzystości aplikacji usługi Google jest wdrażany za pomocą Tessera i jest zgodny ze specyfikacją tlog-tiles z kafelkiem o wysokości 8 (każdy kafelek lub pakiet zawiera maksymalnie 28 = 256 elementów).

Główny katalog zawartości logów jest dostępny pod adresem: https://www.gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/entries/

Główny katalog zawartości kafelka jest dostępny pod adresem: https://www.gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/

Pamiętaj, że nie są to zwykłe strony internetowe: wpisy logu zawarte w podkatalogach powinny być odczytywane automatycznie za pomocą biblioteki klienta tlog-tiles (takiej jak Tessera lub biblioteka Tlog Golang SumDB), a nie przez przeglądarkę. Podajemy go tutaj, w celu uniknięcia wątpliwości.

  • Kafelki drzewa: hasze węzłów wewnętrznych i liści drzewa Merkle są udostępniane w tile/<level>/<path> (np. tile/0/000, tile/1/000).
  • Pakiety wpisów: dane logów są uporządkowane w pakiety wpisów w tile/entries/<path> (np. tile/entries/000, tile/entries/001), przy czym każdy pakiet zawiera maksymalnie 256 połączonych wpisów.

Opis zawartości każdego wpisu znajdziesz w sekcji Zawartość logu.

Skrót korzenia drzewa Merkle logu, zawarty w punkcie kontrolnym, jest udostępniany na stronie https://www.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 log (wersja 1)

Przed aktualizacją w III kwartale 2026 r. dziennik działał w ramach wcześniejszej implementacji V1 z użyciem podpisów ECDSA (NIST P-256 z SHA-256). Dziennik V1 jest zarchiwizowany i dostępny tylko do odczytu, ale pozostaje publicznie dostępny do weryfikacji wpisów historycznych:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaP7xodTP5/teDOUYFAUHF0MqvOXt
+jamtcDYWxTjY99hyYczpB/cF2fxHhIqEznNpLcI2Vorl+iEchWhZ0y3Mg==
-----END PUBLIC KEY-----

Weryfikacja roszczeń dotyczących logów

Na stronie weryfikacji znajdziesz bardziej szczegółowy opis tego, jak różne komponenty logu są używane do weryfikacji twierdzeń zawartych w modelu wnioskodawcy.