Best Practices für eindeutige Bezeichner

Dieses Dokument bietet eine Anleitung für die Auswahl geeigneter Bezeichner für Ihre App auf der Grundlage Ihres Anwendungsfalls.

Einen allgemeinen Überblick über Android-Berechtigungen finden Sie unter Übersicht über Berechtigungen. Spezifische Best Practices für die Arbeit mit Android-Berechtigungen finden Sie unter Best Practices für App-Berechtigungen.

Best Practices für die Arbeit mit Android-Kennungen

Befolgen Sie bei der Arbeit mit Android-Kennungen die folgenden Best Practices:

1. Verwenden Sie keine Hardware-Kennungen. In den meisten Anwendungsfällen können Sie die Verwendung von Hardware-Identifikatoren wie SSAID (Android ID) vermeiden, ohne die erforderliche Funktionalität einzuschränken.

   Android 10 (API-Level 29) fügt Einschränkungen für nicht rücksetzbare Identifikatoren hinzu, die sowohl IMEI als auch Seriennummer umfassen. Ihre App muss eine App für Geräte- oder Profileigentümer sein, über spezielle Betreiberberechtigungen oder die privilegierte Berechtigung READ_PRIVILEGED_PHONE_STATE verfügen, um auf diese Identifikatoren zugreifen zu können.

2. Verwenden Sie eine Werbe-ID nur für die Erstellung von Benutzerprofilen oder für Werbezwecke. Wenn Sie eine Werbe-ID verwenden, respektieren Sie immer die Auswahlmöglichkeiten der Benutzer in Bezug auf das Adtracking. Stellen Sie außerdem sicher, dass die Kennung nicht mit persönlich identifizierbaren Informationen (PII) in Verbindung gebracht werden kann, und vermeiden Sie die Überbrückung von Werbe-ID-Rücksetzungen.

3. Verwenden Sie für alle anderen Anwendungsfälle, mit Ausnahme von Zahlungsbetrug und Telefonie, nach Möglichkeit eine Firebase-Installations-ID (FID) oder eine privat gespeicherte GUID. Für die überwiegende Mehrheit der Anwendungsfälle, bei denen es sich nicht um Werbung handelt, sollte eine FID oder GUID ausreichend sein.

4. Verwenden Sie APIs, die für Ihren Anwendungsfall geeignet sind, um das Datenschutzrisiko zu minimieren. Verwenden Sie die DRM-API für den Schutz hochwertiger Inhalte und die SafetyNet-APIs für den Schutz vor Missbrauch. Die SafetyNet-APIs sind der einfachste Weg, um festzustellen, ob ein Gerät echt ist, ohne ein Risiko für die Privatsphäre einzugehen.

Die verbleibenden Abschnitte dieses Leitfadens erläutern diese Regeln im Zusammenhang mit der Entwicklung von Android-Apps.

Arbeiten mit Werbe-IDs

Die Werbe-ID ist ein vom Benutzer zurücksetzbarer Bezeichner und eignet sich für Werbeanwendungen. Bei der Verwendung dieser ID sind jedoch einige wichtige Punkte zu beachten:

Achtet immer auf die Absicht des Nutzers, die Werbe-ID zurückzusetzen.Überbrückt keine Rücksetzungen durch den Nutzer, indem ihr eine andere Kennung oder einen Fingerabdruck verwendet, um nachfolgende Werbe-IDs ohne die Zustimmung des Nutzers miteinander zu verknüpfen. Die Google Play Developer ContentPolicy besagt Folgendes:

„…wenn eine neue Werbekennung zurückgesetzt wird, darf sie nicht mit einer früheren Werbekennung oder mit Daten, die von einer früheren Werbekennung abgeleitet wurden, ohne die ausdrückliche Zustimmung des Nutzers verknüpft werden.“

Beachten Sie immer das zugehörige Personalized Ads-Flag. Werbe-IDs sind insofern konfigurierbar, als die Nutzer den Umfang des mit der ID verbundenen Trackings begrenzen können. Verwenden Sie immer die AdvertisingIdClient.Info.isLimitAdTrackingEnabled()Methode, um sicherzustellen, dass Sie die Wünsche Ihrer Nutzer nicht missachten. Die GooglePlay Developer ContentPolicy besagt Folgendes:

„…Sie müssen sich an die Einstellung eines Nutzers „Abmeldung von interessenbezogener Werbung“ oder „Abmeldung von Anzeigenpersonalisierung“ halten. Wenn ein Nutzer diese Einstellung aktiviert hat, dürfen Sie die Werbekennung nicht für die Erstellung von Nutzerprofilen zu Werbezwecken oder für die gezielte Ansprache von Nutzern mit personalisierter Werbung verwenden.“

„Beachten Sie alle Datenschutz- oder Sicherheitsrichtlinien, die mit den von Ihnen verwendeten SDKs verbunden sind und sich auf die Verwendung der Werbekennung beziehen.Wenn Sie beispielsweise true in dieenableAdvertisingIdCollection()Methode aus dem Google Analytics SDK übergeben, stellen Sie sicher, dass Sie alle anwendbaren Analytics SDK-Richtlinien überprüfen und einhalten.

Beachten Sie auch, dass die Google Play Developer ContentPolicy verlangt, dass die Werbe-ID „nicht mit persönlich identifizierbaren Informationen verbunden oder mit einer dauerhaften Gerätekennung verknüpft werden darf (z. B. SSAID, MAC-Adresse, IMEI usw.),).“

Angenommen, Sie möchten Informationen sammeln, um Datentabellen mit den folgenden Spalten zu füllen:

In diesem Beispiel, könnte die ad_id-Spalte über die account_id-Spalte in beiden Tabellen mit PII verknüpft werden, was einen Verstoß gegen die Google Play DeveloperContent-Richtlinie darstellen würde, wenn Sie nicht die ausdrückliche Genehmigung Ihrer Nutzer einholen.

Denken Sie daran, dass die Verknüpfungen zwischen Anzeigen-ID und PII nicht immer so explizit sind. Es ist möglich, „Quasi-Identifikatoren“ zu haben, die sowohl in PII- als auch in Ad-ID-geschlüsselten Tabellen erscheinen, was ebenfalls Probleme verursacht. Nehmen wir zum Beispiel an, wir ändernTABLE-01 und TABLE-02 wie folgt:

In diesem Fall, bei hinreichend seltenen Klickereignissen ist es immer noch möglich, eine Verknüpfung zwischen der Werbekunden-ID TABLE-01 und der in TABLE-02 enthaltenen PII unter Verwendung des Zeitstempels des Ereignisses und des Gerätemodells herzustellen.

Obwohl es oft schwierig ist, zu garantieren, dass keine solchen Quasi-Identifikatoren in einem Datensatz vorhanden sind, können Sie die offensichtlichsten Join-Risiken vermeiden, indem Sie eindeutige Daten nach Möglichkeit verallgemeinern. Im vorangegangenen Beispiel würde dies bedeuten, die Genauigkeit des Zeitstempels zu verringern, so dass bei jedem Zeitstempel mehrere Geräte mit demselben Modell auftauchen.

Andere Lösungen umfassen die folgenden:

• Nicht Tabellen entwerfen, die PII explizit mit Werbe-IDs verknüpfen. Im ersten Beispiel oben würde dies bedeuten, die Spalte account_id nicht in TABLE-01 aufzunehmen.

• Zugangskontrolllisten für Benutzer oder Rollen, die sowohl auf die mit der Werbe-ID verschlüsselten Daten als auch auf die PII zugreifen können, zu trennen und zu überwachen.Durch eine strenge Kontrolle und Prüfung der Möglichkeit, gleichzeitig auf beide Quellen zuzugreifen (z. B. durch eine Verknüpfung zwischen Tabellen), verringern Sie das Risiko einer Verbindung zwischen der Werbe-ID und den PII. Im Allgemeinen bedeutet Zugriffskontrolle Folgendes:

  1. Zugriffskontrolllisten (ACLs) für die Schlüssel-Daten der Werbe-ID und die PII getrennt halten, um die Anzahl der Personen oder Rollen zu minimieren, die in beidenACLs enthalten sind.
  2. Zugriffsprotokollierung und -prüfung einführen, um alle Ausnahmen von dieser Regel zu erkennen und zu verwalten.

Weitere Informationen zum verantwortungsvollen Umgang mit Werbe-IDs finden Sie in derAdvertisingIdClient API-Referenz.

Arbeiten mit FIDs und GUIDs

Die einfachste Lösung zur Identifizierung einer App-Instanz, die auf einem Gerät ausgeführt wird, ist die Verwendung einer Firebase-Installations-ID (FID), und dies ist die empfohlene Lösung für die meisten Nicht-Ads-Anwendungsfälle. Nur die App-Instanz, für die sie bereitgestellt wurde, kann auf diesen Bezeichner zugreifen, und er ist (relativ) leicht zurücksetzbar, da er nur so lange bestehen bleibt, wie die App installiert ist.

Folglich bieten FIDs bessere Datenschutzeigenschaften im Vergleich zu nicht zurücksetzbaren, gerätebezogenen Hardware-IDs. Weitere Informationen finden Sie in derfirebase.installationsAPI-Referenz.

In Fällen, in denen eine FID nicht praktikabel ist, können Sie auch benutzerdefinierte, global eindeutige IDs (GUIDs) verwenden, um eine App-Instanz eindeutig zu identifizieren. Der einfachste Weg, dies zu tun, ist die Generierung einer eigenen GUID unter Verwendung des folgenden Codes:

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

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

Da der Bezeichner global eindeutig ist, kann er zur Identifizierung einer bestimmten App-Instanz verwendet werden. Um Probleme im Zusammenhang mit der Verknüpfung des Bezeichners in verschiedenen Anwendungen zu vermeiden, speichern Sie GUIDs im internen Speicher und nicht im externen (gemeinsamen) Speicher. Weitere Informationen finden Sie auf der Übersichtsseite Daten- und Dateispeicher.

Nicht mit MAC-Adressen arbeiten

MAC-Adressen sind weltweit eindeutig, können nicht vom Benutzer zurückgesetzt werden und überleben Werksresets. Aus diesen Gründen und zum Schutz der Privatsphäre der Benutzer ist der Zugriff auf MAC-Adressen bei Android-Versionen ab 6 auf Systemanwendungen beschränkt. Apps von Drittanbietern können nicht auf sie zugreifen.

MAC-Adressenverfügbarkeit ändert sich in Android 11

Bei Apps, die auf Android 11 und höher abzielen, erfolgt die MAC-Randomisierung für Passpoint-Netzwerke pro Passpoint-Profil, wobei eine eindeutige MAC-Adresse auf der Grundlage der folgenden Felder erzeugt wird:

• Fully-qualified domain name (FQDN)
• Realm
• Benutzerdaten, basierend auf den im Passpoint-Profil verwendeten Daten:
  • Benutzerdaten: Benutzername
  • Zertifikatdaten: Zertifikat und Zertifikatstyp
  • SIM-Daten: EAP-Typ und IMSI

Außerdem können nichtprivilegierte Anwendungen nicht auf die MAC-Adresse des Geräts zugreifen; nur Netzwerkschnittstellen mit einer IP-Adresse sind sichtbar. Dies wirkt sich auf diegetifaddrs()undNetworkInterface.getHardwareAddress()Methoden sowie auf das Senden von RTM_GETLINK Netlink-Nachrichten aus.

Nachfolgend eine Liste der Möglichkeiten, wie Apps von dieser Änderung betroffen sind:

• NetworkInterface.getHardwareAddress() gibt für jede Schnittstelle Null zurück.
• Apps können die bind()-Funktion nicht auf NETLINK_ROUTE-Sockets verwenden.
• Der ip-Befehl gibt keine Informationen über Schnittstellen zurück.
• Anwendungen können keine RTM_GETLINK-Nachrichten senden.

Bitte beachten Sie, dass die meisten Entwickler die übergeordneten APIs vonConnectivityManager verwenden sollten und nicht die untergeordneten APIs wieNetworkInterface,getifaddrs()oder Netlink-Sockets. Eine App, die beispielsweise aktuelle Informationen über die aktuellen Routen benötigt, kann diese Informationen erhalten, indem sie mit ConnectivityManager.registerNetworkCallback() auf Netzwerkänderungen wartet und das zugehörigeLinkProperties.getRoutes() des Netzwerks aufruft.

Kennungsmerkmale

Das Android-Betriebssystem bietet eine Reihe von IDs mit unterschiedlichen Verhaltensmerkmalen. Diese Eigenschaften haben jedoch auch Auswirkungen auf den Datenschutz, daher ist es wichtig zu verstehen, wie diese Eigenschaften miteinander interagieren.

Geltungsbereich

Der Geltungsbereich der Kennung erklärt, welche Systeme auf die Kennung zugreifen können. Der Anwendungsbereich von Android-Kennungen gibt es im Allgemeinen in drei Varianten:

• Einzelne App: Die ID ist intern für die App und nicht für andere Apps zugänglich.
• Gruppe von Apps: Die ID ist für eine vordefinierte Gruppe von verwandten Apps zugänglich.
• Gerät: Die ID ist für alle auf dem Gerät installierten Apps zugänglich.

Je breiter der Geltungsbereich einer Kennung ist, desto größer ist das Risiko, dass sie für Tracking-Zwecke verwendet wird. Umgekehrt kann ein Identifikator, auf den nur eine einzige App-Instanz zugreifen kann, nicht verwendet werden, um ein Gerät über Transaktionen in verschiedenen Apps zu verfolgen.

Rücksetzbarkeit und Persistenz

Rücksetzbarkeit und Persistenz definieren die Lebensdauer des Identifikators und erklären, wie er zurückgesetzt werden kann. Übliche Auslöser für das Zurücksetzen sind: Zurücksetzen in der Anwendung, Zurücksetzen über die Systemeinstellungen, Zurücksetzen beim Start und Zurücksetzen bei der Installation. Android-Kennungen können unterschiedliche Lebensspannen haben, aber die Lebensdauer hängt in der Regel davon ab, wie die Kennung zurückgesetzt wird:

• Nur für Sitzungen: Jedes Mal, wenn der Benutzer die App neu startet, wird eine neue ID verwendet.
• Installationsreset: Jedes Mal, wenn der Benutzer die App deinstalliert und neu installiert, wird eine neue ID verwendet.
• FDR-Reset: Es wird jedes Mal eine neue ID verwendet, wenn der Benutzer das Gerät werkseitig zurücksetzt.
• FDR-persistent: Die ID überlebt das Zurücksetzen auf die Werkseinstellungen.

Die Rücksetzbarkeit gibt dem Benutzer die Möglichkeit, eine neue ID zu erstellen, die von allen bestehenden Profilinformationen abgekoppelt ist. Je länger und zuverlässiger eine Kennung bestehen bleibt, z. B. eine Kennung, die auch nach einem Zurücksetzen auf die Werkseinstellungen bestehen bleibt, desto größer ist das Risiko, dass der Nutzer einer langfristigen Verfolgung ausgesetzt wird. Wenn die Kennung bei einer Neuinstallation der App zurückgesetzt wird, verringert dies die Persistenz und bietet eine Möglichkeit, die Kennung zurückzusetzen, selbst wenn es keine explizite Benutzerkontrolle gibt, um sie innerhalb der App oder der Systemeinstellungen zurückzusetzen.

Einzigartigkeit

Einzigartigkeit legt die Wahrscheinlichkeit von Kollisionen fest, d. h., dass identische Kennungen innerhalb des zugehörigen Bereichs existieren. Auf der höchsten Stufe kommt es bei einem global eindeutigen Bezeichner nie zu einer Kollision, auch nicht auf anderen Geräten oder Anwendungen.Ansonsten hängt der Grad der Einzigartigkeit von der Entropie des Bezeichners und der zur Erstellung verwendeten Zufallsquelle ab. Beispielsweise ist die Wahrscheinlichkeit einer Kollision bei zufälligen Bezeichnern, die mit dem Kalenderdatum der Installation (z. B. 2019-03-01) versehen sind, viel höher als bei Bezeichnern, die mit dem Unixtimestamp der Installation (z. B. 1551414181) versehen sind.

Im Allgemeinen können Benutzerkonto-Bezeichner als eindeutig angesehen werden. Das heißt, jede Geräte-/Kontokombination hat eine eindeutige ID. Andererseits ist der Schutz der Privatsphäre umso größer, je weniger eindeutig eine Kennung innerhalb einer Population ist, da sie für die Verfolgung eines einzelnen Benutzers weniger nützlich ist.

Integritätsschutz und Nichtabstreitbarkeit

Man kann eine Kennung verwenden, die schwer zu fälschen oder wiederzugeben ist, um zu beweisen, dass das zugehörige Gerät oder Konto bestimmte Eigenschaften hat. So können Sie beispielsweise nachweisen, dass es sich bei dem Gerät nicht um ein virtuelles Gerät handelt, das von einem Spammer verwendet wird.Schwer zu fälschende Bezeichner bieten auch die Möglichkeit der Nicht-Abstreitbarkeit. Wenn das Gerät eine Nachricht mit einem geheimen Schlüssel signiert, ist es schwierig zu behaupten, dass die Nachricht von einem anderen Gerät gesendet wurde. Nicht-Widerlegbarkeit kann etwas sein, das ein Benutzer wünscht, z. B. bei der Authentifizierung einer Zahlung, oder es kann eine unerwünschte Eigenschaft sein, z. B. wenn er eine Nachricht sendet, die er bereut.

Gebräuchliche Anwendungsfälle und der zu verwendende Identifikator

Dieser Abschnitt bietet Alternativen zur Verwendung von Hardware-IDs wie IMEI. Von der Verwendung von Hardware-IDs wird abgeraten, da der Benutzer sie nicht zurücksetzen kann und sie auf das Gerät beschränkt sind. In vielen Fällen würde eine App-gebundene Kennung ausreichen.

Verfolgen Sie die Einstellungen des abgemeldeten Benutzers

In diesem Fall speichern Sie den Status pro Gerät auf der Serverseite ohne ein Benutzerkonto.

Verwenden: FID oder GUID

Warum diese Empfehlung?

Die Aufrechterhaltung von Informationen durch Neuinstallationen wird nicht empfohlen, da Benutzer ihre Einstellungen durch eine Neuinstallation der App zurücksetzen möchten.

Verfolgen Sie abgemeldete Benutzereinstellungen zwischen Apps mit demselben Signierschlüssel

In diesem Fall speichern Sie den Status pro Gerät auf der Serverseite und übertragen ihn zwischen verschiedenen Apps, die mit demselben Schlüssel auf demselben Gerät signiert sind.

Verwendung: SSAID

Warum diese Empfehlung?

In Android 8.0 (API-Level 26) und höher bietet SSAID einen Identifikator, der zwischen Apps, die mit demselben Entwickler-Signierschlüssel signiert wurden, gemeinsam verwendet wird. Damit können Sie den Status zwischen diesen Apps austauschen, ohne dass sich der Benutzer bei einem Konto anmelden muss.

Verfolgung des Verhaltens abgemeldeter Nutzer

In diesem Fall haben Sie ein Profil eines Nutzers erstellt, das auf seinem Verhalten in verschiedenen Apps/Sitzungen auf demselben Gerät basiert.

Verwendung: Advertising ID

Warum diese Empfehlung?

Die Verwendung der Advertising ID ist gemäß der GooglePlay Developer ContentPolicy für Werbezwecke obligatorisch, da der Nutzer sie zurücksetzen kann.

Generate signed-out or anonymous user analytics

In diesem Fall messen Sie Nutzungsstatistiken und Analysen für signed-out oder anonyme Nutzer.

Use: FID oder eine GUID, wenn eine FID nicht ausreicht

Warum diese Empfehlung?

Eine FID oder GUID ist auf die Anwendung beschränkt, die sie erstellt, wodurch verhindert wird, dass die Kennung zur Verfolgung von Nutzern in anderen Anwendungen verwendet wird. Außerdem kann sie leicht zurückgesetzt werden, da der Benutzer die App-Daten löschen oder die App neu installieren kann. Der Prozess der Erstellung von FIDs und GUIDs ist einfach:

• Abrufen einer FID: Siehe die Firebase-Installationsanleitung.

• Erstellen einer GUID: Implementieren Sie eine Logik in Ihrer App, wie im folgenden Codesnippet gezeigt:

  Kotlin

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

  Java

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

Wenn Sie dem Benutzer mitgeteilt haben, dass die von Ihnen gesammelten Daten anonym sind, sollten Sie sicherstellen, dass Sie die Kennung nicht mitPII oder anderen Kennungen verknüpfen, die mit PII verknüpft werden könnten.

Sie können auch Google Analytics für MobileApps verwenden, das eine Lösung für die Analyse pro App bietet.

Verfolgen Sie Konversionen von abgemeldeten Nutzern

In diesem Fall verfolgen Sie Konversionen, um festzustellen, ob Ihre Marketingstrategie erfolgreich ist.

Verwenden Sie: Advertising ID

Warum diese Empfehlung?

Dies ist ein werbebezogener Anwendungsfall, der eine ID erfordern könnte, die über verschiedene Apps hinweg verfügbar ist, daher ist die Verwendung einer Advertising ID die geeignetste Lösung.

Mehrere Installationen über verschiedene Geräte hinweg handhaben

In diesem Fall müssen Sie die richtige Instanz der App identifizieren, wenn sie auf mehreren Geräten für denselben Benutzer installiert ist.

Verwendung: FID oder GUID

Warum diese Empfehlung?

Eine FID wurde explizit für diesen Zweck entwickelt; ihr Geltungsbereich ist auf die App beschränkt, so dass sie nicht verwendet werden kann, um Benutzer über verschiedene Apps hinweg zu verfolgen, und sie wird bei einer Neuinstallation der App zurückgesetzt. In den seltenen Fällen, in denen eine FID nicht ausreicht, können Sie auch eine GUID verwenden.

Funktionalität mit Mobilservice-Abonnements verknüpfen

In diesem Fall müssen Sie die Funktionalität der App mit bestimmten Mobilservice-Abonnements auf dem Gerät verknüpfen. Beispielsweise kann es erforderlich sein, den Zugriff auf bestimmte Premium-App-Funktionen auf der Grundlage der Mobilfunkabonnements des Geräts über die SIM zu überprüfen.

Verwenden Sie: Subscription IDAPI, um SIMs zu identifizieren, die auf dem Gerät verwendet werden.

Die Subscription ID bietet einen Indexwert (beginnend bei 1) zur eindeutigen Identifizierung der installierten SIMs (einschließlich physischer und elektronischer), die auf dem Gerät verwendet werden. Über diese ID kann Ihre Anwendung ihre Funktionalität mit verschiedenen Abonnementinformationen für eine bestimmte SIM verknüpfen. Dieser Wert ist für eine bestimmte SIM-Karte stabil, es sei denn, das Gerät wird auf die Werkseinstellungen zurückgesetzt. Es kann jedoch Fälle geben, in denen dieselbe SIM-Karte auf verschiedenen Geräten eine andere Abonnement-ID hat oder verschiedene SIM-Karten auf verschiedenen Geräten dieselbe ID haben. Wenn die Abonnement-ID nicht eindeutig genug ist, wird empfohlen, die Abonnement-ID mit der SSAID zu verketten.

Warum diese Empfehlung?

Einige Apps verwenden derzeit möglicherweise die ICCID für diesen Zweck. Da die ICC-ID global eindeutig und nicht rücksetzbar ist, ist der Zugriff seit Android 10 auf Apps mit READ_PRIVILEGED_PHONE_STATEBerechtigung beschränkt. Ab Android 11 hat Google den Zugriff auf die ICCID über die getIccId()API weiter eingeschränkt, unabhängig von der Ziel-API-Stufe der App. Betroffene Apps sollten stattdessen auf die Verwendung der Abonnement-ID umsteigen.

Betrugsbekämpfung: Enforcing free content limits and detecting Sybil attacks

In diesem Fall möchten Sie die Anzahl der kostenlosen Inhalte, wie z.B. Artikel, begrenzen, die ein Benutzer auf einem Gerät sehen kann.

Verwenden: FID oder GUID. Unter Android 8.0 (API-Level 26) und höher ist SSAID ebenfalls eine Option, da sie auf den App-Signierschlüssel beschränkt ist.

Warum diese Empfehlung?

Die Verwendung einer GUID oder FID zwingt den Benutzer, die App neu zu installieren, um die Inhaltsbeschränkungen zu umgehen, was für die meisten Menschen eine ausreichende Belastung darstellt. Wenn dies kein ausreichender Schutz ist, bietet Android eine DRMAPI, die verwendet werden kann, um den Zugriff auf Inhalte zu beschränken, einschließlich einer pro-APK-Kennung, der Widevine ID.

Trägerfunktionalität

In diesem Fall interagiert Ihre App mit der Telefon- und Textfunktionalität des Geräts unter Verwendung eines Trägerkontos.

Verwendung: IMEI, IMSI und Line1

Warum diese Empfehlung?

Die Verwendung von Hardware-Identifikatoren ist akzeptabel, wenn sie für eine betreiberbezogene Funktionalität erforderlich ist. Sie könnten diese Bezeichner beispielsweise verwenden, um zwischen Mobilfunkanbietern oder SIM-Slots zu wechseln oder um SMS-Nachrichten über IP (für Line1) zuzustellen – SIM-basierte Benutzerkonten. Für unprivilegierte Anwendungen wird jedoch empfohlen, eine Kontoanmeldung zu verwenden, um die Benutzergerätedaten serverseitig abzurufen. Ein Grund dafür ist, dass diese Identifikatoren in Android 6.0 (API-Level 23) und höher nur über eine Laufzeitberechtigung verwendet werden können. Benutzer können diese Berechtigung ausschalten, daher sollte Ihre App diese Ausnahmen sorgfältig behandeln.

Missbrauchserkennung: Identifizierung von Bots und DDoS-Angriffen

In diesem Fall versuchen Sie, mehrere gefälschte Geräte zu erkennen, die Ihre Backend-Dienste angreifen.

Verwendung: Die SafetyNet API

Warum diese Empfehlung?

Eine Kennung für sich genommen sagt wenig darüber aus, ob ein Gerät echt ist. Sie können überprüfen, ob eine Anfrage von einem echten Android-Gerät kommt – im Gegensatz zu einem Emulator oder einem anderen Code, der ein anderes Gerät fälscht -, indem Sie die SafetyNet API-Methodeattest() verwenden, um die Integrität eines Geräts zu überprüfen, das eine Anfrage stellt. Ausführlichere Informationen finden Sie in der SafetyNet-API-Dokumentation.

Betrugs- und Missbrauchserkennung: Erkennung von gestohlenen Zugangsdaten von hohem Wert

In diesem Fall versuchen Sie zu erkennen, ob ein einzelnes Gerät mehrfach mit gestohlenen Zugangsdaten von hohem Wert verwendet wird, z. B. um betrügerische Zahlungen vorzunehmen.

Verwendung: Die Betrugsprävention erfordert naturgemäß proprietäre Signale, die sich im Laufe der Zeit ändern können und daher in diesem Dokument nicht berücksichtigt werden. Es ist jedoch zu beachten, dass Hardware-Kennungen wie IMEI und IMSI auf verwurzelten oder emulierten Geräten leicht verändert werden können, so dass sie keine zuverlässigen Indikatoren für Betrug sind.