Tento dokument poskytuje návod pro výběr vhodných identifikátorů pro vaši aplikaci na základě případu použití.
Obecný pohled na oprávnění systému Android naleznete v části Přehled oprávnění. Konkrétní osvědčené postupy pro práci s oprávněními systému Android naleznete v části Osvědčené postupy pro práci s oprávněními aplikací.
- Osvědčené postupy pro práci s identifikátory systému Android
- Práce s reklamními ID
- Práce s FID a GUID
- Kotlin
- Java
- Nepracujte s adresami MAC
- V systému Android 11 se mění dostupnost adres MAC
- Vlastnosti identifikátoru
- Obsah
- Resetovatelnost a perzistence
- Uniqueness
- Ochrana integrity a nepopiratelnost
- Obvyklé případy použití a vhodný identifikátor k použití
- Sledovat předvolby odhlášeného uživatele
- Sledovat odhlašované uživatelské předvolby mezi aplikacemi se stejným podpisovým klíčem
- Sledovat chování odhlašovaného uživatele
- Generování analytiky odhlášených nebo anonymních uživatelů
- Kotlin
- Java
- Sledování konverzí přihlášených uživatelů
- Zpracování více instalací na různých zařízeních
- Připojení funkcí k odběru mobilních služeb
- Anti-fraud:
- Funkce operátora
- Detekce zneužití:
- Detekce podvodů a zneužití: Detekce ukradených pověření vysoké hodnoty
Osvědčené postupy pro práci s identifikátory systému Android
Při práci s identifikátory systému Android dodržujte tyto osvědčené postupy:
-
Vyhněte se používání hardwarových identifikátorů. Ve většině případů použití se můžete vyhnout použití hardwarových identifikátorů, jako je SSAID (Android ID), aniž byste omezilipožadovanou funkčnost.
Android 10 (úroveň API 29) přidává omezení pro neobnovitelné identifikátory,které zahrnují IMEI i sériové číslo. Vaše aplikace musí být vlastníkem zařízení nebo profilu,musí mít speciální oprávnění operátora nebo mít privilegované oprávnění
READ_PRIVILEGED_PHONE_STATE
, aby mohla k těmto identifikátorům přistupovat. -
Pro případy použití profilování uživatelů nebo reklam používejte pouze reklamní ID. Při použití Advertising ID vždy respektujte volby uživatelů týkající se sledování reklam. Zajistěte také, aby identifikátor nemohl být spojen s osobně identifikovatelnými informacemi (PII), a vyhněte se překlenovacímu resetování Advertising ID.
-
Ve všech ostatních případech použití, s výjimkou prevence platebních podvodů a telefonie, používejte Firebase installation ID (FID) nebo soukromě uložený GUID, kdykoli je to možné. Pro naprostou většinu případů použití, které se netýkají reklam, by měl stačit identifikátor FID nebo GUID.
-
V zájmu minimalizace rizika ohrožení soukromí používejte rozhraní API, která jsou vhodná pro daný případ použití. Pro ochranu vysoce hodnotného obsahu použijte rozhraní DRM API a pro ochranu proti zneužití rozhraní API SafetyNet. Rozhraní API SafetyNet je nejjednodušší způsob, jak zjistit, zda je zařízení pravé, aniž by došlo k ohrožení soukromí.
Zbývající části této příručky rozvádějí tato pravidla v kontextu vývoje aplikací pro Android.
Práce s reklamními ID
Reklamní ID je identifikátor nastavitelný uživatelem a je vhodný pro případy použití reklam. Při jeho používání je však třeba mít na paměti několik klíčových bodů:
Vždy respektujte záměr uživatele při resetování reklamního ID. nepřeklenujte resetování uživatelem použitím jiného identifikátoru nebo otisku prstu k propojení následných reklamních ID bez souhlasu uživatele. Zásady obsahu pro vývojáře Google Play uvádějí následující:
„…v případě resetování nesmí být nový reklamní identifikátor spojen s předchozím reklamním identifikátorem nebo údaji odvozenými z předchozího reklamního identifikátoru bez výslovného souhlasu uživatele.“
Vždy respektujte související příznak Personalizované reklamy. Reklamní identifikátory jsoukonfigurovatelné v tom smyslu, že uživatelé mohou omezit množství sledování spojeného sID. Vždy používejte AdvertisingIdClient.Info.isLimitAdTrackingEnabled()
metodu, abyste se ujistili, že neobcházíte přání uživatelů. Zásady obsahu pro vývojáře GooglePlay uvádějí následující:
„…musíte dodržovat nastavení uživatele „Odhlásit se od reklamy založené na zájmech“ nebo „Odhlásit se od personalizace reklam“. Pokud uživatel toto nastavení povolil,nesmíte reklamní identifikátor používat k vytváření uživatelských profilů pro účelyreklamy nebo k cílení na uživatele pomocí personalizované reklamy. povolené činnosti zahrnují kontextovou reklamu, omezování frekvence, sledování konverzí, podávání zpráv a zabezpečení a odhalování podvodů.“
Vezměte na vědomí všechny zásady ochrany osobních údajů nebo zabezpečení spojené s SDK, které používáte a které se týkají používání reklamního identifikátoru.Pokud například předáváte true
doenableAdvertisingIdCollection()
metody z Google Analytics SDK, ujistěte se, že jste zkontrolovali a dodržovali všechny použitelné zásady Analytics SDK.
Také si uvědomte, že zásady obsahu pro vývojáře Google Play vyžadují, aby Advertising ID „nebylo spojeno s informacemi umožňujícími osobní identifikaci nebo spojeno s jakýmkoli trvalým identifikátorem zařízení (například:SSAID, MAC adresa, IMEI atd…“,).“
Předpokládejme, že chcete shromažďovat informace pro naplnění databázových tabulek s následujícími sloupci:
TABULKA-01 | |||
timestamp |
ad_id |
account_id |
clickid |
TABULKA-02 | |||
account_id |
name |
dob |
country |
V tomto příkladu, by mohl být sloupec ad_id
připojen k PII prostřednictvím sloupce account_id
v obou tabulkách, což by bylo porušením zásad pro vývojáře obsahu Google Play, pokud byste nezískali výslovné povolení od svých uživatelů.
Mějte na paměti, že spojení mezi ID inzerenta a PII není vždy takto explicitní. Je možné mít „kvaziidentifikátory“, které se objevují v tabulkách s klíčem PII iAd ID, což také způsobuje problémy. Předpokládejme například, že tabulkyTABLE-01 a TABLE-02 změníme takto:
TABULKA-01 | ||||
timestamp |
ad_id |
clickid |
dev_model |
|
TABULKA-.02 | ||||
timestamp |
demo |
account_id |
dev_model |
name |
V tomto případě, s dostatečně vzácnými událostmi kliknutí je stále možné spojit ID inzerenta TABLE-01 a PII obsažené v TABLE-02 pomocí časového razítka události a modelu zařízení.
Ačkoli je často obtížné zaručit, že v datovém souboru neexistují žádné takové kvaziidentifikátory, můžete zabránit nejzjevnějším rizikům spojování zobecněním jedinečných údajů, kde je to možné. V předchozím příkladu by to znamenalo snížitpřesnost časového razítka tak, aby se pro každé časové razítko objevilo více zařízení se stejným modelem.
Další řešení zahrnují následující:
-
Není třeba navrhovat tabulky, které explicitně spojují PII s Advertising ID. V prvním výše uvedeném příkladu by to znamenalo nezařazovat sloupec
account_id
do TABULKY-01. -
Segregace a monitorování seznamů řízení přístupu pro uživatele nebo role, které mají přístup jak k údajům s klíčem Advertising ID, tak k PII. přísnou kontrolou a auditem možnosti přístupu k oběma zdrojům současně (například provedením spojení mezi tabulkami) snížíte riziko spojení mezi Advertising ID a PII. Obecně řečeno, řízení přístupu znamená následující:
- Udržujte seznamy řízení přístupu (ACL) pro klíčová data Advertiser ID a PIIspojené, abyste minimalizovali počet osob nebo rolí, které jsou v obouACL.
- Zavedete protokolování a auditování přístupu, abyste zjistili a spravovali všechny výjimky z tohoto pravidla.
Další informace o zodpovědné práci s reklamními ID naleznete vAdvertisingIdClient
referenci API.
Práce s FID a GUID
Nejjednodušším řešením identifikace instance aplikace běžící na zařízení je použití instalačního ID Firebase (FID), a to je doporučenéřešení ve většině případů použití, které se netýkají reklam. K tomuto identifikátoru má přístup pouze instance aplikace, pro kterou byl vytvořen, a je (relativně) snadno resetovatelný, protože přetrvává pouze po dobu, kdy je aplikace nainstalována.
V důsledku toho poskytuje identifikátor FID lepší vlastnosti soukromí ve srovnání s hardwarovými identifikátory, které lze resetovat. Další informace naleznete v referencifirebase.installations
API.
V případech, kdy FID není praktické, můžete k jednoznačné identifikaci instance aplikace použít také vlastní globálně unikátní ID (GUID). Nejjednodušší způsob je vygenerovat vlastní GUID pomocí následujícího kódu:
Kotlin
var uniqueID = UUID.randomUUID().toString()
Java
String uniqueID = UUID.randomUUID().toString();
Protože je identifikátor globálně jedinečný, lze jej použít k identifikaci konkrétní instance aplikace. Abyste se vyhnuli obavám spojeným s propojením identifikátoru napříč aplikacemi, ukládejte GUID do interního úložiště místo do externího (sdíleného) úložiště. Dalšíinformace naleznete na stránce Přehled datových a souborových úložišť.
Nepracujte s adresami MAC
Adresy MAC jsou globálně jedinečné, nejsou uživatelsky nastavitelné a přežijí tovární reset. Z těchto důvodů je z důvodu ochrany soukromí uživatelů v systému Android verze 6 a vyšší přístup k adresám MAC omezen na systémové aplikace. Aplikace třetích stran k nim nemají přístup.
V systému Android 11 se mění dostupnost adres MAC
V aplikacích určených pro systém Android 11 a vyšší je náhodná volba MAC pro sítě Passpoint podle profilu Passpoint, který generuje jedinečnou adresu MAC na základě následujících polí:
- Plně kvalifikovaný název domény (FQDN)
- Real
- Potvrzení, založené na pověření použitém v profilu Passpoint:
- Potvrzení uživatele: jméno uživatele
- Potvrzení certifikátu: certifikát a typ certifikátu
- Potvrzení SIM: Kromě toho neprivilegované aplikace nemají přístup k MAC adrese zařízení; viditelná jsou pouze síťová rozhraní s IP adresou. To má vliv na metody
getifaddrs()
aNetworkInterface.getHardwareAddress()
a také na odesílání zprávRTM_GETLINK
Netlink.Následuje seznam způsobů, kterými jsou aplikace touto změnou ovlivněny:
-
NetworkInterface.getHardwareAddress()
vrací nulu pro každé rozhraní. - Aplikace nemohou používat funkci
bind()
naNETLINK_ROUTE
soketech. - Příkaz
ip
nevrací informace o rozhraních. - Aplikace nemohou odesílat zprávy
RTM_GETLINK
.
Poznamenejme, že většina vývojářů by měla používat spíše API vyšší úrovně
ConnectivityManager
než API nižší úrovně jakoNetworkInterface
,getifaddrs()
nebo Netlink sockety. Například aplikace, která potřebuje aktuální informace o aktuálních trasách, může tyto informace získat nasloucháním změnám v síti pomocíConnectivityManager.registerNetworkCallback()
a voláním přidruženého síťového rozhraníLinkProperties.getRoutes()
.Vlastnosti identifikátoru
Osystém Android nabízí řadu identifikátorů s různými charakteristikami chování. to, který identifikátor byste měli použít, závisí na tom, jak následující charakteristiky fungují s vaším případem použití. Tyto charakteristiky však s sebou nesou také důsledky pro soukromí, proto je důležité pochopit, jak spolu tyto charakteristiky vzájemně souvisejí.
Obsah
Obsah identifikátoru vysvětluje, které systémy mohou k identifikátoru přistupovat. Rozsah identifikátoru systému Android se obecně vyskytuje ve třech variantách:
- Jednotlivá aplikace:
- Skupina aplikací: Identifikátor je přístupný předem definované skupině souvisejících aplikací.
- Zařízení:
Čím širší rozsah je identifikátoru přidělen, tím větší je riziko, že bude použit pro účely sledování. Naopak, pokud k identifikátoru může přistupovat pouze jedna instance aplikace, nelze jej použít ke sledování zařízení napříč transakcemi v různých aplikacích.
Resetovatelnost a perzistence
Resetovatelnost a perzistence definují životnost identifikátoru a vysvětlují, jak jej lze resetovat. Mezi běžné spouštěče resetování patří: resetování v aplikaci, resetování prostřednictvím Nastavení systému, resetování při spuštění a resetování při instalaci. Identifikátory Androidu mohou mít různou životnost, ale životnost obvykle souvisí s tím, jak je identifikátor resetován:
- Pouze relace:
- Resetování při instalaci: Při každém restartu aplikace se použije nové ID:
- FDR-reset: Nové ID se použije pokaždé, když uživatel aplikaci odinstaluje a znovu nainstaluje:
- FDR-persistent: Nové ID se použije pokaždé, když uživatel resetuje zařízení z výroby:
Resetovatelnost dává uživatelům možnost vytvořit nové ID, které je oddělené od všech existujících informací o profilu. Čím déle a spolehlivěji přetrvává identifikátor, například takový, který přetrvává i po obnovení továrního nastavení, tím větší je riziko, že uživatel může být vystaven dlouhodobému sledování. Pokud je identifikátor resetován při přeinstalaci aplikace, snižuje se tím jeho přetrvávání a poskytuje se prostředek pro resetování identifikátoru, i když neexistuje explicitní uživatelská kontrola pro jeho resetování z aplikace nebo systémových nastavení.
Uniqueness
Uniqueness stanovuje pravděpodobnost kolizí; to znamená, že v přidruženém rozsahu existují identické identifikátory. Na nejvyšší úrovni u globálnějedinečného identifikátoru nikdy nedojde ke kolizi, a to ani v jiných zařízeních nebo aplikacích. jinak úroveň jedinečnosti závisí na entropii identifikátoru azdroji náhodnosti použitém k jeho vytvoření. Například pravděpodobnost kolize je mnohem vyšší u náhodných identifikátorů osazených kalendářním datem instalace (například
2019-03-01
) než u identifikátorů osazených časovým razítkem instalace (například1551414181
).Obecně lze identifikátory uživatelských účtů považovat za jedinečné. To znamená, že každá kombinace zařízení/účtu má jedinečný identifikátor. Na druhou stranu, čím méně jedinečný je identifikátor v rámci populace, tím větší je ochrana soukromí, protože je méně užitečný pro sledování jednotlivého uživatele.
Ochrana integrity a nepopiratelnost
K prokázání, že přiřazené zařízení nebo účet má určité vlastnosti, můžete použít identifikátor, který je obtížné podvrhnout nebo přehrát. Můžete například dokázat, že zařízení není virtuální zařízení používané spammerem.Obtížně podvrhnutelné identifikátory také zajišťují nepopiratelnost. Pokud zařízení podepíše zprávu tajným klíčem, je obtížné tvrdit, že zprávu odeslalo zařízení někoho jiného. Neodvolatelnost může být něco, co uživatel chce, například při ověřování platby, nebo to může být nežádoucí vlastnost, například když odešle zprávu, které lituje.
Obvyklé případy použití a vhodný identifikátor k použití
Tato část uvádí alternativy k použití hardwarových identifikátorů, jako je IMEI. Používáníhardwarových identifikátorů se nedoporučuje, protože je uživatel nemůže resetovat a jsou překopírovány na zařízení. V mnoha případech by stačil identifikátor omezený na aplikaci.
Sledovat předvolby odhlášeného uživatele
V tomto případě ukládáte stav na zařízení na straně serveru bez uživatelského účtu.
Použití:
Proč toto doporučení?
Nedoporučuje se uchovávat informace prostřednictvím přeinstalací, protože uživatelé mohou chtít obnovit své předvolby přeinstalací aplikace.
Sledovat odhlašované uživatelské předvolby mezi aplikacemi se stejným podpisovým klíčem
V tomto případě ukládáte stav podle zařízení na straně serveru a přenášíte jej mezi různými aplikacemi, které jsou podepsány stejným klíčem na stejném zařízení.
Použití: SSAID
Proč toto doporučení?
V systému Android 8.0 (úroveň API 26) a vyšších verzích poskytuje SSAID identifikátor, který je společný pro aplikace podepsané stejným podpisovým klíčem vývojáře. Umožňuje sdílet stav mezi těmito aplikacemi, aniž by se uživatel musel přihlašovat k účtu.
Sledovat chování odhlašovaného uživatele
V tomto případě jste vytvořili profil uživatele na základě jeho chování v různých aplikacích/relacích na stejném zařízení.
Použití:
Proč toto doporučení?
Použití reklamního ID je povinné pro případy použití reklamy podle zásad GooglePlay Developer ContentPolicy, protože uživatel jej může resetovat.
Generování analytiky odhlášených nebo anonymních uživatelů
V tomto případě měříte statistiky a analýzy používání pro odhlášené anonymní uživatele.
Použití: FID nebo GUID, pokud FID nestačí
Proč toto doporučení?
FID nebo GUID jsou omezeny na aplikaci, která je vytvořila, což zabraňuje tomu, aby byl identifikátor použit ke sledování uživatelů napříč aplikacemi. Je také snadno obnovitelný, protože uživatel může vymazat data aplikace nebo aplikaci znovu nainstalovat. Procesvytváření identifikátorů FID a GUID je jednoduchý:
- Získání identifikátoru FID: Viz průvodce instalacemi Firebase.
-
Vytvoření GUID: Implementujte logiku do své aplikace, jak ukazuje následující ukázka kódu:
Kotlin
val uniqueID: String = UUID.randomUUID().toString()
Java
String uniqueID = UUID.randomUUID().toString();
Uvědomte si, že pokud jste uživateli sdělili, že údaje, které shromažďujete, jsou anonymní, měli byste zajistit, abyste identifikátor nepřipojovali kPII nebo jiným identifikátorům, které by mohly být s PII spojeny.
Můžete také použít službu Google Analytics for MobileApps, která nabízí řešení pro analýzu jednotlivých aplikací.
Sledování konverzí přihlášených uživatelů
V tomto případě sledujete konverze, abyste zjistili, zda je vaše marketingová strategie úspěšná.
Použití:
Proč toto doporučení?
Jedná se o případ použití související s reklamou, který může vyžadovat ID, které je dostupné napříč různými aplikacemi, takže použití Advertising ID je nejvhodnějším řešením.
Zpracování více instalací na různých zařízeních
V tomto případě potřebujete identifikovat správnou instanci aplikace, pokud je nainstalována na více zařízeních stejného uživatele.
Použití: FID nebo GUID
Proč toto doporučení?
FID je navržen výslovně pro tento účel; jeho rozsah je omezen na aplikaci, takže jej nelze použít ke sledování uživatelů v různých aplikacích, a při přeinstalaci aplikace se resetuje. Ve vzácných případech, kdy FID nestačí, můžete použít také GUID.
Připojení funkcí k odběru mobilních služeb
V tomto případě je třeba přiřadit funkce aplikace k určitým odběrům mobilních služeb v zařízení. Například můžete mít požadavek na ověření přístupu k určitým prémiovým funkcím aplikace na základě předplatného mobilních služeb v zařízení prostřednictvím SIM karty.
Použití: Subscription IDAPI pro identifikaci SIM karet, které jsou v zařízení používány.
Subscription ID poskytuje hodnotu indexu (počínaje 1) pro jednoznačnou identifikaci nainstalovaných SIM karet (včetně fyzických a elektronických) používaných v zařízení. Prostřednictvím tohoto ID může vaše aplikace spojit své funkce s různými informacemi o předplatném pro danou SIM kartu. Tato hodnota je pro danou SIM kartu stabilní, pokud nedojde k obnovení továrního nastavení zařízení. Mohou však nastat případy, kdy stejnáSIM má různé ID předplatného na různých zařízeních nebo různé SIM mají stejné ID na různých zařízeních. pokud ID předplatného není dostatečnějedinečné, doporučuje se spojit ID předplatného s SSAID.
Proč toto doporučení?
Některé aplikace mohou v současné době používat ICCID pro tentoúčel. Vzhledem k tomu, že ICC ID je globálně jedinečné a nelze jej obnovit, je přístup k němu od systému Android 10 omezen na aplikace s
READ_PRIVILEGED_PHONE_STATE
oprávněním. Počínaje systémem Android 11 společnost Google dále omezilapřístup k ICCID prostřednictvím rozhranígetIccId()
API bez ohledu na cílovou úroveň API aplikace. Dotčené aplikace by měly místo toho přejít na používání Subscription ID.Anti-fraud:
V tomto případě chcete omezit počet bezplatného obsahu, například článků,který může uživatel v zařízení zobrazit.
Použití: FID nebo GUID. V systému Android 8.0 (úroveň API 26) a vyšších verzích přichází v úvahu také SSAID, protože je omezeno na podpisový klíč aplikace.
Proč toto doporučení?
Použití GUID nebo FID nutí uživatele k přeinstalování aplikace, aby omezení obsahu obešel, což je dostatečná zátěž, která většinu lidí odradí. Pokud to není dostatečná ochrana, systém Android poskytuje rozhraní DRMAPI, které lze použít k omezení přístupu k obsahu, zahrnuje identifikátor pro jednotlivé APK, Widevine ID.
Funkce operátora
V tomto případě vaše aplikace komunikuje s telefonem a textovými funkcemi zařízení pomocí účtu operátora.
Použití: IMEI, IMSI a Line1
Proč toto doporučení?“
Použití hardwarových identifikátorů je přijatelné, pokud je vyžadováno pro funkce související s operátorem. Tyto identifikátory můžete použít například pro přepínání mezi mobilními operátory nebo sloty SIM nebo pro doručování SMS zpráv přesIP (pro Line1) – uživatelské účty založené na SIM. Pro neprivilegované aplikace však doporučujeme používat přihlášení k účtu pro získání informací o uživatelském zařízení na straně serveru. Jedním z důvodů je, že v systému Android 6.0 (úroveň API 23) a vyšších lze tyto identifikátory používat pouze prostřednictvím oprávnění runtime. Uživatelé mohou toto oprávnění vypnout, takže vaše aplikace by měla tyto výjimky řešit elegantně.
Detekce zneužití:
V tomto případě se snažíte odhalit více falešných zařízení, která útočí na vaše služby zpětné vazby.
Použití: SafetyNet API
Proč toto doporučení?
Identifikátor sám o sobě málo naznačuje, že zařízení je pravé. Můžete ověřit, že požadavek pochází z pravého zařízení se systémem Android – na rozdíl od emulátoru nebo jiného kódu, který podvrhuje jiné zařízení – pomocí metody
attest()
SafetyNet API pro ověření integrity zařízení, které zadává požadavek. Podrobnějšíinformace naleznete v dokumentaci rozhraní SafetyNet API.Detekce podvodů a zneužití: Detekce ukradených pověření vysoké hodnoty
V tomto případě se snažíte zjistit, zda je jedno zařízení použito vícekrát s ukradenými pověřeními vysoké hodnoty, například k provádění podvodných plateb.
Použití: Prevence podvodů vyžaduje ze své podstaty proprietární signály, které se mohou v průběhu času měnit, a proto jsou mimo rozsah tohoto dokumentu. Všimněte si však, že hardwarové identifikátory, jako jsou IMEI a IMSI, lze na rootnutých nebo emulovaných zařízeních snadno změnit, takže nejsou spolehlivými indikátory podvodu.
-