Anpassung Ihres iOS SDK für Safaris ITP und Tracking-Prävention (DE)
Safaris Intelligent Tracking Prevention (ITP) und andere Datenschutzfunktionen entwickeln sich ständig weiter, was iOS SDKs, die auf traditionelle Tracking-Methoden angewiesen sind, vor Herausforderungen stellt.
Erstanbieterkontext nutzenSafaris ITP schränkt Drittanbieter-Cookies stark ein. Gestalten Sie Ihr iOS SDK so, dass es wann immer möglich im Erstanbieterkontext arbeitet, indem Sie serverseitige Lösungen oder direkte Integration nutzen.
Datenschutzfreundliche Identifikatoren priorisierenWeg von persistenten, websiteübergreifenden Identifikatoren. Konzentrieren Sie sich auf ephemere oder vom Benutzer zugestimmte Identifikatoren, unter Berücksichtigung der Benutzereinstellungen und Apples App Tracking Transparency Framework.
Robuste Fallbacks implementierenAntizipieren Sie, dass einige Datenpunkte oder Tracking-Mechanismen blockiert werden könnten. Erstellen Sie Ihr SDK mit Strategien zur graceful degradation und Fallbacks, um die Kernfunktionalität auch bei aktivem ITP aufrechtzuerhalten.
Bleiben Sie über Apples Richtlinien auf dem LaufendenITP und Datenschutzrichtlinien sind dynamisch. Überprüfen Sie regelmäßig Apples Entwicklerdokumentation und Datenschutz-Updates, um sicherzustellen, dass Ihr SDK konform und effektiv bleibt.
Safaris Intelligent Tracking Prevention (ITP) hat die Landschaft des Web-Trackings grundlegend verändert, insbesondere für Entwickler, die auf Drittanbieter-Cookies und persistente Identifikatoren angewiesen sind. Für iOS SDKs stellt dies eine einzigartige Reihe von Herausforderungen dar, insbesondere bei der Integration mit Webansichten oder der Handhabung der domänenübergreifenden Kommunikation. Apples kontinuierliches Engagement für den Datenschutz der Benutzer, verstärkt durch Funktionen wie App Tracking Transparency (ATT) und strengere Richtlinien zur Datenerfassung, bedeutet, dass SDK-Entwickler ihre Strategien proaktiv anpassen müssen, um die Funktionalität zu gewährleisten, die Datenintegrität zu wahren und die Benutzerzustimmung zu respektieren.
Dieser Blogbeitrag befasst sich mit den Feinheiten von ITP und ähnlichen Datenschutzmechanismen in Safari unter iOS und bietet umsetzbare Erkenntnisse und praktische Beispiele zur Optimierung Ihres SDK. Unser Ziel ist es, Ihnen dabei zu helfen, widerstandsfähige, datenschutzfreundliche SDKs zu entwickeln, die nicht nur zuverlässig funktionieren, sondern auch das Vertrauen der Benutzer in einer zunehmend datenschutzbewussten digitalen Welt fördern.
Safari ITP verstehen und seine Auswirkungen auf iOS SDKs
Intelligent Tracking Prevention (ITP) ist eine Reihe von datenschutzverbessernden Technologien, die in Safari (und WebKit) integriert sind. Ihre Hauptfunktion besteht darin, das websiteübergreifende Tracking zu begrenzen, indem die Verwendung von Cookies und anderen Formen von Website-Daten durch Dritte eingeschränkt wird. Im Laufe der Jahre hat sich ITP in mehreren Iterationen weiterentwickelt, wobei jede strengere Kontrollen einführte:
- Blockierung von Drittanbieter-Cookies: Der wichtigste Aspekt. ITP partitioniert oder blockiert aggressiv Drittanbieter-Cookies, was es Werbetreibenden und Analyseanbietern erschwert, Benutzer über verschiedene Websites hinweg zu verfolgen.
- Storage Access API: Eingeführt als datenschutzfreundliche Möglichkeit für eingebettete Inhalte, den Zugriff auf ihren Erstanbieter-Speicher anzufordern, wenn ein Benutzer mit ihnen interagiert.
- Link-Dekorationsschutz: ITP kann auch Tracking-Parameter aus URLs entfernen, um Tracking durch Link-Dekoration zu verhindern.
- Referrer-Richtlinie: Safari sendet oft eine restriktivere Referrer-Richtlinie (z. B.
strict-origin-when-cross-origin), die den Informationsumfang begrenzt, der an Drittanbieter-Sites weitergegeben wird. - Ephemeral Bounce Tracking Prevention: Identifiziert und mindert Techniken, bei denen Tracker Benutzer über ihre Site umleiten, um Erstanbieter-Cookies zu setzen.
Für iOS SDKs, insbesondere solche, die mit Webinhalten interagieren (z. B. In-App-Browser, Authentifizierungsabläufe, Zahlungsgateways oder eingebettete Analysen), können die Auswirkungen von ITP tiefgreifend sein. Wenn Ihr SDK auf das Setzen oder Lesen von Cookies von einer Drittanbieter-Domain innerhalb eines WKWebView angewiesen ist oder bestimmte Referrer-Informationen erwartet, kann ITP diese Mechanismen unterbrechen, was zu Folgendem führen kann:
- Fehlgeschlagene Authentifizierungs- oder Zahlungsprozesse.
- Ungenauigkeiten in Attributions- oder Analysedaten.
- Unterbrochene Benutzererfahrungen aufgrund fehlender Zustands- oder Sitzungsinformationen.
Strategien für die ITP-sichere iOS SDK-Entwicklung
Die Anpassung an ITP erfordert einen Mentalitätswechsel vom traditionellen Tracking zur datenschutzorientierten Datenverarbeitung. Hier sind die wichtigsten Strategien:
1. Erstanbieterkontext und serverseitige Lösungen priorisieren
Der effektivste Weg, die Einschränkungen von ITP für Drittanbieter-Cookies zu umgehen, ist das Arbeiten innerhalb eines Erstanbieterkontexts. Das bedeutet, dass die Domain, die das Cookie setzt oder auf den Speicher zugreift, dieselbe ist wie die Domain, die der Benutzer gerade besucht.
Praktisches Beispiel: Serverseitiges Tracking für Analysen
Anstatt sich auf ein Drittanbieter-Analyse-Skript zu verlassen, das in Ihrem WKWebView eingebettet ist und versucht, eigene Cookies zu setzen, sollten Sie einen serverseitigen Ansatz in Betracht ziehen:
- SDK sammelt Daten: Ihre iOS-App (oder der Webinhalt in Ihrem
WKWebView) sammelt relevante Benutzerinteraktionsdaten (z. B. angesehenes Produkt, geklickter Button). - Daten an Ihr Backend senden: Diese Daten werden direkt an Ihren eigenen Backend-Server gesendet.
- Backend leitet an Analyseanbieter weiter: Ihr Backend leitet diese Daten dann an die API Ihres Analyseanbieters weiter. Da diese Kommunikation Server-zu-Server erfolgt, umgeht sie die ITP-Einschränkungen für clientseitige Cookies.
Dieser Ansatz gibt Ihnen die volle Kontrolle über die Daten, stellt sicher, dass sie zuverlässig gesendet werden, und unterliegt nicht der browserseitigen Tracking-Prävention.
2. Die Storage Access API für websiteübergreifende Anforderungen nutzen
Wenn Sie unbedingt Zugriff auf websiteübergreifende Cookies innerhalb eines eingebetteten WKWebView benötigen (z. B. für Single Sign-On mit einem Identitätsanbieter), ist die Storage Access API die genehmigte, datenschutzfreundliche Methode. Diese API ermöglicht es Drittanbieter-Inhalten, eine explizite Genehmigung vom Benutzer anzufordern, um auf ihren Erstanbieter-Speicher zuzugreifen.
Praktisches Beispiel: Nahtloses SSO in WKWebView
Stellen Sie sich vor, Ihr SDK bettet ein WKWebView für einen Authentifizierungsablauf ein, der auf Cookies Ihres Identitätsanbieters (IDP) zugreifen muss, um SSO zu erreichen. Ohne die Storage Access API würde Safari diese Cookies blockieren.
Clientseitig (innerhalb Ihres eingebetteten Webinhalts):
document.requestStorageAccess().then(function() {
// Speicherzugriff gewährt, jetzt können Sie Anfragen stellen, die Cookies verwenden
// z.B. den SSO-iFrame laden oder eine XHR-Anfrage an den IDP senden
}).catch(function() {
// Speicherzugriff verweigert oder Benutzerinteraktion erforderlich
// Anmutig behandeln, vielleicht auf eine vollständige Umleitungsanmeldung zurückgreifen
});
iOS SDK (WKUIDelegate und WKNavigationDelegate):
Sie müssen die Benutzeraufforderung behandeln, die Safari anzeigt. Die WKUIDelegate-Methode webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler: (oder ähnliche Berechtigungsanfragen) könnte aufgerufen werden, aber für den Speicherzugriff wird die Aufforderung normalerweise von Safari selbst behandelt. Stellen Sie sicher, dass Ihre WKWebViewConfiguration korrekt eingerichtet ist, insbesondere websiteDataStore.
3. Datenschutzfreundliche Identifikatoren und Benutzerzustimmung übernehmen
Mit App Tracking Transparency (ATT) verlangt Apple die explizite Benutzerzustimmung für das Tracking über Apps und Websites hinweg, die anderen Unternehmen gehören. Ihr SDK sollte dies respektieren. Verzichten Sie darauf, sich ohne Zustimmung auf persistente Geräte-Identifikatoren für Tracking-Zwecke zu verlassen.
Praktisches Beispiel: Umgang mit ATT und IDFA
Wenn Ihr SDK zuvor den Identifier for Advertisers (IDFA) für Attribution oder Targeting verwendet hat:
- ATT-Autorisierung anfordern: Verwenden Sie
AppTrackingTransparency.framework, um die Benutzerautorisierung anzufordern, bevor Sie auf IDFA zugreifen. - Bedingte IDFA-Nutzung: Rufen Sie IDFA nur ab und verwenden Sie es, wenn der Benutzer die Berechtigung erteilt.
- Alternative Identifikatoren: Bei Verweigerung verlassen Sie sich auf kontextspezifische, ephemere Identifikatoren (z. B. eine Sitzungs-ID) oder serverseitig generierte, nicht persistente IDs, die nicht für websiteübergreifendes Tracking verwendet werden.
Swift-Beispiel:
import AppTrackingTransparency
import AdSupport
func requestTrackingAuthorization() {
if #available(iOS 14, *) {
ATTrackingManager.requestTrackingAuthorization { status in
switch status {
case .authorized:
let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
print("IDFA: \(idfa)")
// IDFA für zugestimmtes Tracking verwenden
case .denied, .notDetermined, .restricted:
print("ATT-Autorisierung verweigert oder nicht bestimmt.")
// Auf andere datenschutzfreundliche Methoden zurückgreifen
@unknown default:
break
}
}
} else {
// Fallback für iOS-Versionen vor 14
// Prüfen, ob Tracking über ASIdentifierManager.shared().isAdvertisingTrackingEnabled aktiviert ist
}
}
Wie Didit hilft
Didit, als All-in-One-Identitätsplattform, ist von Natur aus auf einen datenschutzorientierten Ansatz ausgerichtet, was es robust gegenüber ITP und ähnlichen Tracking-Präventionsmechanismen macht. Unser Hauptaugenmerk liegt auf der sicheren Verifizierung echter Menschen, nicht auf websiteübergreifendem Tracking. Didits Architektur ist darauf ausgelegt, Identitätsprüfung, Biometrie, Betrugserkennung und Authentifizierung innerhalb eines einzigen, kontrollierten Systems zu handhaben, wodurch die Abhängigkeit von Drittanbieter-Tracking-Cookies minimiert wird. Dies erreichen wir durch:
- Erstanbieter-Integration: Didits SDKs und APIs sind für die direkte Erstanbieter-Integration in Ihre Anwendung konzipiert, um sicherzustellen, dass Identitätsprüfungsprozesse innerhalb des Kontexts Ihrer App stattfinden und ITP-Bedenken im Zusammenhang mit websiteübergreifendem Tracking weitgehend umgangen werden.
- Serverseitige Verarbeitung: Viele der robusten Funktionen von Didit, wie z. B. AML-Screening und Betrugssignalanalyse, arbeiten serverseitig. Das bedeutet, dass sensible Datenverarbeitung und Identitätsprüfungen sicher auf unserem Backend erfolgen, wodurch clientseitige Tracking-Schwachstellen eliminiert werden.
- Ephemere Biometrie: Didit verarbeitet biometrische Daten im Speicher und löscht sie, wobei nur boolesche Ergebnisse an Ihre Anwendung zurückgegeben werden. Dieser „Privacy by Design“-Ansatz bedeutet, dass wir keine persistenten biometrischen Identifikatoren für Tracking speichern, was perfekt mit den Zielen von ITP übereinstimmt.
- Sichere Authentifizierungsabläufe: Unsere Authentifizierungsmethoden, einschließlich der biometrischen Re-Authentifizierung, sind sicher und privat konzipiert und verwenden Challenge-Response-Mechanismen, die nicht auf websiteübergreifende Cookies zur Zustandsverwaltung angewiesen sind.
- Compliance und Vertrauen: Als SOC 2 Typ II, ISO 27001 und GDPR-konformes Unternehmen basiert Didit auf einem Fundament aus Datenschutz und Sicherheit, was unsere Plattform natürlich widerstandsfähig gegenüber Änderungen in Tracking-Präventionstechnologien macht.
Bereit zum Start?
Die Anpassung Ihres iOS SDK an Safaris ITP und die breitere Datenschutzlandschaft ist nicht nur eine Frage der Compliance; es geht darum, Vertrauen bei Ihren Benutzern aufzubauen und die Langlebigkeit Ihres Produkts zu sichern. Indem Sie Erstanbieterkontexte nutzen, geeignete APIs wie Storage Access verwenden, die Benutzerzustimmung priorisieren und über Apples sich entwickelnde Richtlinien auf dem Laufenden bleiben, können Sie ein robustes und datenschutzfreundliches SDK erstellen.
Erfahren Sie, wie Didits datenschutzorientierte Identitätsplattform Ihre Compliance vereinfachen und das Benutzererlebnis verbessern kann. Besuchen Sie unsere Website, schauen Sie sich unsere technische Dokumentation an oder fordern Sie eine Demo an, um Didit in Aktion zu sehen.