Az egyedi azonosítók legjobb gyakorlatai

Ez a dokumentum útmutatást nyújt az alkalmazás megfelelő azonosítóinak kiválasztásához a felhasználási eset alapján.

Az Android engedélyek általános áttekintése az engedélyek áttekintésében található. Az Android-engedélyekkel való munkavégzés konkrét legjobb gyakorlataiért lásd: Alkalmazás-engedélyek legjobb gyakorlatai.

Az Android-azonosítókkal való munkavégzés legjobb gyakorlatai

Az Android-azonosítókkal való munkavégzés során kövesse az alábbi legjobb gyakorlatokat:

1. Kerülje a hardveres azonosítók használatát. A legtöbb felhasználási esetben elkerülhető a hardveres azonosítók, például az SSAID (Android ID) használata a szükséges funkciók korlátozása nélkül.

   Az Android 10 (API 29. szint) korlátozásokat vezet be a nem visszaállítható azonosítókra, amelyek IMEI és sorozatszámot is tartalmaznak. Az alkalmazásnak eszköz- vagy profiltulajdonos alkalmazásnak kell lennie, speciális szolgáltatói jogosultságokkal kell rendelkeznie, vagy rendelkeznie kell a READ_PRIVILEGED_PHONE_STATE kiváltságos jogosultsággal ahhoz, hogy hozzáférhessen ezekhez az azonosítókhoz.

2. Hirdetési azonosítót csak felhasználói profilok vagy hirdetések felhasználási eseteiben használjon. Reklámazonosító használatakor mindig tartsa tiszteletben a felhasználóknak a hirdetések nyomon követésére vonatkozó választásait. Gondoskodjon arról is, hogy az azonosító ne legyen összekapcsolható személyazonosításra alkalmas adatokkal (PII), és kerülje a hirdetési azonosító visszaállításának áthidalását.

3. A Firebase telepítési azonosítót (FID) vagy egy magán tárolt GUID-t használjon, amikor csak lehetséges minden más felhasználási esethez, kivéve a fizetési csalások megelőzését és a telefonálást. A nem hirdetési célú felhasználási esetek túlnyomó többségénél egy FID vagy GUID elegendő lehet.

4. A felhasználási esetnek megfelelő API-kat használjon a privátszféra kockázatának minimalizálása érdekében. Használja a DRM API-t a nagy értékű tartalmak védelméhez és a SafetyNet API-kat a visszaélések elleni védelemhez. A SafetyNet API-k a legegyszerűbb módja annak megállapítására, hogy egy eszköz valódi-e anélkül, hogy adatvédelmi kockázatot vállalna.

Az útmutató további részei ezeket a szabályokat az Android-alkalmazások fejlesztésével összefüggésben fejtik ki.

Munka a reklámazonosítókkal

A reklámazonosító egy felhasználó által visszaállítható azonosító, és alkalmas reklámhasználati esetekre. Van azonban néhány fontos szempont, amit szem előtt kell tartani, amikor ezt az ID-t használja:

Mindig tartsa tiszteletben a felhasználó szándékát a reklámazonosító visszaállításában.Ne hidalja át a felhasználó visszaállítását azzal, hogy egy másik azonosítót vagy ujjlenyomatot használ, hogy összekapcsolja egymást követő reklámazonosítókat a felhasználó beleegyezése nélkül. A Google Play Developer ContentPolicy a következőket mondja ki:

“…visszaállítás esetén egy új reklámazonosító nem kapcsolható össze egy korábbi reklámazonosítóval vagy egy korábbi reklámazonosítóból származó adatokkal a felhasználó kifejezett hozzájárulása nélkül.”

Mindig tartsa tiszteletben a kapcsolódó személyre szabott hirdetési jelzést. A reklámazonosítók konfigurálhatók, mivel a felhasználók korlátozhatják az azonosítóhoz kapcsolódó nyomon követés mennyiségét. Mindig használja a AdvertisingIdClient.Info.isLimitAdTrackingEnabled()módszert annak biztosítására, hogy ne kerülje meg a felhasználók kívánságait. A GooglePlay Developer ContentPolicy a következőket mondja ki:

“…be kell tartania a felhasználó “Opt out of interest-based advertising” vagy “Opt out of Ads Personalization” beállítását. Ha a felhasználó engedélyezte ezt a beállítást,nem használhatja a hirdetési azonosítót felhasználói profilok létrehozására hirdetési célokra vagy a felhasználók személyre szabott hirdetésekkel történő megcélzására.A megengedett tevékenységek közé tartozik a kontextuális hirdetés, a gyakoriságkorlátozás, a konverziókövetés, a jelentéstétel, a biztonság és a csalás felderítése.”

Tudatában kell lennie az Ön által használt SDK-khoz kapcsolódó adatvédelmi vagy biztonsági irányelveknek, amelyek a hirdetési azonosító használatával kapcsolatosak.Például, ha a Google Analytics SDK-ból a truet aenableAdvertisingIdCollection()módszerbe adja át, győződjön meg róla, hogy áttanulmányozta és betartja az összes vonatkozó Analytics SDK-irányelvet.

Azt is vegye figyelembe, hogy a Google Play Developer ContentPolicy előírja, hogy a hirdetési azonosító “nem kapcsolható személyazonosításra alkalmas információkhoz, és nem társítható semmilyen állandó eszközazonosítóhoz (például: SSAID, MAC-cím, IMEI stb,).”

Tegyük fel, hogy például a következő oszlopokkal rendelkező adattáblák feltöltéséhez szeretne információt gyűjteni:

Ebben a példában, a ad_id oszlop mindkét táblázatban a account_idoszlopon keresztül összekapcsolható a PII-vel, ami a Google Play DeveloperContent Policy megsértését jelentené, ha nem kapna kifejezett engedélyt a felhasználóktól.

Ne feledje, hogy a Hirdető azonosítója és a PII közötti kapcsolatok nem mindig ilyen egyértelműek. Lehetséges, hogy a “kvázi-azonosítók” mind a PII, mind a hirdetési azonosító kulcsos táblákban megjelennek, ami szintén problémákat okozhat. Tegyük fel például, hogy aTABLE-01 és TABLE-02 táblákat a következőképpen változtatjuk meg:

Ez esetben, kellően ritka kattintási események esetén még mindig lehetséges a TABLE-01 hirdetési azonosító és a TABLE-02-ben szereplő PII összekapcsolása az esemény időbélyegzője és az eszközmodell segítségével.

Noha gyakran nehéz garantálni, hogy egy adathalmazban nem léteznek ilyen kvázi-azonosítók, a legnyilvánvalóbb csatlakozási kockázatokat megelőzhetjük az egyedi adatok általánosításával, ahol lehetséges. Az előző példában ez az időbélyeg pontosságának csökkentését jelentené, hogy minden időbélyegnél több azonos modellel rendelkező eszköz jelenjen meg.

A többi megoldás a következő:

• Nem tervezünk olyan táblázatokat, amelyek kifejezetten összekapcsolják a PII-t a hirdetési azonosítókkal. A fenti első példában ez azt jelentené, hogy a account_id oszlop nem szerepel a TABLE-01-ben.

• A hozzáférési vezérlési listák elkülönítése és ellenőrzése azon felhasználók vagy szerepkörök esetében, akik mind a hirdetési azonosító kulcsadataihoz, mind a PII-hez hozzáférnek.A két forráshoz való egyidejű hozzáférés képességének szigorú ellenőrzésével és auditálásával (például a táblák közötti csatlakozással) csökkenti a hirdetési azonosító és a PII közötti kapcsolat kockázatát. Általánosságban elmondható, hogy a hozzáférés ellenőrzése a következőket jelenti:

  1. A Hirdetői azonosító kulcsadatok és a PII hozzáférési vezérlési listáit (ACL-ek) egyesítse, hogy minimalizálja azon személyek vagy szerepkörök számát, akik mindkét ACL-ben szerepelnek.
  2. A hozzáférési naplózás és ellenőrzés megvalósítása az e szabály alóli kivételek észlelése és kezelése érdekében.

A reklámazonosítókkal való felelősségteljes munkára vonatkozó további információkért lásd azAdvertisingIdClient API-referenciát.

Munka FID-kkel és GUID-kkel

A legegyszerűbb megoldás egy eszközön futó alkalmazáspéldány azonosítására a Firebase telepítési azonosító (FID) használata, és ez az ajánlott megoldás a nem hirdetési célú felhasználási esetek többségében. Csak az az alkalmazáspéldány férhet hozzá ehhez az azonosítóhoz, amelyikhez azt létrehozták, és (viszonylag) könnyen visszaállítható, mivel csak addig marad fenn, amíg az alkalmazás telepítve van.

Az FID-k ennek eredményeképpen jobb adatvédelmi tulajdonságokat biztosítanak a nem visszaállítható, eszközre szabott hardverazonosítókhoz képest. További információért lásd afirebase.installationsAPI-referenciát.

Azokban az esetekben, amikor az FID nem praktikus, egyéni, globálisan egyedi azonosítókat (GUID) is használhat egy alkalmazáspéldány egyedi azonosítására. Ennek legegyszerűbb módja a saját GUID generálása a következő kód segítségével:

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

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

Mivel az azonosító globálisan egyedi, felhasználható egy adottapp példány azonosítására. Az azonosító alkalmazások közötti összekapcsolásával kapcsolatos problémák elkerülése érdekében a GUID-ket külső (megosztott) tároló helyett belső tárolóban tárolja. További információkért lásd az Adat- és fájltárolásáttekintő oldalt.

Ne dolgozzon MAC-címekkel

A MAC-címek globálisan egyediek, nem állíthatók vissza a felhasználó által, és túlélik a gyári visszaállítást. Ezen okok miatt, a felhasználói adatvédelem érdekében a 6-os és magasabb Android-verziókon a MAC-címekhez való hozzáférés a rendszeralkalmazásokra korlátozódik. Harmadik féltől származó alkalmazások nem férhetnek hozzá.

A MAC-címek elérhetősége megváltozik az Android 11-ben

Az Android 11 és újabb Androidot célzó alkalmazásokban a MAC véletlenszerűsége a Passpointhálózatok esetében Passpoint-profilonként történik, egyedi MAC-címet generálva a következő mezők alapján:

• Teljesen minősített tartománynév (FQDN)
• Realm
• Credential, a Passpoint profilban használt credential alapján:
  • User credential: felhasználói név
  • Certificate credential: cert and cert type
  • SIM credential:

Ezenkívül a nem privilegizált alkalmazások nem férhetnek hozzá az eszköz MAC-címéhez; csak az IP-címmel rendelkező hálózati interfészek láthatók. Ez hatással van agetifaddrs()ésNetworkInterface.getHardwareAddress()módszerekre, valamint a RTM_GETLINK Netlink üzenetek küldésére.

A következőkben felsoroljuk, hogy az alkalmazásokat milyen módon érinti ez a változás:

• NetworkInterface.getHardwareAddress() minden interfész esetében nullát ad vissza.
• Az alkalmazások nem használhatják a bind() funkciót NETLINK_ROUTE socketeken.
• A ip parancs nem ad vissza információt az interfészekről.
• Az alkalmazások nem tudnak RTM_GETLINK üzeneteket küldeni.

Megjegyezzük, hogy a legtöbb fejlesztőnek inkább a magasabb szintű ConnectivityManager API-kat kell használnia, mint az alacsonyabb szintű API-kat, mint a NetworkInterface,getifaddrs() vagy a Netlink sockets. Például egy olyan alkalmazás, amelynek naprakész információra van szüksége az aktuális útvonalakról, ezt az információt úgy kaphatja meg, hogy a ConnectivityManager.registerNetworkCallback() segítségével figyel a hálózati változásokra, és meghívja a hálózathoz tartozóLinkProperties.getRoutes()-t.

Identifier characteristics

Az Android OS számos azonosítót kínál különböző viselkedési jellemzőkkel.Hogy melyik azonosítót érdemes használni, attól függ, hogy a következő jellemzők hogyan működnek az Ön felhasználási esetével. Ezek a jellemzők azonban adatvédelmi következményekkel is járnak, ezért fontos megérteni, hogy ezek a jellemzők hogyan hatnak egymásra.

Scope

Az azonosító scope megmagyarázza, hogy mely rendszerek férhetnek hozzá az azonosítóhoz. Az Androidazonosító hatókörének általában három változata van:

• Egyetlen alkalmazás:
• Alkalmazások csoportja: Az azonosító elérhető a kapcsolódó alkalmazások egy előre meghatározott csoportja számára.
• Eszköz:

Minél szélesebb körű egy azonosító, annál nagyobb a kockázata annak, hogy nyomon követési célokra használják. Ezzel szemben, ha egy azonosítóhoz csak egyetlen alkalmazáspéldány férhet hozzá, az nem használható az eszköz nyomon követésére a különböző alkalmazások tranzakciói között.

Megújíthatóság és állandóság

A megújíthatóság és állandóság meghatározza az azonosító élettartamát, és megmagyarázza, hogyan lehet azt visszaállítani. Gyakori visszaállítási kiváltó okok: alkalmazáson belüli visszaállítás, visszaállítás a Rendszerbeállításokon keresztül, visszaállítás indításkor és visszaállítás telepítéskor. Az Android-azonosítók különböző élettartamúak lehetnek, de az élettartam általában az azonosító visszaállításának módjához kapcsolódik:

• Csak munkamenet:
• Telepítés-visszaállítás:
• FDR-reset:
• FDR-persistent: Az azonosító túléli a gyári visszaállítást.

A visszaállíthatóság lehetővé teszi a felhasználók számára, hogy új azonosítót hozzanak létre, amely nem kapcsolódik semmilyen meglévő profilinformációhoz. Minél hosszabb ideig és megbízhatóbban fennmarad egy azonosító, például egy olyan, amely a gyári visszaállítások után is megmarad, annál nagyobb a kockázata annak, hogy a felhasználó hosszú távú nyomon követésnek van kitéve. Ha az azonosító az alkalmazás újratelepítésekor visszaállításra kerül, ez csökkenti a perzisztenciát, és lehetőséget biztosít az azonosító visszaállítására, még akkor is, ha nincs kifejezett felhasználói vezérlés az alkalmazáson vagy a rendszerbeállításokon belül.

Egyediség

Az egyediség meghatározza az ütközések valószínűségét, vagyis azt, hogy azonos azonosítók léteznek a kapcsolódó hatókörben. A legmagasabb szinten egy globálisan egyedi azonosító soha nem ütközik, még más eszközökön vagy alkalmazásokban sem.Egyébként az egyediség szintje az azonosító entrópiájától és a létrehozásához használt véletlenszerűség forrásától függ. Például az ütközés esélye sokkal nagyobb a véletlenszerű azonosítók esetében, amelyeket a telepítés naptári dátumával (például 2019-03-01), mint az Unixtimestamp telepítési dátumával (például 1551414181) beültetett azonosítók esetében.

A felhasználói fiókok azonosítói általában egyedinek tekinthetők. Vagyis minden eszköz/fiók kombinációnak egyedi azonosítója van. Másrészt, minél kevésbé egyedi egy azonosító egy populáción belül, annál nagyobb az adatvédelmi védelem, mivel kevésbé használható az egyes felhasználók nyomon követésére.

Integrity protection and non-repudientability

Egy olyan azonosítót használhat, amelyet nehéz hamisítani vagy visszajátszani annak bizonyítására, hogy a hozzárendelt eszköz vagy fiók bizonyos tulajdonságokkal rendelkezik. Például bizonyíthatja, hogy az eszköz nem egy spammer által használt virtuális eszköz.A nehezen hamisítható azonosítók a letagadhatatlanságot is biztosítják. Ha az eszközök egy üzenetet titkos kulccsal írnak alá, nehéz azt állítani, hogy valaki más eszköze küldte az üzenetet. A letagadhatatlanság lehet olyan, amit a felhasználó szeretne, például egy fizetés hitelesítésekor, vagy lehet nemkívánatos tulajdonság, például amikor olyan üzenetet küld, amit megbánt.

Gyakori felhasználási esetek és a megfelelő azonosító használata

Ez a szakasz a hardverazonosítók, például az IMEI használatának alternatíváit tartalmazza. A hardveres azonosítók használata azért nem javasolt, mert a felhasználó nem tudja visszaállítani őket, és az eszközhöz vannak rendelve. Sok esetben egy alkalmazáshoz tartozó azonosító is elegendő lenne.

A kijelentkezett felhasználó beállításainak követése

Ebben az esetben a szerveroldalon készülékenkénti állapotot mentünk, felhasználói fiók nélkül.

Használat: FID vagy GUID

Miért ez az ajánlás?

Az információk újratelepítésen keresztül történő megőrzése nem ajánlott, mivel a felhasználók az alkalmazás újratelepítésével esetleg vissza akarják állítani a beállításaikat.

Követi a lejelentett felhasználói beállításokat az azonos aláírási kulccsal rendelkező alkalmazások között

Ez esetben a szerveroldalon tárolja az eszközonkénti állapotot, és átviszi azt a különböző alkalmazások között, amelyek ugyanazzal a kulccsal vannak aláírva ugyanazon az eszközön.

Használat: SSAID

Miért ez az ajánlás?

Az Android 8.0 (API 26. szint) és újabb verziókban az SSAID egy olyan azonosítót biztosít, amely közös az azonos fejlesztői aláíró kulccsal aláírt alkalmazások között. Lehetővé teszi az állapot megosztását ezen alkalmazások között anélkül, hogy a felhasználónak be kellene jelentkeznie egy fiókba.

A kijelentkezett felhasználó viselkedésének nyomon követése

Ebben az esetben egy felhasználó profilját hozta létre a felhasználó viselkedése alapján ugyanazon az eszközön különböző alkalmazások/ülések között.

Használja:

Miért ez az ajánlás?

A hirdetési azonosító használata a GooglePlay Developer ContentPolicy szerint kötelező a hirdetési felhasználási esetekben, mivel a felhasználó visszaállíthatja azt.

Generate signed-out or anonymous user analytics

Ebben az esetben a lejelentkezett vagy anonim felhasználók használati statisztikáit és elemzési adatait méri.

Use: FID, vagy GUID, ha az FID nem elegendő

Miért ez az ajánlás?

Egy FID vagy GUID az azt létrehozó alkalmazáshoz van rendelve, ami megakadályozza, hogy az azonosítót a felhasználók alkalmazások közötti nyomon követésére használják. Emellett könnyen visszaállítható, mivel a felhasználó törölheti az alkalmazás adatait vagy újratelepítheti az alkalmazást. A FID-ek és GUID-ek létrehozásának folyamata egyszerű:

• FID visszakeresése: Lásd a Firebase telepítési útmutatóját.

• GUID létrehozása: Implementáljon logikát az alkalmazásában, ahogy az a következő kódrészletben látható:

  Kotlin

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

  Java

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

Figyeljen arra, hogy ha azt mondta a felhasználónak, hogy a gyűjtött adatok anonimak, akkor biztosítsa, hogy az azonosítót nem kapcsolja összePII-vel vagy más azonosítókkal, amelyek PII-hez kapcsolódhatnak.

A Google Analytics for MobileApps-t is használhatja, amely megoldást kínál az alkalmazásonkénti analitikára.

A kijelentkezett felhasználók konverzióinak nyomon követése

Ez esetben a konverziókat követi, hogy felismerje, sikeres-e a marketingstratégiája.

Használja:

Miért ez az ajánlás?

Ez egy hirdetésekkel kapcsolatos felhasználási eset, amelyhez olyan azonosítóra lehet szükség, amely különböző alkalmazásokon keresztül elérhető, ezért a hirdetési azonosító használata a legmegfelelőbb megoldás.

Más eszközön történő többszörös telepítések kezelése

Ebben az esetben az alkalmazás megfelelő példányát kell azonosítania, amikor az ugyanazon felhasználó több eszközön is telepítve van.

Használat: FID vagy GUID

Miért ez az ajánlás?

A FID-t kifejezetten erre a célra tervezték; hatókörét az alkalmazásra korlátozzák, így nem használható a felhasználók különböző alkalmazások közötti nyomon követésére, és az alkalmazás újratelepítésekor visszaállítják. Azokban a ritka esetekben, amikor az FID nem elegendő, használhat GUID-t is.

Funkciók hozzárendelése mobilszolgáltatási előfizetésekhez

Ebben az esetben az alkalmazás funkcióit kell hozzárendelni bizonyos mobilszolgáltatási előfizetésekhez az eszközön. Például előfordulhat, hogy a SIM-en keresztül az eszköz mobilszolgáltatási előfizetésein alapuló, bizonyos prémium alkalmazásfunkciókhoz való hozzáférésre van szükség.

Use: Subscription IDAPI toidentify SIMs that are used on the device.

The Subscription ID provides an index value (starting at 1) for uniqueidentification installed SIMs (including physical and electronic) used on thedevice. Ezen az azonosítón keresztül az alkalmazás társíthatja funkcióit az adott SIM-hez tartozó különböző előfizetési információkhoz. Ez az érték egy adott SIM esetében állandó, kivéve, ha a készüléket gyári alaphelyzetbe állítják. Előfordulhatnak azonban olyan esetek, amikor ugyanannak a SIM-nek különböző készülékeken különböző előfizetési azonosítója van, vagy különböző SIM-ek különböző készülékeken ugyanazzal az azonosítóval rendelkeznek.Ha az előfizetési azonosító nem eléggé egyedi, ajánlott az előfizetési azonosítót az SSAID-vel összekapcsolni.

Miért ez az ajánlás?

Egyes alkalmazások jelenleg az ICCID-t használják erre a célra. Mivel az ICC ID globálisan egyedi és nem visszaállítható, a hozzáférés az Android 10 óta a READ_PRIVILEGED_PHONE_STATEengedéllyel rendelkező alkalmazásokra korlátozódik. Az Android 11-től kezdve a Google tovább korlátozta az ICCID-hez való hozzáférést a getIccId()API-n keresztül, függetlenül az alkalmazás cél API-szintjétől. Az érintett alkalmazásoknak át kell állniuk az előfizetési azonosító használatára.

Csalás elleni védelem: Az ingyenes tartalmak korlátozásának kikényszerítése és a Sybil-támadások felderítése

Ebben az esetben korlátozni szeretné az ingyenes tartalmak, például cikkek számát, amelyeket egy felhasználó láthat egy eszközön.

Használat: FID vagy GUID. Android 8.0 (26-os API-szint) és magasabb szinteken az SSAID is egy lehetőség, mivel az alkalmazás aláíró kulcsára van korlátozva.

Miért ez az ajánlás?

A GUID vagy FID használata arra kényszeríti a felhasználót, hogy újratelepítse az alkalmazást a tartalomkorlátozás megkerülése érdekében, ami elegendő teher ahhoz, hogy a legtöbb embert elriassza. Ha ez nem elegendő védelem, az Android biztosít egy DRMAPI-t, amely a tartalomhoz való hozzáférés korlátozására használható, tartalmaz egy APK-nkénti azonosítót, a Widevine ID-t.

Hordozói funkcionalitás

Ebben az esetben az alkalmazás interakcióba lép a készülék telefon- és szövegfunkcionalitásával egy hordozói fiók segítségével.

Használat: IMEI, IMSI és Line1

Miért ez az ajánlás?

A hardverazonosítók felhasználása elfogadható, ha az a szolgáltatóval kapcsolatos funkciókhoz szükséges. Például ezeket az azonosítókat használhatja a mobilszolgáltatók vagy SIM-helyek közötti váltáshoz, vagy SMS-üzenetek IP-n keresztüli kézbesítéséhez (Line1 esetén) – SIM-alapú felhasználói fiókok. A nem privilegizált alkalmazások esetében azonban a felhasználói eszközinformációk szerveroldali lekérdezéséhez fiókbejelentkezést javasolunk. Ennek egyik oka, hogy az Android 6.0-ban (23. API-szint) és afelett ezek az azonosítók csak futásidejű engedélyen keresztül használhatók. A felhasználók kikapcsolhatják ezt az engedélyt, ezért az alkalmazásnak ezeket a kivételeket kíméletesen kell kezelnie.

Hibafeltárás:

Használat: A SafetyNet API

Miért ez az ajánlás?

Egy azonosító önmagában kevéssé jelzi, hogy egy eszköz valódi. A SafetyNet APIattest()módszerével ellenőrizheti, hogy egy kérés valódi Android-eszközről származik-e – szemben egy másik eszközt meghamisító emulátorral vagy más kóddal -, a SafetyNet APIattest()módszerével a kérést küldő eszköz integritásának ellenőrzésére. Részletesebb információkért lásd a SafetyNet API dokumentációját.

Csalás és visszaélés észlelése: Nagy értékű lopott hitelesítő adatok észlelése

Ez esetben azt próbálja észlelni, ha egyetlen eszközt többször is használnak nagy értékű, lopott hitelesítő adatokkal, például csalárd fizetések lebonyolítására.

Használat: A csalásmegelőzés természeténél fogva olyan saját jeleket igényel, amelyek idővel változhatnak, és ezért nem tartoznak e dokumentum hatálya alá. Megjegyzendő azonban, hogy a hardveres azonosítók, mint például az IMEI és az IMSI, könnyen módosíthatók a gyökeres vagy emulált eszközökön, így nem megbízható csalásjelzők.