Klikasz „Odrzuć wszystko”, zamykasz aplikację i uruchamiasz ją ponownie. Ten sam formularz zgody wraca. Powtarzasz odmowę, a przy następnym starcie sytuacja wygląda identycznie. W części aplikacji zbadanych na Androidzie nie był to efekt aktualizacji ani wyczyszczenia danych: program zapisywał wybór użytkownika dopiero wtedy, gdy ten zgodził się na wszystkie operacje przetwarzania.
To tylko jeden z wyników badania „The TCF doesn’t really A(A)ID – Automatic Privacy Analysis and Legal Compliance of TCF-based Android Applications”, opublikowanego w 2026 r. w Proceedings on Privacy Enhancing Technologies 2026(3). Badacze zebrali 5067 popularnych aplikacji z Google Play, 4482 udało się pobrać, a w 576 potwierdzili faktyczne wykorzystanie Transparency and Consent Framework (TCF). W 15 z tych 576 aplikacji odmowa nie była zapisywana tak jak pełna zgoda.
Drugi wynik dotyczy tego, co działo się już poza ekranem zgody. Po odrzuceniu wszystkich celów 364 z 550 analizowanych aplikacji TCF, czyli 66,2 proc., wysyłały Android Advertising ID (AAID). W osobnym teście 284 z 513 aplikacji, czyli 55,3 proc., przekazywały AAID jeszcze podczas obsługi banera, zanim użytkownik zatwierdził jakikolwiek wybór. To ważne rozróżnienie: jedno badanie wykryło problem z zapamiętywaniem odmowy, drugie pokazało transmisję identyfikatora reklamowego. Nie należy wrzucać obu zjawisk do jednego worka.
W 15 aplikacjach pełna zgoda była zapamiętywana, a odmowa nie
TCF to standard rozwijany przez IAB Europe dla ekosystemu reklamy cyfrowej. Jego zadaniem jest m.in. zapisywanie i przekazywanie informacji o wyborach użytkownika pomiędzy aplikacją, platformą zarządzania zgodami i uczestniczącymi w systemie dostawcami. Nie jest to jeden program odpowiedzialny za prywatność całej aplikacji.
Widoczny formularz jest zwykle obsługiwany przez CMP, czyli Consent Management Platform. Stan decyzji może być następnie zapisany m.in. w postaci TC String, a biblioteki i dostawcy działający w aplikacji powinni odpowiednio reagować na otrzymane sygnały. Problem zaczyna się wtedy, gdy interfejs mówi jedno, a kod aplikacji lub dołączony SDK robi coś innego.
Badacze zbierali aplikacje z rankingów Google Play od 29 stycznia do 10 marca 2025 r. Uzyskali 5067 unikalnych pozycji. 4482 aplikacje udało się pobrać na przygotowane urządzenie testowe; pozostałe 585 odpadło m.in. z powodu niedostępności, płatnego dostępu, prerejestracji albo problemów z działaniem na emulatorze.
Samo znalezienie śladów TCF w plikach aplikacji jeszcze nie wystarczało. Framework inicjalizowały 842 aplikacje, ale badacze wymagali również możliwości potwierdzenia jego użycia przez działający formularz. Po tej weryfikacji pozostało 576 aplikacji rzeczywiście wykorzystujących TCF, czyli 12,85 proc. z 4482 pobranych programów.
Następnie automatycznie obsługiwano formularze za pomocą Appium i narzędzi Androida oraz sprawdzano, czy ustawienia zapisane przez CMP odpowiadają wykonanej operacji. Wtedy pojawiła się grupa 15 aplikacji, w których wybory były trwale zapisywane tylko po udzieleniu zgody na całość przetwarzania.
W publikacji wymieniono:
- Sweet Beauty Camera Filter
- Geotag Photo: Camera Location
- Control Center Simple
- Draw Animation – Anim Creator
- Silly Smiles Live Wallpaper 4K
- AR Draw Sketch: Trace & Paint
- Easy Piano Keyboard – Piano88
- Find Phone by Clap, Whistle
- Caller ID Name, Location & SMS
- Chat AI – AI Chatbot Friend
- Dating – Chat & Meet Singles
- Locate Mobile by Number
- Phone Tracker By Number
- Books – Read and Download
- PDF Viewer: PDF Fill & Sign
Ta lista wymaga jednego istotnego zastrzeżenia. Są to aplikacje i wersje zaobserwowane podczas badania prowadzonego w 2025 r. Nie jest to dowód, że wersja którejkolwiek z nich dostępna obecnie w Google Play nadal zachowuje się identycznie. Po aktualizacji błąd mógł zostać poprawiony, aplikacja mogła zmienić CMP albo cały sposób obsługi zgód.
Sam fakt ponownego wyświetlenia formularza również nie przesądza automatycznie o nieprawidłowości. Ponowne zebranie decyzji może być uzasadnione po istotnej zmianie celów przetwarzania, zmianie zestawu partnerów albo po świadomym usunięciu zapisanych danych aplikacji. Tutaj mechanizm był bardziej charakterystyczny: „tak” przetrwało ponowne uruchomienie, a „nie” nie.
To właśnie odróżnia zwykłe ponowienie zgody od mechanizmu określanego jako nagging. Jeżeli użytkownik musi przy każdym uruchomieniu wykonywać tę samą czynność tylko dlatego, że odmówił, aplikacja tworzy asymetrię: zgoda usuwa przeszkodę, odmowa pozostawia ją na kolejne uruchomienie. Przy piątym czy dziesiątym pojawieniu się formularza część osób zaakceptuje wszystko nie dlatego, że zmieniła decyzję dotyczącą danych, lecz dlatego, że chce wreszcie dostać się do programu.
Dla polskiego użytkownika znaczenie ma tu nie tylko RODO. Art. 399 Prawa komunikacji elektronicznej reguluje przechowywanie informacji lub dostęp do informacji już zapisanej w urządzeniu końcowym i co do zasady wymaga wcześniejszego poinformowania użytkownika oraz jego zgody, z wyjątkami m.in. dla działań koniecznych do transmisji albo dostarczenia usługi żądanej przez użytkownika. Art. 400 odsyła przy uzyskiwaniu tej zgody do zasad ochrony danych osobowych. To nie daje podstawy do wydawania wyroku o każdej pojedynczej aplikacji na podstawie samego banera, ale pokazuje, dlaczego moment uzyskania zgody technicznie ma znaczenie.
AAID był wysyłany także po odmowie, a w części aplikacji jeszcze przed decyzją
Najciekawsza część eksperymentu zaczynała się tam, gdzie kończy się możliwość oceny aplikacji gołym okiem. Poprawnie wyglądający baner nie mówi, kiedy uruchomiło się SDK reklamowe ani jakie dane zdążyły już opuścić telefon.
Badacze przygotowali emulowane urządzenie Google Pixel 9 Pro z API 35. Zapewnili mu europejski adres IP oraz współrzędne lokalizacji wskazujące państwo UE. Ruch sieciowy był przechwytywany przy pomocy mitmproxy, a w aplikacjach stosujących SSL pinning badacze korzystali z Objection opartego na Fridzie, aby umożliwić analizę zaszyfrowanych połączeń HTTPS. Aplikacje, które po takiej ingerencji natychmiast się zamykały albo blokowały analizę, były oznaczane jako niemożliwe do przebadania w tym etapie.
Nie szukano wyłącznie AAID. Mechanizm analizy sprawdzał żądania pod kątem Android Advertising ID, publicznego adresu IP, e-maila, numeru telefonu, IMEI, adresu MAC, współrzędnych GPS, IMSI, ICCID i numeru seryjnego telefonu. W przechwyconych danych z tego eksperymentu wykryto jednak AAID i adresy IP. Ponieważ adres IP jest z natury widoczny przy zestawianiu komunikacji sieciowej, publikowane wyniki dotyczące przesyłania danych skoncentrowano na AAID.
AAID jest resetowalnym identyfikatorem reklamowym Androida. Systemy reklamowe i atrybucyjne mogą wykorzystywać go do rozpoznawania urządzenia pomiędzy zdarzeniami, przypisywania instalacji lub działania do kampanii, pomiaru reklamy czy budowania ciągłości aktywności reklamowej. Nie jest więc odpowiednikiem losowego numeru technicznego potrzebnego wyłącznie do otworzenia ekranu aplikacji.
Ruch analizowano w dwóch etapach.
W teście pasywnym decyzja dotycząca banera była już zapisana. Aplikację uruchamiano i przez 40 sekund pozostawiano bez dalszej interakcji. Spośród programów, z którymi udało się wcześniej prawidłowo wykonać test dynamiczny, ruch sieciowy można było przeanalizować w 550. Jedenaście kolejnych aplikacji odpadało m.in. dlatego, że ulegały awarii lub nie pozwalały skutecznie wyłączyć SSL pinningu.
Przy scenariuszu odrzucenia wszystkich celów AAID wysyłały 364 z 550 aplikacji — 66,2 proc.
Nie oznacza to 66,2 proc. wszystkich aplikacji na Androida ani nawet 66,2 proc. wszystkich aplikacji z Google Play. Mianownikiem jest tutaj konkretna grupa 550 analizowanych aplikacji wykorzystujących TCF, które przeszły wcześniejsze etapy badania.
Drugi eksperyment był jeszcze bardziej interesujący, bo badał moment, w którym użytkownik dopiero widział formularz. Badacze resetowali zapisane wybory i uruchamiali przechwytywanie ruchu podczas wyświetlania oraz obsługi banera, zanim decyzja została zatwierdzona. Po wyborze ruch obserwowano jeszcze przez 20 sekund.
Ten etap przeprowadzono od 15 do 21 maja 2025 r. na 513 aplikacjach. W 284 przypadkach, czyli 55,3 proc., AAID pojawił się w ruchu sieciowym już podczas interakcji z formularzem zgody.
Techniczny fakt jest więc precyzyjny: badacze wykryli żądania zawierające AAID przed potwierdzeniem wyboru użytkownika. Osobną kwestią jest ocena prawna. Autorzy publikacji interpretują takie zachowanie jako problem z wymogiem wcześniejszej zgody dla dostępu i wykorzystania mobilnego identyfikatora reklamowego. Nie należy natomiast z samego przechwyconego pakietu wyciągać wniosku, że właściciel każdej domeny, do której trafiło żądanie, samodzielnie zdecydował o uruchomieniu transmisji.
Wśród często występujących domen odbierających AAID pojawiały się m.in. domeny należące lub powiązane z systemami Facebooka, Adjust, Unity, Google i Rayjump. Aplikacja mobilna może mieć jeden ekran zgody przygotowany przez CMP, ale równocześnie korzystać z kilku bibliotek reklamowych, analitycznych lub atrybucyjnych. Błąd może powstać na granicy pomiędzy stanem zgody a momentem inicjalizacji konkretnego SDK.
To jest też powód, dla którego sama zmiana dostawcy CMP może niczego nie naprawić. W badanej grupie Google LLC było CMP w 517 z 576 aplikacji, czyli w 89,76 proc. przypadków, ale transmisję AAID wykrywano również w aplikacjach używających innych rozwiązań. Nie można z tego wyprowadzić wniosku, że Google odpowiada za wszystkie wykryte transmisje. Można wyprowadzić inny: wydawca nie powinien traktować instalacji CMP jako dowodu, że wszystkie biblioteki w aplikacji respektują stan zgody.
Audyt trzeba zacząć od ruchu sieciowego, nie od wyglądu formularza
Jeżeli zespół testuje tylko wariant „Akceptuję wszystko”, może przejść przez cały proces QA i nie zauważyć najważniejszego błędu. Przy pełnej zgodzie uruchomienie bibliotek reklamowych jest oczekiwane. Dopiero odmowa pokazuje, czy aplikacja potrafi rzeczywiście czegoś nie uruchomić.
Pierwszy test powinien być najprostszy: czysta instalacja, pierwsze uruchomienie, brak jakiegokolwiek kliknięcia na banerze i obserwacja połączeń wychodzących. Trzeba zanotować moment inicjalizacji zewnętrznych SDK, pierwsze żądania sieciowe oraz występowanie AAID lub innych identyfikatorów. Jeśli biblioteka reklamowa zaczyna działać przed uzyskaniem sygnału, problem znajduje się niżej niż warstwa interfejsu.
Drugi test to czysta instalacja i „Odrzuć wszystko”. Po wyborze należy obserwować ruch, zamknąć aplikację, uruchomić ją ponownie i sprawdzić dwie rzeczy naraz: czy blokowane biblioteki nadal pozostają zablokowane oraz czy odmowa została zapisana. Baner, który wraca po każdej odmowie, jest błędem innego rodzaju niż SDK wysyłające dane pomimo prawidłowo zapisanego wyboru. Te usterki wymagają innej naprawy.
Trzeci wariant powinien obejmować zgodę częściową, jeżeli CMP i konfiguracja aplikacji taką możliwość oferują. Tu najłatwiej znaleźć błędne mapowanie celów: użytkownik zezwala np. na jeden rodzaj przetwarzania, a biblioteka zachowuje się tak, jakby otrzymała zgodę na wszystko.
Dopiero czwarty test powinien sprawdzać „Akceptuję wszystko”. Jego wartość polega przede wszystkim na porównaniu ruchu. Jeżeli wariant pełnej zgody i pełnej odmowy generują prawie identyczny zestaw żądań reklamowych oraz identyfikatorów, trzeba sprawdzić, czy stan z CMP rzeczywiście dociera do bibliotek i czy SDK nie jest inicjalizowany zbyt wcześnie.
W każdym z tych scenariuszy dobrze rejestrować ten sam zestaw informacji: wersję aplikacji i Androida, czas pierwszego żądania, docelową domenę, inicjalizowany SDK, obecność AAID, aktualny stan zgody oraz zachowanie po ponownym uruchomieniu. Taki zapis pozwala później odróżnić problem CMP od błędu integracji, konfiguracji biblioteki albo kolejności wykonywania kodu.
Badanie ma jednak ograniczenia i nie wolno ich pomijać tylko dlatego, że wyniki są efektowne. Zbiór obejmował popularne aplikacje z rankingów kategorii, a nie losową próbę wszystkich programów na Androida. 585 aplikacji nie udało się pobrać. Spośród 12 typów CMP rozpoznanych w aplikacjach inicjalizujących framework badacze automatycznie obsługiwali sześć; pozostałe występowały bardzo rzadko lub miały zbyt niestandardowe formularze. Autorzy szacują, że na tym etapie z analizy odrzucono z tego powodu 1,90 proc. aplikacji.
Drugie ograniczenie dotyczy samych danych. Automat szukał konkretnych wartości w adresach i treści żądań, ale nie obejmował systematycznie danych poddanych transformacji, np. hashowaniu SHA albo kodowaniu Base64. Ręczna kontrola próbki nie ujawniła takiego zjawiska, lecz nie oznacza to, że żadna aplikacja nie mogła przesyłać danych w formie, której automat nie rozpoznał.
Trzecie ograniczenie to emulator. Pixel 9 Pro z API 35 zapewniał powtarzalne środowisko i umożliwiał analizę tysięcy programów, ale aplikacja może zachowywać się inaczej na fizycznym telefonie. Część programów faktycznie wykrywała elementy środowiska testowego lub ingerencję w SSL pinning. Wyniki są więc mocnym pomiarem dużej próbki, a nie gwarancją identycznego zachowania każdego urządzenia.
Dochodzi do tego czas. Testy wykonano w 2025 r. Tymczasem TCF nadal się zmienia. Okres migracji do TCF 2.3 zakończył się 28 lutego 2026 r., a od 1 marca nowe TC Stringi powinny uwzględniać m.in. obowiązkową informację o ujawnionych dostawcach. Autorzy opublikowanej wersji badania zaznaczają wprost, że zmiany TCF 2.3 nie wpływają na opisane przez nich wyniki.
Na tym rozwój frameworka się nie zatrzymał. 23 lipca 2026 r. opublikowano specyfikację TCF 2.4, a termin wdrożenia nowych wymagań przez CMP w środowisku aplikacji mobilnych i CTV wyznaczono na 23 lutego 2027 r. Zmiany dotyczą m.in. sposobu przedstawiania użytkownikowi informacji o funkcjach. Nie można jednak zakładać, że kolejna wersja specyfikacji sama naprawi źle ustawioną kolejność inicjalizacji SDK w konkretnej aplikacji. To trzeba sprawdzić w działającym programie.
Zwykły użytkownik ma znacznie mniejsze możliwości niż zespół wykonujący audyt. Z samego wyglądu banera nie da się stwierdzić, czy AAID został wysłany. Można za to wykonać prosty test trwałości decyzji: wybrać „Odrzuć wszystko”, całkowicie zamknąć aplikację, uruchomić ją ponownie i sprawdzić, czy wybór pozostał zapisany. Przy zgłaszaniu problemu warto zapisać nazwę i wersję programu, wersję Androida, datę testu, dokładną kolejność wykonanych czynności oraz zrobić zrzuty kolejnych ekranów. W Polsce sprawami dotyczącymi ochrony danych osobowych zajmuje się Prezes Urzędu Ochrony Danych Osobowych.
Nie ma natomiast sensu formułować zgłoszenia wyłącznie jako „aplikacja mnie śledzi”, jeśli jedyną obserwacją jest powracający formularz. Znacznie mocniejsza jest informacja: „po wybraniu pełnej odmowy i ponownym uruchomieniu aplikacji formularz wraca, natomiast po udzieleniu pełnej zgody nie pojawia się ponownie”. To opis zachowania, które da się odtworzyć.
FAQ
Czy 66,2 proc. oznacza, że dwie trzecie wszystkich aplikacji na Androida wysyła AAID po odmowie?
Nie. Wynik dotyczy 364 z 550 aplikacji wykorzystujących TCF, dla których udało się przeprowadzić pasywną analizę ruchu. Nie można przenosić tego odsetka na cały Google Play.
Czy każda aplikacja pokazująca baner ponownie po odmowie działa nieprawidłowo?
Nie. Ponowne zebranie decyzji może być uzasadnione np. po istotnej zmianie warunków lub celów przetwarzania. W badaniu charakterystyczne było to, że pełna zgoda była zapisywana, natomiast odmowa lub ograniczenie zgody powodowały ponowne wyświetlenie formularza przy następnym uruchomieniu.
Czy wysłanie AAID oznacza automatycznie, że użytkownik został już sprofilowany?
Nie. Badanie wykrywało transmisję identyfikatora reklamowego, a nie cały późniejszy proces wykonywany po stronie odbiorcy. Samo wykrycie AAID nie pozwala ustalić wszystkich operacji, które zostały na nim później wykonane.
Czy domena, do której wysłano AAID, automatycznie odpowiada za błąd aplikacji?
Nie. Żądanie może wynikać z działania zewnętrznego SDK wbudowanego przez wydawcę programu, a ustalenie odpowiedzialności wymaga analizy konfiguracji, ról poszczególnych podmiotów i celu przetwarzania. Lista domen z badania pokazuje kierunek transmisji, a nie gotowy podział odpowiedzialności prawnej.
Czy wyniki dotyczą aktualnych wersji 15 wymienionych aplikacji?
Nie można tego założyć. Obserwacje dotyczą wersji dostępnych w okresie badania w 2025 r. Aktualizacja aplikacji mogła zmienić jej zachowanie, dlatego dzisiejszą wersję należałoby zbadać ponownie.
Czy prawidłowo wyglądający baner oznacza, że aplikacja respektuje odmowę?
Nie. Baner potwierdza jedynie, że użytkownik dostał interfejs do wykonania wyboru. Dopiero sprawdzenie stanu zapisanego przez CMP oraz ruchu sieciowego pokazuje, czy SDK rzeczywiście reagują na tę decyzję.
Co sprawdzić jako pierwsze w aplikacji korzystającej z TCF?
Najpierw wykonaj czystą instalację i przechwyć ruch przed kliknięciem czegokolwiek na banerze. Jeżeli już wtedy AAID lub inny identyfikator przeznaczony do funkcji wymagających zgody trafia do zewnętrznego SDK, napraw właśnie tę kolejność inicjalizacji. Dopiero po zatrzymaniu przedwczesnej transmisji ma sens dopracowywanie wyglądu formularza i pozostałych ścieżek zgody.
Najnowsze komentarze