Najlepsze praktyki dotyczące unikatowych identyfikatorów

Ten dokument zawiera wskazówki dotyczące wyboru odpowiednich identyfikatorów dla twojej aplikacji w oparciu o twój przypadek użycia.

Aby zapoznać się z ogólnym spojrzeniem na uprawnienia w systemie Android, zobaczPrzegląd uprawnień. Aby uzyskać konkretne najlepsze praktyki dotyczące pracy z uprawnieniami Androida, zobacz App permissions bestpractices.

Najlepsze praktyki dotyczące pracy z identyfikatorami Androida

Przy pracy z identyfikatorami Androida należy przestrzegać tych najlepszych praktyk:

1. Unikaj używania identyfikatorów sprzętowych. W większości przypadków użycia można uniknąć używania identyfikatorów sprzętowych, takich jak SSAID (Android ID), bez ograniczania wymaganej funkcjonalności.

   Android 10 (poziom API 29) dodaje ograniczenia dla nieresetowalnych identyfikatorów, które obejmują zarówno IMEI, jak i numer seryjny. Twoja aplikacja musi być aplikacją właściciela urządzenia lub profilu, mieć specjalne uprawnienia operatora lub uprawnienie uprzywilejowane READ_PRIVILEGED_PHONE_STATE w celu uzyskania dostępu do tych identyfikatorów.

2. Używaj identyfikatora reklamowego tylko w przypadkach profilowania użytkownika lub reklam. W przypadku korzystania z identyfikatora reklamowego należy zawsze przestrzegać wyborów użytkowników dotyczących śledzenia reklam. Upewnij się również, że identyfikator nie może być połączony z informacjami umożliwiającymi identyfikację osoby (PII) i unikaj mostkowania resetów identyfikatora reklamowego.

3. Używaj identyfikatora instalacji Firebase (FID) lub prywatnie przechowywanego identyfikatora GUID, gdy tylko jest to możliwe, we wszystkich innych przypadkach użycia, z wyjątkiem zapobiegania oszustwom płatniczym i telefonii. W zdecydowanej większości przypadków użycia niezwiązanych z reklamami, FID lub GUID powinien być wystarczający.

4. Używaj API odpowiednich dla danego przypadku użycia, aby zminimalizować ryzyko utraty prywatności. Użyj interfejsów API DRM do ochrony treści o wysokiej wartości i interfejsów API SafetyNet do ochrony przed nadużyciami. Interfejsy API SafetyNet są najprostszym sposobem na określenie, czy urządzenie jest autentyczne bez ponoszenia ryzyka utraty prywatności.

Pozostałe sekcje tego przewodnika rozwijają te zasady w kontekście tworzenia aplikacji na Androida.

Pracuj z identyfikatorami reklam

Reklamowy identyfikator jest identyfikatorem resetowanym przez użytkownika i jest odpowiedni dla przypadków użycia reklam. Należy jednak pamiętać o kilku kluczowych kwestiach podczas korzystania z tego identyfikatora:

Zawsze respektuj intencje użytkownika dotyczące resetowania identyfikatora reklamowego.Nie pomijaj resetowania identyfikatorów przez użytkownika, używając innego identyfikatora lub odcisku palca do łączenia ze sobą kolejnych identyfikatorów reklamowych bez zgody użytkownika. Polityka Google Play Developer ContentPolicy stanowi, co następuje:

„…po zresetowaniu nowy identyfikator reklamowy nie może być połączony z poprzednim identyfikatorem reklamowym ani z danymi pochodzącymi z poprzedniego identyfikatora reklamowego bez wyraźnej zgody użytkownika.”

Zawsze respektuj powiązaną flagę Personalized Ads. Identyfikatory reklamowe są konfigurowalne w taki sposób, że użytkownicy mogą ograniczyć ilość śledzenia związanego z danym identyfikatorem. Zawsze używaj metody AdvertisingIdClient.Info.isLimitAdTrackingEnabled(), aby upewnić się, że nie obchodzisz życzeń swoich użytkowników. The GooglePlay Developer ContentPolicy states thefollowing:

„…you must abide by a user’s 'Opt out of interest-based advertising’ or’Opt out of Ads Personalization’ setting. Jeśli użytkownik włączył to ustawienie, nie można używać identyfikatora reklamowego do tworzenia profili użytkowników do celów reklamowych lub do kierowania do użytkowników spersonalizowanych reklam. Dozwolone działania obejmują reklamy kontekstowe, ograniczanie częstotliwości, śledzenie konwersji, raportowanie i bezpieczeństwo oraz wykrywanie oszustw.”

Należy pamiętać o wszelkich politykach prywatności lub bezpieczeństwa związanych z używanymi zestawami SDK, które są związane z używaniem identyfikatora reklamowego.Na przykład, jeśli przekażesz true do metodyenableAdvertisingIdCollection() z Google Analytics SDK, upewnij się, że zapoznałeś się i przestrzegasz wszystkich stosownych zasad Analytics SDK.

Należy również pamiętać, że Google Play Developer ContentPolicy wymaga, aby Advertising ID „nie może być połączony z informacjami umożliwiającymi identyfikację osoby lub powiązany z jakimkolwiek trwałym identyfikatorem urządzenia (na przykład:SSAID, adres MAC, IMEI, itp,).”

Jako przykład, załóżmy, że chcesz zebrać informacje, aby wypełnić tabele danych z następującymi kolumnami:

W tym przykładzie, kolumna ad_id mogłaby zostać połączona z PII poprzez kolumnę account_id w obu tabelach, co stanowiłoby naruszenie zasad Google Play DeveloperContent Policy, jeśli nie uzyskasz wyraźnego pozwolenia od swoich użytkowników.

Pamiętaj, że powiązania między Advertiser ID a PII nie zawsze są tak jednoznaczne. Możliwe jest posiadanie „quasi-identyfikatorów”, które pojawiają się zarówno w tabelach kluczowych PII, jak iAd ID, co również powoduje problemy. Na przykład, załóżmy, że zmieniamyTABLE-01 i TABLE-02 w następujący sposób:

W tym przypadku, przy wystarczająco rzadkich zdarzeniach kliknięcia nadal możliwe jest połączenie identyfikatora reklamodawcy TABLE-01 i informacji PII zawartych w TABLE-02 przy użyciu znacznika czasowego zdarzenia i modelu urządzenia.

Inne rozwiązania obejmują następujące czynności:

• Nieprojektowanie tabel, które wyraźnie łączą PII z identyfikatorami reklam. W pierwszym przykładzie powyżej oznaczałoby to nieuwzględnianie kolumny account_id w tabeli-01.

• Segregowanie i monitorowanie list kontroli dostępu dla użytkowników lub ról, które mają dostęp zarówno do kluczowych danych identyfikatora reklamy, jak i informacji osobistych.Ścisła kontrola i audyt możliwości jednoczesnego dostępu do obu źródeł (na przykład poprzez wykonanie złączenia między tabelami) zmniejsza ryzyko powiązania identyfikatora reklamy z informacjami osobistymi. Ogólnie rzecz biorąc, kontrolowanie dostępu oznacza wykonywanie następujących czynności:

  1. Utrzymuj listy kontroli dostępu (ACL) dla kluczowych danych identyfikatora reklamodawcy i PII w rozłączeniu, aby zminimalizować liczbę osób lub ról, które znajdują się na obu listach kontroli dostępu.
  2. Wdrożenie rejestrowania i audytu dostępu w celu wykrywania wyjątków od tej reguły i zarządzania nimi.

Więcej informacji na temat odpowiedzialnej pracy z identyfikatorami reklamowymi można znaleźć wAdvertisingIdClient dokumencie referencyjnym API.

Praca z identyfikatorami FID i GUID

Najprostszym rozwiązaniem do identyfikacji instancji aplikacji działającej na urządzeniu jest użycie identyfikatora instalacji Firebase (FID) i jest to zalecane rozwiązanie w większości przypadków użycia niezwiązanych z reklamami. Tylko instancja aplikacji, dla której został dostarczony może uzyskać dostęp do tego identyfikatora, i jest (stosunkowo) łatwo resetowalny, ponieważ utrzymuje się tylko tak długo, jak aplikacja jest zainstalowana.

W rezultacie, FID zapewniają lepsze właściwości prywatności w porównaniu do tonon-resettable, device-scoped hardware IDs. Aby uzyskać więcej informacji, zobaczfirebase.installationsAPI reference.

W przypadkach, gdy FID nie jest praktyczny, można również użyć niestandardowych globalnie unikalnych identyfikatorów (GUID), aby jednoznacznie zidentyfikować instancję aplikacji. Najprostszym sposobem na to jest wygenerowanie własnego identyfikatora GUID przy użyciu następującego kodu:

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

Ponieważ identyfikator jest globalnie unikalny, może być użyty do identyfikacji konkretnej instancji aplikacji. Aby uniknąć problemów związanych z łączeniem identyfikatora pomiędzy aplikacjami, przechowuj identyfikatory GUID w wewnętrznej pamięci masowej zamiast w zewnętrznej (współdzielonej) pamięci masowej. Aby uzyskać więcej informacji, zobacz stronę Przegląd przechowywania danych i plików.

Nie pracuj z adresami MAC

Adresy MAC są globalnie unikatowe, nie są resetowane przez użytkownika i przetrwają resety fabryczne. Z tych powodów, aby chronić prywatność użytkowników, w systemie Android w wersji 6 i nowszych, dostęp do adresów MAC jest ograniczony do aplikacji systemowych. Aplikacje firm trzecich nie mają do nich dostępu.

Dostępność adresów MAC zmienia się w systemie Android 11

W aplikacjach przeznaczonych dla systemu Android 11 i nowszych, randomizacja MAC dla sieci Passpoint odbywa się według profilu Passpoint, generując unikalny adres MAC na podstawie następujących pól:

• Fully-qualified domain name (FQDN)
• Realm
• Credential, na podstawie danych uwierzytelniających użytych w profilu Passpoint:
  • User credential: user name
  • Certificate credential: cert i cert type
  • SIM credential: EAP type and IMSI

Dodatkowo, aplikacje nieuprzywilejowane nie mają dostępu do adresu MAC urządzenia; widoczne są tylko interfejsy sieciowe z adresem IP. Ma to wpływ na metodygetifaddrs() iNetworkInterface.getHardwareAddress(), a także na wysyłanie wiadomości RTM_GETLINK Netlink.

Poniżej znajduje się lista sposobów, w jakie ta zmiana wpływa na aplikacje:

• NetworkInterface.getHardwareAddress() zwraca wartość null dla każdego interfejsu.
• Aplikacje nie mogą używać funkcji bind() na gniazdach NETLINK_ROUTE.
• Komenda ip nie zwraca informacji o interfejsach.
• Aplikacje nie mogą wysyłać RTM_GETLINK wiadomości.

Zauważ, że większość programistów powinna używać interfejsów API wyższego poziomuConnectivityManager zamiast interfejsów API niższego poziomu, takich jakNetworkInterface,getifaddrs() lub gniazda Netlink. Na przykład aplikacja, która potrzebuje aktualnych informacji o bieżących trasach, może uzyskać te informacje, nasłuchując zmian w sieci za pomocą ConnectivityManager.registerNetworkCallback() i wywołując powiązaną siećLinkProperties.getRoutes().

Charakterystyka identyfikatorów

System operacyjny Android oferuje wiele identyfikatorów o różnych charakterystykach zachowania.To, którego identyfikatora powinieneś użyć, zależy od tego, jak poniższe charakterystyki współpracują z Twoim przypadkiem użycia. Te cechy mają jednak również wpływ na prywatność, więc ważne jest, aby zrozumieć, jak te cechy współdziałają ze sobą.

Zakres

Zakres identyfikatora wyjaśnia, które systemy mogą uzyskać dostęp do identyfikatora. Zakres identyfikatora Androida generalnie występuje w trzech smakach:

• Pojedyncza aplikacja: Identyfikator jest wewnętrzny dla aplikacji i nie jest dostępny dla innych aplikacji.
• Grupa aplikacji: Identyfikator jest dostępny dla wcześniej zdefiniowanej grupy powiązanych aplikacji.
• Urządzenie: Identyfikator jest dostępny dla wszystkich aplikacji zainstalowanych na urządzeniu.

Im szerszy zakres przyznany identyfikatorowi, tym większe ryzyko, że zostanie on wykorzystany do celów śledzenia. I odwrotnie, jeżeli identyfikator może być dostępny tylko dla pojedynczej instancji aplikacji, nie może być wykorzystywany do śledzenia urządzenia w ramach transakcji w różnych aplikacjach.

Możliwość resetowania i trwałość

Możliwość resetowania i trwałość określają czas życia identyfikatora i wyjaśniają, w jaki sposób można go zresetować. Powszechne wyzwalacze resetowania obejmują: resetowanie w aplikacji, resetowanie przez Ustawienia systemowe, resetowanie przy uruchamianiu i resetowanie przy instalacji. Identyfikatory Androida mogą mieć różny czas życia, ale czas życia jest zwykle związany z tym, jak identyfikator jest resetowany:

• Tylko sesja: Nowy identyfikator jest używany za każdym razem, gdy użytkownik ponownie uruchamia aplikację.
• Install-reset: Nowy identyfikator jest używany za każdym razem, gdy użytkownik odinstalowuje i ponownie instaluje aplikację.
• FDR-reset: Nowy identyfikator jest używany za każdym razem, gdy użytkownik fabrycznie resetuje urządzenie.
• FDR-persistent: Identyfikator przetrwa reset fabryczny.

Możliwość resetowania daje użytkownikom możliwość tworzenia nowego identyfikatora, który jest odłączony od wszelkich istniejących informacji profilowych. Im dłużej i pewniej utrzymuje się identyfikator, np. taki, który utrzymuje się po przywróceniu ustawień fabrycznych, tym większe ryzyko, że użytkownik może zostać poddany długotrwałemu śledzeniu. Jeśli identyfikator jest resetowany po ponownej instalacji aplikacji, zmniejsza to trwałość i zapewnia środki do resetowania identyfikatora, nawet jeśli nie ma wyraźnej kontroli użytkownika do resetowania go z poziomu aplikacji lub ustawień systemowych.

Niepowtarzalność

Niepowtarzalność określa prawdopodobieństwo kolizji; to znaczy, że identyczne identyfikatory istnieją w powiązanym zakresie. Na najwyższym poziomie, globalnie unikalny identyfikator nigdy nie ma kolizji, nawet na innych urządzeniach lub aplikacjach.W przeciwnym razie, poziom unikalności zależy od entropii identyfikatora i źródła losowości użytego do jego utworzenia. Na przykład, szansa na kolizję jest znacznie wyższa dla losowych identyfikatorów posianych z datą kalendarzową instalacji (takich jak 2019-03-01) niż dla identyfikatorów posianych z Unixtimestamp instalacji (takich jak 1551414181).

Ogólnie, identyfikatory kont użytkowników mogą być uważane za unikalne. Oznacza to, że każda kombinacja urządzenie/konto ma unikalny identyfikator. Z drugiej strony, im mniej unikalny identyfikator jest w obrębie populacji, tym większa ochrona prywatności, ponieważ jest mniej przydatny do śledzenia indywidualnego użytkownika.

Integrity protection and non-repudiability

Można użyć identyfikatora, który jest trudny do sfałszowania lub odtworzenia, aby udowodnić, że skojarzone urządzenie lub konto ma pewne właściwości. Na przykład, można udowodnić, że urządzenie nie jest urządzeniem wirtualnym używanym przez spamera.Trudne do sfałszowania identyfikatory zapewniają również niezaprzeczalność. Jeśli urządzenie podpisuje wiadomość za pomocą tajnego klucza, trudno jest twierdzić, że wiadomość została wysłana przez urządzenie innej osoby. Nieodwracalność może być czymś, czego chce użytkownik, np. podczas uwierzytelniania płatności, lub może być niepożądaną właściwością, np. gdy wysyła wiadomość, której żałuje.

Wspólne przypadki użycia i odpowiedni identyfikator do użycia

Ta sekcja zapewnia alternatywy do używania identyfikatorów sprzętowych, takich jak IMEI. Używanie identyfikatorów sprzętowych jest odradzane, ponieważ użytkownik nie może ich zresetować i są one przypisane do urządzenia. W wielu przypadkach wystarczyłby identyfikator przypisany do aplikacji.

Śledzenie preferencji wypisanego użytkownika

W tym przypadku zapisujesz stan urządzenia po stronie serwera bez konta użytkownika.

Użyj: FID lub GUID

Dlaczego to zalecenie?

Przechowywanie informacji poprzez ponowne instalowanie nie jest zalecane, ponieważ użytkownicy mogą chcieć zresetować swoje preferencje poprzez ponowną instalację aplikacji.

Śledzenie wypisanych preferencji użytkownika między aplikacjami z tym samym kluczem podpisującym

W tym przypadku zapisujesz stan per-urządzenie po stronie serwera i przenosisz go między różnymi aplikacjami, które są podpisane tym samym kluczem na tym samym urządzeniu.

Użycie: SSAID

Dlaczego to zalecenie?

W Androidzie 8.0 (poziom API 26) i wyższych, SSAID zapewnia identyfikator, który jest wspólny dla aplikacji podpisanych tym samym kluczem podpisującym dewelopera. Pozwala to na współdzielenie stanu między tymi aplikacjami bez wymagania od użytkownika zalogowania się na konto.

Śledzenie zachowania wylogowanego użytkownika

W tym przypadku został utworzony profil użytkownika na podstawie jego zachowania w różnych aplikacjach/sesjach na tym samym urządzeniu.

Użycie: Advertising ID

Dlaczego to zalecenie?

Użycie Advertising ID jest obowiązkowe dla przypadków użycia reklamowego zgodnie z GooglePlay Developer ContentPolicy, ponieważ użytkownik może go zresetować.

Generate signed-out or anonymous user analytics

W tym przypadku mierzysz statystyki użytkowania i analitykę dla wylogowanych lub anonimowych użytkowników.

Użycie: FID lub identyfikator GUID, jeśli FID jest niewystarczający

Dlaczego to zalecenie?

Identyfikator FID lub GUID jest przypisany do aplikacji, która go tworzy, co zapobiega wykorzystaniu identyfikatora do śledzenia użytkowników w różnych aplikacjach. Jest on również łatwo resetowalny, ponieważ użytkownik może wyczyścić dane aplikacji lub ponownie zainstalować aplikację. Proces tworzenia identyfikatorów FID i GUID jest prosty:

• Pobieranie identyfikatora FID: Zobacz przewodnik po instalacji Firebase.

• Tworzenie identyfikatora GUID: Zaimplementuj logikę w swojej aplikacji, jak pokazano w poniższym fragmencie kodu:

  Kotlin

  val uniqueID: String = UUID.randomUUID().toString()

  Java

  String uniqueID = UUID.randomUUID().toString();

Uważaj, że jeśli powiedziałeś użytkownikowi, że dane, które zbierasz, sąanonimowe, powinieneś upewnić się, że nie łączysz identyfikatora zPII lub innymi identyfikatorami, które mogą być powiązane z PII.

Możesz również użyć Google Analytics for MobileApps, który oferuje rozwiązanie do analizy per-app.

Śledzenie konwersji użytkowników wylogowanych

W tym przypadku śledzisz konwersje, aby wykryć, czy Twoja strategia marketingowa jest skuteczna.

Użyj: Advertising ID

Why this recommendation?

This is an ads-related use case which might require an ID that is availableacross different apps, so using an Advertising ID is the most appropriatesolution.

Handle multiple installations across different devices

W tym przypadku musisz zidentyfikować właściwą instancję aplikacji, gdy jest ona sinstalowana na wielu urządzeniach dla tego samego użytkownika.

Use: FID lub GUID

Dlaczego to zalecenie?

An FID jest zaprojektowany specjalnie do tego celu; jego zakres jest ograniczony do aplikacji, więc nie może być używany do śledzenia użytkowników w różnych aplikacjach, i jest resetowany po ponownej instalacji aplikacji. W rzadkich przypadkach, gdy identyfikator FID jest niewystarczający, można również użyć identyfikatora GUID.

Połączenie funkcjonalności z subskrypcjami usług mobilnych

W tym przypadku należy powiązać funkcjonalność aplikacji z pewnymi subskrypcjami usług mobilnych na urządzeniu. Na przykład, możesz mieć wymóg, aby zweryfikować dostęp do niektórych funkcji premium aplikacji na podstawie subskrypcji usług mobilnych urządzenia za pośrednictwem SIM.

Użycie: Subscription IDAPI do identyfikacji kart SIM używanych na urządzeniu.

Identyfikator subskrypcji zapewnia wartość indeksu (począwszy od 1) do jednoznacznej identyfikacji zainstalowanych kart SIM (w tym fizycznych i elektronicznych) używanych na urządzeniu. Dzięki temu identyfikatorowi Twoja aplikacja może powiązać swoją funkcjonalność z różnymi informacjami o subskrypcji dla danej karty SIM. Wartość ta jest stabilna dla danej karty SIM, o ile urządzenie nie zostanie zresetowane fabrycznie. Jeśli identyfikator subskrypcji nie jest wystarczająco unikalny, zaleca się połączenie identyfikatora subskrypcji z identyfikatorem SSAID.

Dlaczego to zalecenie?

Niektóre aplikacje mogą obecnie używać ICCID do tego celu. Ponieważ ICC ID jest globalnie unikalny i nieresetowalny, dostęp został ograniczony do aplikacji z READ_PRIVILEGED_PHONE_STATEuprawnieniami od Androida 10. Począwszy od Androida 11, Google jeszcze bardziej ograniczyło dostęp do ICCID poprzez getIccId()API, niezależnie od docelowego poziomu API aplikacji. Dotknięte aplikacje powinny migrować do korzystania z identyfikatora subskrypcji zamiast tego.

Przeciwdziałanie oszustwom: Enforcing free content limits and detecting Sybil attacks

W tym przypadku chcesz ograniczyć liczbę darmowych treści, takich jak artykuły, które użytkownik może zobaczyć na urządzeniu.

Użyj: FID lub GUID. W systemie Android 8.0 (poziom API 26) i wyższych, SSAID jest również opcją, ponieważ jest przypisany do klucza podpisującego aplikację.

Dlaczego to zalecenie?

Użycie GUID lub FID zmusza użytkownika do ponownej instalacji aplikacji w celu obejścia limitów zawartości, co jest wystarczającym obciążeniem, aby odstraszyć większość ludzi. Jeśli to nie jest wystarczająca ochrona, Android zapewnia DRMAPI, który może być użyty do ograniczenia dostępu do treści, zawiera identyfikator per-APK, Widevine ID.

Funkcjonalność operatora

W tym przypadku, twoja aplikacja wchodzi w interakcję z telefonem urządzenia i funkcjonalnością tekstową przy użyciu konta operatora.

Użycie: IMEI, IMSI i Line1

Dlaczego to zalecenie?

Użycie identyfikatorów sprzętowych jest dopuszczalne, jeśli jest to wymagane dla funkcjonalności związanej z operatorem. Na przykład, można użyć tych identyfikatorów do przełączania między operatorami komórkowymi lub gniazdami SIM, lub do dostarczania wiadomości SMS przez IP (dla Line1) – konta użytkowników oparte na SIM. W przypadku nieuprzywilejowanych aplikacji zalecamy jednak korzystanie z logowania na konto w celu pobrania informacji o urządzeniu użytkownika po stronie serwera. Jednym z powodów jest to, że w Androidzie 6.0 (API level 23) i nowszych, te identyfikatory mogą być używane tylko poprzez zezwolenie runtime. Użytkownicy mogą wyłączyć to uprawnienie, więc Twoja aplikacja powinna łagodnie obsługiwać te wyjątki.

Wykrywanie nadużyć: Identyfikacja botów i ataków DDoS

W tym przypadku, próbujesz wykryć wiele fałszywych urządzeń atakujących twoje usługi typu backend.

Użycie: API SafetyNet

Dlaczego to zalecenie?

Identyfikator w izolacji niewiele wskazuje, że urządzenie jest prawdziwe. Można sprawdzić, czy żądanie pochodzi z prawdziwego urządzenia z systemem Android – w przeciwieństwie do emulatora lub innego kodu podszywającego się pod inne urządzenie – używając metody SafetyNet APIattest() do sprawdzania integralności urządzenia zgłaszającego żądanie. Bardziej szczegółowe informacje można znaleźć w dokumentacji API SafetyNet.

Detekcja oszustw i nadużyć: Detecting high-value stolen credentials

W tym przypadku próbujesz wykryć, czy pojedyncze urządzenie jest używane wielokrotnie z kradzionymi danymi uwierzytelniającymi o wysokiej wartości, np. do dokonywania oszukańczych płatności.

Użycie: Ze względu na swoją naturę, zapobieganie oszustwom wymaga zastrzeżonych sygnałów, które mogą się zmieniać w czasie i dlatego są poza zakresem tego dokumentu. Należy jednak pamiętać, że identyfikatory sprzętowe, takie jak IMEI i IMSI, można łatwo zmodyfikować w urządzeniach zdrutowanych lub emulowanych, dlatego nie są one wiarygodnymi wskaźnikami oszustwa.

.