Etykiety prywatności macOS mogą nie mówić całej prawdy – analiza 1000 aplikacji wykazała, że 85% korzystało z API danych użytkownika bez pełnego ujawnienia, a część przekazywała identyfikatory sieciom reklamowym

Etykieta prywatności w Mac App Store wygląda jak szybka odpowiedź na proste pytanie: co aplikacja robi z moimi danymi? Problem w tym, że deklaracja widoczna przed instalacją nie zawsze odpowiada temu, co program robi po uruchomieniu. Analiza 1000 aplikacji dla macOS pokazała skalę rozbieżności, której trudno sprowadzić do kilku niedopatrzeń: tylko około 15% badanych programów prawidłowo ujawniało wszystkie kategorie danych odpowiadające wrażliwym informacjom, do których uzyskiwały dostęp. Aż 85% korzystało z API pozwalających sięgnąć do danych użytkownika bez pełnego odzwierciedlenia tego w etykiecie prywatności.
Nie oznacza to automatycznie, że 850 aplikacji wykradało dane albo wysyłało je reklamodawcom. To ważne rozróżnienie. Sam dostęp do API, faktyczne pobranie informacji i wysłanie ich poza komputer są trzema różnymi zdarzeniami. Badacze sprawdzili je osobno — i właśnie analiza ruchu sieciowego przyniosła drugi, bardziej praktyczny problem.
85% aplikacji z niepełną deklaracją. Jak dokładnie przeprowadzono badanie?
Badanie przygotowane przez Jyotirmaya Chauhana, Kostasa Solomosa, Mira Masooda Alego i Jasona Polakisa wykorzystało system NutriScan, łączący analizę statyczną pakietu aplikacji z obserwacją jej zachowania podczas pracy. Autorzy nie ograniczyli się więc do czytania polityk prywatności albo porównywania opisów zamieszczonych przez deweloperów. Sprawdzali między innymi deklarowane uprawnienia, privacy manifests, wywołania natywnych API oraz ruch wychodzący z aplikacji.
Punktem wyjścia była pula ponad 1800 programów dla macOS. Z analizy wyłączono około 350 aplikacji, które stosowały mechanizmy uniemożliwiające dynamiczną instrumentację wykorzystywanym przez badaczy narzędziem Frida. Ostateczny zestaw obejmował dokładnie 1000 aplikacji:
-
500 popularnych aplikacji, wybranych głównie na podstawie liczby ocen użytkowników,
-
500 aplikacji losowych z pozostałej części zbioru.
W pierwszej grupie znalazły się między innymi programy z kategorii Productivity, Utilities, Photo & Video, Business, Music czy Health & Fitness. Druga obejmowała również narzędzia deweloperskie, programy graficzne i aplikacje edukacyjne. Nie był to więc test jednej szczególnej klasy oprogramowania.
Eksperyment prowadzono na MacBooku Air z układem M4 i świeżym kontem Apple. Każdą aplikację uruchamiano i obsługiwano przez około 5 minut. Badacze wybrali taki próg po wcześniejszych testach, w których dłuższe sesje nie ujawniały już dodatkowych naruszeń. Dla 14,9% programów wymagających rejestracji tworzono konto testowe, a w przypadku 47 aplikacji aktywowano dostępną wersję próbną.
To istotne również przy interpretacji wyników. Pięć minut nie obejmuje każdego możliwego ekranu, funkcji i scenariusza użycia. Autorzy sami wskazują to jako ograniczenie NutriScan. Badanie może zatem nie wykrywać części zachowań ujawniających się dopiero po dłuższym czasie albo po wykonaniu specyficznej czynności. Nie działa to jednak w drugą stronę: wykryte połączenia sieciowe czy wywołania API są rzeczywistymi zachowaniami zaobserwowanymi podczas testu.
Najbardziej uderzająca była różnica pomiędzy tym zachowaniem a etykietami App Store. Tylko około 15% programów deklarowało kompletny zestaw kategorii odpowiadających wrażliwym danym, do których uzyskiwały dostęp. Problemy występowały częściej w mniej popularnej części próby: niemal 45% aplikacji losowych autorzy uznali za całkowicie niezgodne w badanym zakresie, wobec około 30% popularnych programów.
To pokazuje również niewygodną cechę całego systemu: elegancka etykieta jest końcowym produktem procesu deklaracyjnego, a nie pełnym raportem z technicznego audytu programu.
Dane nie zawsze zostawały na Macu. 497 aplikacji komunikowało je na zewnątrz
Najpoważniejszy wynik pojawia się dopiero po przejściu od pytania „do czego aplikacja ma dostęp?” do pytania „co rzeczywiście wysyła przez sieć?”.
Spośród tysiąca przebadanych programów 497 przesyłało informacje dotyczące użytkownika lub urządzenia poza komputer. W tej grupie 204 aplikacje przekazywały identyfikatory objęte kategoriami przewidzianymi przez system etykiet prywatności, a 62 z tych aplikacji nie miały odpowiadającej temu deklaracji. Oznacza to około 12,5% wszystkich 497 programów wysyłających dane.
Pozostała część obserwowanego ruchu obejmowała również parametry przydatne do fingerprintingu urządzenia, między innymi:
-
wersję systemu macOS,
-
wersję kernela Darwin,
-
oznaczenie modelu Maca,
-
model układu,
-
rozdzielczość ekranu,
-
typ wyświetlacza,
-
nazwę użytkownika lub komputera w przypadkach, w których była dostępna.
W badaniu wersja kernela pojawiała się w ruchu 408 aplikacji, wersja systemu w 362, model chipsetu w 241, a identyfikator modelu Maca w 222. Część takich informacji może trafiać do połączeń automatycznie, na przykład poprzez ciąg User-Agent tworzony przez CFNetwork. To kolejny powód, dla którego nie każde przesłanie parametru technicznego należy utożsamiać ze świadomym budowaniem profilu reklamowego. Jednocześnie zestaw kilku stabilnych właściwości urządzenia może zwiększyć skuteczność fingerprintingu.
Wśród domen odbierających informacje często występowała infrastruktura związana z Google, Amazonem i Facebookiem/Meta — między innymi domeny googleapis.com, 1e100.net, amazonaws.com, cloudfront.net, fbcdn.net i facebook.com. Same połączenia z tymi domenami również nie dowodzą automatycznie targetowania reklam: część infrastruktury służy do hostingu, analityki, przechowywania plików, raportowania błędów czy dystrybucji treści. Badanie pokazuje natomiast coś bardziej konkretnego: informacje o użytkowniku i urządzeniu faktycznie opuszczały aplikacje i trafiały do podmiotów świadczących między innymi usługi reklamowe, analityczne oraz infrastrukturalne.
Szczególnie problematyczne są trwałe identyfikatory użytkownika i urządzenia. Badacze znaleźli przypadki przekazywania takich danych do sieci reklamowych powiązanych między innymi z Google i Facebookiem. Łączenie identyfikatora z właściwościami urządzenia pozwala nie tylko rozpoznać kolejną sesję tej samej aplikacji. Może również zwiększać skuteczność korelowania aktywności pomiędzy różnymi usługami i urządzeniami.
Dla użytkownika z Polski ma to dodatkowy wymiar. W rozumieniu RODO identyfikatorem nie musi być nazwisko ani adres e-mail. Informacja umożliwiająca bezpośrednią albo pośrednią identyfikację osoby — w tym identyfikator internetowy czy dane lokalizacyjne — może stanowić dane osobowe. Z samej rozbieżności między etykietą App Store a zachowaniem programu nie można jednak automatycznie wyprowadzić wniosku o naruszeniu RODO. Trzeba jeszcze ustalić administratora danych, podstawę i cel przetwarzania, zakres obowiązku informacyjnego oraz to, czy użytkownik otrzymał wymagane informacje innym kanałem.
Najsłabszym ogniwem okazują się SDK i mechanizm deklaracji
Apple wymaga, aby informacje prezentowane w sekcji prywatności App Store obejmowały nie tylko kod napisany przez producenta aplikacji. Deweloper odpowiada również za dane zbierane przez zewnętrzne SDK, na przykład biblioteki reklamowe i analityczne, oraz powinien ujawnić, co taki kod zbiera, w jakim celu i czy informacje są wykorzystywane do śledzenia.
W praktyce właśnie tutaj powstaje sporo luk. Autorzy badania stwierdzili, że wśród programów zawierających privacy manifests w ponad 80% przypadków deweloperzy nie uwzględniali w pełni danych zbieranych przez osadzony kod firm trzecich. Dla kategorii „Other Diagnostic Data” brak odpowiadającej pozycji w etykiecie dotyczył 37,5% deklaracji zawartych w manifestach, dla „Other Data Types” było to 20,2%, dla „Device ID” 12,5%, a dla historii zakupów 9,5%.
To nie jest drobny problem dokumentacyjny. SDK potrafi zmienić zakres zbieranych danych bez widocznej zmiany podstawowej funkcji aplikacji. Program do edycji zdjęć nadal edytuje zdjęcia, komunikator nadal wysyła wiadomości, a aplikacja do notatek nadal zapisuje tekst — jednocześnie nowa wersja biblioteki analitycznej może wprowadzić dodatkową telemetrię. Jeżeli producent aktualizuje zależność, ale nie wraca do deklaracji w App Store Connect, etykieta szybko przestaje opisywać aktualny stan programu.
Apple częściowo próbuje ograniczać ten problem poprzez Privacy Manifests i podpisy dla zewnętrznych SDK. Firma wymaga także informacji o praktykach dotyczących danych przy przesyłaniu nowych programów i aktualizacji do App Store. Samą deklarację prywatności deweloper może jednak zmienić bez ponownego przesyłania wersji aplikacji do App Review.
W tym miejscu warto odróżnić jeszcze etykiety prywatności od App Tracking Transparency. Apple opisuje ATT jako obowiązek uzyskania pozwolenia między innymi przed śledzeniem użytkownika pomiędzy aplikacjami i stronami innych firm oraz przed dostępem do identyfikatora reklamowego, ale jego podstawowe wymagania dotyczą iOS, iPadOS i tvOS. Nie należy więc zakładać, że model ochrony znany użytkownikowi iPhone’a działa identycznie w natywnych aplikacjach macOS.
Apple wyraźnie zabrania również obchodzenia ograniczeń poprzez tworzenie alternatywnych identyfikatorów urządzenia do trackingu i wskazuje fingerprinting jako praktykę niedozwoloną w ramach swoich zasad dla deweloperów. To jednak nie zmienia głównego wniosku z badania: mechanizm deklaracyjny i techniczne zachowanie aplikacji mogą się rozjechać, a użytkownik oglądający wyłącznie etykietę nie ma narzędzia do samodzielnego wykrycia tej różnicy.
Dla osób administrujących Macami w firmie sensowniejsze jest więc traktowanie etykiety jako pierwszego filtra, a nie dowodu zgodności. Przy programach mających dostęp do dokumentów, kontaktów, lokalizacji albo kont służbowych trzeba dodatkowo sprawdzić producenta, listę wbudowanych SDK, połączenia wychodzące oraz politykę prywatności. W środowisku zarządzanym przez MDM szczególnie ostrożnie należy podchodzić do darmowych narzędzi instalowanych poza zatwierdzonym katalogiem aplikacji.
Jeżeli potrzebujesz dodatkowego materiału dotyczącego tej kwestii, zobacz ANCHOR.
FAQ
Czy wynik 85% oznacza, że 850 z 1000 aplikacji wysyłało prywatne dane do reklamodawców?
Nie. 85% dotyczyło korzystania z API danych użytkownika bez pełnego ujawnienia tego w etykiecie. Osobno ustalono, że 497 aplikacji przesyłało informacje o użytkowniku lub urządzeniu przez sieć.
Czy połączenie aplikacji z serwerem Google, Amazona albo Meta oznacza śledzenie reklamowe?
Nie. Te firmy dostarczają także hosting, CDN, analitykę, systemy błędów i inne usługi techniczne. Znaczenie ma rodzaj przesyłanych danych, cel transmisji i możliwość powiązania ich z użytkownikiem lub urządzeniem, a nie sama nazwa domeny.
Czy etykiety prywatności w Mac App Store są weryfikowane automatycznie na podstawie zachowania programu?
Nie w takim znaczeniu, że użytkownik dostaje gwarantowany raport z pełnej analizy ruchu i wszystkich wywołań API. Informacje w sekcji prywatności są deklarowane przez dewelopera, który odpowiada również za działanie zastosowanych SDK firm trzecich.
Czy brak informacji w etykiecie automatycznie oznacza naruszenie RODO?
Nie. Etykieta Apple i obowiązek informacyjny wynikający z RODO to różne mechanizmy. W UE trzeba ocenić między innymi, czy przesyłana informacja jest daną osobową, kto jest administratorem, w jakim celu i na jakiej podstawie ją przetwarza oraz jakie informacje przekazano użytkownikowi.
Co zwykły użytkownik Maca może realnie sprawdzić przed instalacją?
Najpierw etykietę w App Store, później politykę prywatności producenta i zakres żądanych uprawnień. Jeżeli prosty program — przykładowo kalkulator, konwerter plików lub narzędzie do zmiany nazw — chce dostępu do kontaktów, lokalizacji albo szerokiego zakresu plików bez oczywistego uzasadnienia funkcjonalnego, jest to wystarczający powód, żeby poszukać alternatywy.
Czy aplikacja z etykietą „Data Not Collected” daje gwarancję, że niczego nie wysyła?
Nie. Etykieta jest deklaracją dotyczącą określonych kategorii i zasad Apple, a nie techniczną gwarancją braku jakiejkolwiek komunikacji sieciowej. Program może przecież łączyć się z serwerem chociażby po aktualizacje czy treści. Problem zaczyna się wtedy, gdy transmitowane informacje powinny zostać ujawnione, a deklaracja tego nie odzwierciedla.
Pierwszy błąd do usunięcia jest prosty: nie traktować etykiety prywatności jako certyfikatu bezpieczeństwa ani kompletnego audytu danych. Przy aplikacji mającej dostęp do dokumentów służbowych, kontaktów, lokalizacji lub konta Apple najpierw sprawdź zakres uprawnień i producenta, następnie jego politykę prywatności, a dopiero później uznaj deklarację z App Store za dodatkowy argument. Jeśli funkcja programu nie uzasadnia dostępu do konkretnej kategorii danych, odmowa uprawnienia albo wybór innej aplikacji ma wyższy priorytet niż analizowanie marketingowych zapewnień o prywatności.