In der Datenschutzerklärung steht nur ein Satz, dass Google Firebase genutzt werde, darunter Crashlytics ohne weitere Erläuterung.
Ich habe den Hersteller um Stellungnahme gebeten. Dieser teilt im Wesentlichen mit, dass lediglich “allgemeine Einstellungen” und “anonyme Daten zu Abstürzen” an Google übermittelt werden.
Die wenigen Qullen, die ich gefunden habe - etwa ein Forenbeitrag unter App-Entwicklern und kurze Analysen von Datenschützern - gehen in ihrer Meinung stark auseinander.
Ich kann leider die Datenübermittlung an Google nicht technisch nachvollziehen.
Meine Fragen sind daher:
Wie ist Firebase im Lichte von Schrems II zu beurteilen?
Ändert das TTDSG etwas an der Einschätzung, falls der Einsatz bisher ohne Einwilligung als zulässig erachtet wurde?
Hat irgendjemand das schon genauer untersucht?
Gibt es gar eine Äußerung einer Aufsichtsbehörde?
Das ist wirklich ein sehr interessanter Aspekt, der leider von den maßgeblichen Stellen nicht angegangen wird.
Bisher finde ich immer nur isolierte Betrachtungen, die aber m.E. an der Realität vorbei gehen - immer nur die “Datenübermittlung an Google”. Gerade bei Firebase und Crashlytics handelt es sich um Dienste, die auf einem “normalen” Android-Smartphone schwer durch etwas anderes ersetzt werden können. Und, wofür dient eigentlich die o.g. (blockierte) Datenübermittlung? - nun, sie registriert den Start einer App mit den Kennungen, welche diese App zuvor vom (Google)-Playstore bei der Installation verpasst bekommen hat, um in dem Fall, dass die App abstürzt, einen Absturzbericht korrekt zustellen zu können. Ist die App (oder ihr Entwickler) noch in der Lage, einen Absturzbericht selbst zuzustellen, wenn sie bereits abgestürzt ist?
Wer den Playstore nicht benutzt - nun ja, bei dem/der sieht es mit diesen Kennungen ggf. anders aus …
Was hat das mit Schremms II zu tun?
Wenn man es genau nimmt: ist ein aktuelles Smartphone mit handelsüblichem Betriebssystem überhaupt noch mit Schremms II vereinbar? Macht es Sinn, auf einer einzelnen App “mit Schremms II” rumzuhacken, falls diese “etwas übermittelt”, wo doch das Betriebssystem bereits beim Einschalten “alles erledigt” hat? (Bitte, nicht extensives Behavior-Tracking hier mit reinziehen! - das ist eine andere Ebene…)
Beschäftigen wir (bzw. die Maßgeblichen) uns tatsächlich mit den Ursachen und deren Lösung, oder reiben wir uns nur im wenig zielführenden Kampf mit Symptomen auf?
Wegen der Beteiligung von Google würde der App-Anbieter Daten (welche?) an diesen Empfänger übermitteln; inkl. der Drittland-Problematik. Je nach Datenumfang hätte Google die Möglichkeit, die Nutzer zu identifizieren; auch durch Abgleich mit eigenen Datenbeständen und anderen Firebase-nutzenden Apps.
Die Benachrichtigungsfunktion wäre nicht schlimm, wenn es dabei bliebe. Allerdings erwarte ich, dass Google mitbekommt und auswertet, wer, wann, mit wem, in welchem Zusammenhang usw. Das wären Zwecke, die über den Kommunikationsvorgang im Rahmen der App-Funktionen hinaus gehen. Der App-Anbieter und Google bräuchten dafür einen Erlaubnistatbestand.
Auch die Abturzanalyse wäre akzeptabel, wenn sie sich auf Zustandsdaten der App und den groben Rahnmen (Betriebssstemversion usw.) beschränken würde; und wenn sie nicht sofort an Google ginge, sondern z. B. der App-Betreiber alle Absturberichte direkt bekommen und zunächst agreggieren würde.
TTDSG: Wenn Firebase Daten ablegt oder ausliest, um Push-Benachrichtigungen als erwünschten Dienst zu erbringen, kann das unter die Ausnahmen von der Einwilligungspflicht fallen. Nicht damit vereinbar sind die anderen möglichen Firebase-Funktionen. Ist nur eine davon aktiv und die Endeinrichtung betroffen, wäre darüber eine Einwilligung fällig.
´
D., dem FFirebase suspekt ist. und der nicht erwartet, dass viele Entwickler sich Gedanken darüber machen, was davon sie einsetzen dürfen.
Um die Diskussion anzukurbeln:
“… sondern z. B. der App-Betreiber alle Absturberichte direkt bekommen …” - wie denn bitte, wenn die App abgestürzt ist? Wer soll das denn tun, wenn nicht jemand anders? Wer außer dem Betriebssystem ist denn noch “auf Sendung”, nachdem die App abgestürzt ist, und könnte dem App-Betreiber Bescheid geben?
“… wenn sie sich auf Zustandsdaten der App und den groben Rahnmen (Betriebssstemversion usw.) beschränken würde…” - ja selbstverständlich - aber es bleibt immer noch der rechtliche Vorbehalt gegen den Weg über z.B. Google Firebase inkl. der dabei verarbeiteten Metadaten, welche konkrete App (App-Instanz-ID) denn nun abgestürzt ist, und der “Webgeschreibung”, welches Smartphone denn nun diesen Absturzbericht auf welchem Weg gesendet hat.
Warum sollte ein Push-Benachrichtigungsdienst, der sehr viel Daten “mitlesen” kann, ohne weiteres rechtskonform sein dürfen, während der Einsatz eines (mehr oder weniger alternativlosen) Absturzberichtsdienstes für sparsam konfigurierte (und in der Regel selten auftretende) Absturzberichte nicht ohne Einwilligung erfolgen dürfte?
Das TTDSG sieht keinen einwilligungspflichtigen Zugriff auf das Endgerät, wenn ein Telemediendienst vom Nutzer ausdrücklich gewünscht wird und nicht anders zur Verfügung gestellt werden kann. Darunter würde ich einen Push-Benachrichtigungsdienst einordnen. Der funktioniert nur, wenn der Nutzer ihn anfordert = ausdrücklich wünscht?
Wenn die App vernünftig programmiert ist, generiert sie einen Coredump. Es ist durchaus üblich und auch sinnvoll, derlei Cores oder Absturzberichte an die Softwareentwickler weiterzuleiten. Unter Linux ist es auch üblich, dass der Nutzer vorher gefragt wird. Gleiches würde ich von mobilen Apps erwarten. Von der Sendung eines Absturzberichtes ist jedoch nicht das Funktionieren einer Software abhängig. Und genau deswegen braucht es eine Einwilligung.
Soweit ich PhilippH verstanden habe, ist beides nicht sein Problem. Ich hatte mir vor einiger Zeit eine Schul-App angeschaut, die ebenfalls regen Kontakt mit firebaseinstallations.googleapis.com, android.clients.google.com, safebrowsing.googleapis.com und storage.googleapis.com pflegte, um zB irgendwelche Scripte nachzuladen. Dabei wurden verschiedene Token, Kennungen und die App-Version an GG übermittelt, was einen Personenbezug zuließ. Nach Schrems-II und mittlerweile auch dt. Entscheidungen sind diese Übermittlungen einwilligungspflichtig. Nach der Entscheidung des LG München (3 O 17493/20) könnte man argumentieren, dass ähnlich den Fonts auch Scripte in der App lokal funktionieren müssen, um eine Übermittlung an GG zu verhindern. Das geht allerdings dann nicht, wenn die vom Entwickler eingebundenen Dienste nur in der Cloud funktionieren. Hier wären wir beim vom Nutzer ausdrücklich erwünschten Dienst = funktionierende App. Nach meiner Ansicht besteht hier eine Diskrepanz zwischen TTDSG und DSGVO. Allerdings sehe ich auch hier nicht, dass der Nutzer die Verwendung von Crashlytics ausdrücklich erwünscht oder das Funktionieren der App davon abhängig ist. Womit wir wieder bei der Einwilligung sind.
erst einmal Danke für die Antworten. Mir ist bewusst, dass es sich um ein recht “globales” Problem handelt und dass dieses vermutlich nicht mit einer Forumsdiskussion zu lösen ist. Mir fällt da wieder Peter Lustig ein “einfach mal abschalten”. Das geht natürlich nicht.
Die Frage, ob man sich speziell an Firebase aufhängen soll (quasi als Symptom) würde ich in diesem Fall bejaen, da die von mir zu prüfende App beim Appstart ohne Nutzerinteraktion mit diesen URLs Kontakt aufnimmt.
Klar kann man sich auf den Standpunkt stellen: wenn ein Android Smartphone hat, hat (oder ist) bereits gegessen. Jedes weitere Aufhängen am “nach Hause telefonieren” wäre damit überflüssig.
Ich finde es trotzdem relevant ob und inwieweit eine App - hier eine, die sich auch an Minderjährige richtet - überflüssigerweise im erheblichen Umfang mit Google kommuniziert und was dabei eigentlich übertragen wird.
Ich möchte aßuerdem zwei Dinge ergänzen:
In Kalifornien wurde 2020 eine Klage gegen Google erhoben in Sachen Firebase - zu finden unter dem AZ 5:20-cv-04688 “Rodriguez et al v. Google”. Dabei wird Google eine systematische und umfangreiche Datenverarbeitung im Zusammenhang mit Firebase vorgeworfen (in einem anderen Verfahren derselben Kanzlei geht es um die Datensammelei von Google entgegen auf dem Smartphone vorgenommener privacy Einstellungen - beide Verfahren sind aber unabhängig voneinander).
Leider finde ich kein Urteil o. ä. da hierzulande und offensichtlich auch in den USA nur über die Klageerhebung berichtet wurde.
Vielleicht weiß jemand mehr?
Ferner habe ich die Datenschutzerklärung eines deutschen Interessensverbands gefunden, wo ausführlich auf Firebase eingegangen wird. Bei diesem wird für Firebase Crashlytics, Push-Benachrichtigung und Analytics jeweils die Einwilligungsbedürftigkeit bejat (allerdings nicht für den Fall, dass Google [!] die IP-Adressen kürzt, angeblich innerhalb der EU - daher sei die RG Art. 6 Abs. 1 lit. f DSGVO [?!] - das dürfte spätestens nach der jüngsten Entscheidung der Österreichischen Aufsichtsbehörde überholt sein - aber hängen wir uns nicht an Kleinigkeiten auf).
Jedenfalls wird in der DSE ausgeführt, dass Daten ohne geeigente Garantieen an Drittstaaten ohne angemessenes Datenschutzniveau übermittelt werden und daher eine Einwilligung (nach Art. 49 Abs. 1 lit a) bzw. in einigen Aspekten nach Art. 6 Abs. 1 lit. a) ) erforderlich sei. Außerdem wird recht ausführlich ausgeführt, welche Daten durch Google verarbeitet werden.
Ich möchte nicht die Rechtmäßigkeit der DSE bewerten (z. B. ob der Ausnahmefall des Art. 49 Abs. 1 lit. a) hier herangezogen werden kann) und schon gar nicht den in Rede stehenden Verein kritisieren sondern nur feststellen, dass offensichtlich mindestens weit umfangereichere Informationen über Firebase gegeben werden müssen als “Wir nutzen Firebase (einen Google Dienst) darunter auch Crashlytics”.
Im Ergebnis wollte ich mit meine Anfrage eine Bestätigung oder Widerlegung meiner Meinung, dass ich der anfragenden Institution zwar den ansonsten datenschutzkonformen SaaS Dienst als Web-Anwendung empfehlen, jedoch von der Nutzung der mobilen (Android) App abraten sollte.
Google selbst schreibt in seinen Datenschutzinformationen zu Firebase:
“Angesichts des Urteils des Gerichtshofs der Europäischen Union zu Datenübertragungen, das den EU-US-Datenschutzschild für ungültig erklärt, verlässt sich Firebase für relevante Datenübertragungen auf Standardvertragsklauseln, die gemäß dem Urteil weiterhin a gültiger rechtlicher Mechanismus zur Übermittlung von Daten gemäß der DSGVO.”
Danach werden noch die neuen SVK erwähnt. Kein Wort allerdings dazu, dass der EuGH ja zusätzliche Garantien gefordert hat und die SVK alleine für nicht ausreichend hält. Vor dem Hintergrund ist es erstaunlich, dass sich Google alleine auf die SVK “verlässt”.
Hier bescheinigt sich Google selbst, dass die Standardklauseln in allen Konstellationen (Pushnachrichten, Absturzanalyse, Profiling) wirksam bleiben. Ohne zu berücksichtigen, dass ich die App z. B. mit Leuten einsetze, von denen viele “Ahmed” heißen, oder mit Kindern. (Oder mit kranken Kindern, die solche interessanten Namen haben, im Zusammenhang mit Berufsgeheimnissen, mehrmals täglich von verschiedenen Geräten und Orten aus, und über längere Zeiträume.)
Wenn Google die Anonymisierung vornimmt würde der Verantwortliche erst mal die nicht anonymisierten Daten dorthin übermitteln. Zu welchen Zwecken und mit welcher Rechtsgrundlage? (Außerdem wird bei der Menge der anderen identifizierenden Angaben das Kürzen der IP-Adresse nicht reichen.)
Und die Verarbeitung durch Google für eigene Zwecke ist damit nicht vom Tisch.
Schließlich ist zweifelhaft, ob Einwilligungen für Drittlandübermittlungen massenhaft eingesetzt werden können, weil sie eigentlich Ausnahmnen für den Einzelfall wären.
D., der sich die Zulässigkeit (/das Zulässig-hinbekommen) einzelner Funktionen gut vorstellen könnte, wenn man sie bewusst und getrennt von den anderen aktiviert. Und wenn es nicht Google wäre.
Und was ist die Schlussfolgerung aus den zusammengetragenen Argumenten und Informationen?: Absturzbericht geht leider nicht!
Welcher durchschnittliche Nutzer einer Smartphone-App soll den eine INFORMIERTE Einwilligung in die Übersendung von Absturzberichten geben? Wie soll die denn aussehen?
Welchen anderen verfügbaren Weg hätten wir denn, um einem Entwickler einen Absturzbericht zugestellen zu können - als mit Mitteln des Betriebssystems?
Und, nur weil Google das Android modularer - und im Kern “schmaler” - konzipiert hat als andere ihre Betriebssysteme, können wir überhaupt bemerken, dass man einen Absturzberichtsdienst crashlytics erst zuschalten und aktivieren muss. Was die Playdienste inkl. dem PlayStore, aus dem die (problematische) App überhaupt erst kam, alles so rumfunken, ordnen wir wieder der “ausdrücklich gewünschten Funktion” zu? Denn, schließlich wollte der Nutzer ja den PlayStore und die Apps daraus…
So wie alle anderen informierten Einwilligungen. Ich kann das Problem nicht wirklich erkennen. Sind Android-App-Entwickler nicht in der Lage, einen Core beim nächsten Start zu finden und eine nutzerfreundliche Übersicht zu generieren?
Mhhmmm, habe ich mich zu undeutlich ausgedrückt? Ich versuch’s nochmal.
Wenn eine App abgestürzt ist, kann sie selbst nichts mehr. In diesem Moment kann nur noch das Betriebssystem tätig werden, indem es die Artefakte der abgestürzten App entweder geordnet sichert und irgendwo abgibt - oder eben nicht.
Da das Android-Betriebssystem nu’mal von Google kommt ebenso wie die allgegenwärtigen Basisdienste (PlayStore, PlayDienste … Google-freie custom ROMs etc. sind die Ausnahme - nicht der zu unterstellende Regelfall) … nun ja … wer/was bitte soll Hand anlegen an die Absturzreste der App?
Übrigens, beim nächsten App-Start gibt es keine Absturzreste vom vorigen Mal mehr, welche die App (der Entwickler) selbst abholen könnte … wo sollen die sein, wenn nicht das Betriebssystem eine Anweisung bzw. einen dafür bestimmten Dienst eingesetzt hat, um diese Reste einzusammeln? Ohne andere Anweisungen für den Absturzfall macht das Betriebssystem nämlich einfach klar Schiff - und nein, dadurch sind Entwickler kaum in der Lage, anders an Absturzdaten ihrer App zu gelangen. Dieses laufende Reinemachen im Speicher ist ein Grundprinzip der Betriebssysteme, ohne dessen strenge Einhaltung sie ja sonst selbst Gefahr laufen würden, von abgestürzten Apps zugemüllt und funktionsunfähig gemacht zu werden.
Das alles soll kein Plädoyer für die totale Unbedenklichkeit der verschiedenen Google-Dienste sein - keinesfalls.
Aber wenn die Verfügbarkeit einer App so relevant für die Nutzer ist, dass sich auch die Sinnhaftigkeit/Erforderlichkeit von Absturzberichten begründen lässt, dann ist es wohl eher kontraproduktiv, letztere von der Einwilligung des Nutzers abhängig zu machen (es sei denn, man spekuliert sowieso auf die pauschale UNINFORMIERTE Einwilligung in alles …).
Nunja, mir ist die Verarbeitung von Cores, Traces oder Absturzberichten jedenfalls aus eigener Erfahrung bekannt. Ergänzend zu haderner schlage ich darum die Bemühung einer Suchmaschine vor. Allein das Stichwort “/data/tombstone” führt zu umfangreichen Informationen über Funktionen und APIs zum Erstellen, Auffinden und Nutzen selbiger. Allerdings benötigen manche Erläuterungen und Quelltexte ein über “Dieses laufende Reinemachen im Speicher ist ein Grundprinzip der Betriebssysteme…” hinausgehendes Verständnis. Aber ich bin sicher, dass in einschlägigen Entwicklerforen weitergeholfen wird.
Alles andere wurde bereits geschrieben. Es sind die rechtlichen Anforderungen zu erfüllen und nicht die Wünsche der Entwickler, die unfähig sind, Privacy by Design umzusetzen.
Nun ja, ob die “geht nicht und basta” Position, die wir Datenschützer immer gern einnehmen - und dabei den fragenden Programmierern auch noch beiläufig unterstellen, dass sie keine Suchmaschine bedienen könnten - , dazu führen wird, dass die Entwickler privacy-by-design lernen? “Haarsträubend” und “unfähig” sind dabei würzige Triebfedern für eine Diskussion, bei der es dann auf den sachlichen Kern nicht mehr ankommt.
Ich war hier angetreten, etwas zu diskutieren, und nicht herablassende Belehrungen einzusammeln.
Das nächste Thema, das im Nichts endet … Danke.
Die Übermittlung der vom “Entwickler” gewünschten technischen Crash-Daten ist mit einer Übermittlung von personenbezogenen Daten verbunden. Bitte nenne dazu eine Rechtsgrundlage jenseits einer Einwilligung (ggf mit einer skizzierten Abwägung bei Verwendung Art 6 I f, “erforderlich” genügt dazu nicht und selbst das wäre zu begründen). Analog für den Datenexport in Drittstaaten. Beachte dabei, dass eventuell wenige User ein “relevantes” Bedürfnis haben (und andere User das eben nicht wollen), aber alle User betroffen sind. Auf die Qualität von Einwilligungen kommt es mir zunächst nicht an.
Ich weiß nicht, wer “wir Datenschützer” sind und warum diese Position immer gern eingenommen wird. Als DSB vertrete ich allenfalls die Position “Verarbeitung ist rechtswidrig”, wenn keine rechtliche Grundlage für die Datenverarbeitung existiert. Diese Position basiert auf den Anforderungen der DSGVO (Art.6). Obige Aussage wird allerdings häufig beim sog. Datenschutzbashing verwendet, bei dem Datenschützer als Verhinderer von Innovationen und Digitalisierung dargestellt werden, um die eigentlichen Fehler und Probleme zu verschleiern.
Es wurde nichts unterstellt. Die nachfolgend zitierte Behauptung und Frage legten nahe, dass das Vorhandensein und der Speicherort von Tombstones unbekannt sind.
Denn wäre beides bekannt, erübrigte sich die Frage. Und dass die Behauptung falsch ist, kann in der Debug-Dokumentation von Android nachgelesen werden. Die Schlussfolgerung lautet also: er/sie/es weiß es nicht besser. Die Nennung eines Stichwortes für eine Suchmaschine scheint mir eine nachvollziehbare Reaktion zu sein, wenn die Motivation zur Zitierung von Quelltexten oder Funktionsbeschreibungen fehlt.
Das Konzept von Privacy by Design existiert seit den 90ern. Es gibt eine ISO-Norm für Softwarequalität. Entwickler sollten das Thema längst verinnerlicht haben. Es ist verwunderlich, dass sie es immer noch lernen.
Der sachliche Kern ist die Informierung über und die Einwilligung in das Versenden personenbezogener Daten. Das kann seit Jahren technisch umgesetzt werden und wird seit Jahren umgesetzt - sowohl für Absturzberichte (auch unter Android) als auch für sonstige Übermittlungen.
Diese “Programmierersicht” im Stil von “habe wollen” finde ich - mit Verlaub - haarsträubend.
“haarsträubend” bedeutet das Hervorrufen von Empörung, Ablehnung und/oder Ärger. Werden personenbezogene Daten ohne Rechtsgrundlage verarbeitet, dann ruft das bei so manchen DSBs ebendies hervor. Das ist wenig verwunderlich, da die Anforderungen bekannt sind (zB DSGVO). Und weil der Mensch keine Maschine ist, darf er emotional reagieren und dies auch äußern. Nach jahrzehntelanger IT-Erfahrung kann ich haderner nur beipflichten und berichten, dass Entwickler kaum einen anderen Fokus als auf das bloße Funktionieren ihrer Applikation setzen. Dementsprechend sehen Debug-Logs aus, die idR keine pseudonymisierte oder anonymiserte Auswertung vorsehen. Dementsprechend sehen die Wünsche für Absturzberichte aus, die oftmals die komplette Systemlandschaft beinhalten usw. Ja, das ist haarsträubend, denn es beschränkt sich nicht auf das Wesentliche, sondern ist auf das Einsammeln egal welcher Daten ausgerichtet (von denen wir regelmäßig 90% löschen, bevor wir sie rausgeben).
Es sind die rechtlichen Anforderungen zu erfüllen und nicht die Wünsche der Entwickler, die unfähig sind, Privacy by Design umzusetzen.
“unfähig” heißt, dass jemand nicht fähig, nicht imstande oder nicht in der Lage ist, existierende Methoden, Funktionen, APIs etc. einzusetzen. Diese Unfähigkeit kann festgestellt werden, wenn genannter Einsatz fehlt. Dabei spielt keine Rolle, ob ein Entwickler den Einsatz schlicht vergaß oder nicht verinnerlichte oder etwas unbekannt ist oder sonstiges. Denn all diese Gründe führen zu einem “nicht in der Lage sein”.
Vielleicht sollten Sie zum Thema “herablassende Bemerkungen” noch einmal Ihre eigenen Beiträge lesen.
Die von Ihnen gestellten Fragen sind von datenschutzrechtlicher und technischer Seite geklärt. Widersprüchliche Aussagen (Google inkl. Dienste als feste Größe setzen vs. rechtliche Anforderungen als feste Größe ablehnen) und nicht den Tatsachen entsprechende Behauptungen (“Absturzbericht geht leider nicht!”, “beim nächsten App-Start gibt es keine Absturzreste vom vorigen Mal mehr”, “Dieses laufende Reinemachen im Speicher ist ein Grundprinzip der Betriebssysteme”) laden dann zu einer Diskussion ein, wenn eine unbekannte Sachlage im Detail erörtert, Widersprüche und Fehler erst erkannt werden müssen. Das ist hier nicht der Fall.
Wäre dies ein technisches Forum, könnte man über signal handling, einzelne Methoden, Funktionen, deren Sinnhaftigkeit und Einsatz diskutieren. Hier sind wir aber im Datenschutzforum, der sachliche Kern ist folglich ein anderer. Die Aufgabe von Datenschützern ist weder die Programmierung einer App noch das Erklären von Funktionen oder Betriebssystemen. Eine Aufgabe ist das Verständlichmachen von Anforderungen, damit Entwickler sie umsetzen können. Ihre Reaktion indes ist wohlbekannt - nämlich aus langwierigen Diskussionen mit den Entwicklern, denen anhand existierender Methoden und Funktionen erst nachgewiesen werden muss, dass und wie eine technische Umsetzung möglich ist. Bei diesen Diskussion frage ich mich häufig, wie die Software wohl aussehen würde, wenn der/die/das DSB keinen IT-Hintergrund besäße und auf die Aussagen dieser Entwickler angewiesen wäre.
Sie wollen worüber genau diskutieren? Über die von haderner angefragte Rechtsgrundlage? Über den Inhalt einer Einwilligung? Über die Anonymisierung von Absturzberichten und ihre Folgen?
Danke für die Antworten. Ui, es gibt wohl eines Grundsätzliches zu diskutieren…
Ich muss gestehen, mir fehlt der IT Background und kann daher bei den technischen Dingen nur wenig beitragen.
Jenseits der Grundsatzdiskussionen möchte ich den Fokus noch einmal auf zwei Fragen lenken:
1. Werden durch die Integration von Google Firebase Diensten (hier insbesondere Crashlytics) personenbezogene Daten an Google übermittelt? Und wenn ja in welchem Umfang
Die Rechtsgrundlage hierfür in der Beratung zu beurteilen ist natürlich mein Job als bDSB.
Der Softwareanbieter hat meine Frage diesbezüglich mit dem Hinweis auf die Übermittlung “anoymisierter Absturzberichte an Google” abgetan - Motto: kein pbD, keine DSGVO.
Technisch prüfen kann ich das nicht. Daher die Kernfrage: stimmt es, was die Klage in Kalifornien behauptet, dass Google mit und durch Firebase die Appnutzung mit dem Sammeln von zahlreichend pbD “überwacht”.
2. Das richtet sich vornehmlich an IT Fachleute: Wie schwer oder einfach ist es Apps für Android Google Firebase zu vermeiden?
Ist es “nur” so, dass es “einfacher, bequemer, billiger” ist oder ist es quasi unumgänglich, sich dieser Google Dienste zu bedienen?
Mir ist mindestens eine App im Bildungsbereich bekannt, die - nach entsprechendem Hinweis - auf Crashlytics verzichtet hat.
Gibt es denn Alternativen, die vielleicht mit Mehraufwand, aber doch mehr oder weniger problemlos implementiert werden können?
Bei dem von mir zu prüfenden Angebot ist die Mobile App ein sehr wichtiger Bestandteil und trägt extrem zum Bedienkomfort bei. Die Anwender (vorwiegend Lehrer/Innen, aber eben auch Schüler/Innen) werden kaum darauf verzichten wollen (da macht man sich als bDSB wieder sehr beliebt).
Soweit ich weiß, werden die IP-Adresse, Gerätekennung und verschiedene Token übermittelt und eine Anonymisierung findet erst bei GG statt. Der Softwareanbieter sollte die Daten exakt benennen können (IP, appId, authToken, fid, token, device, cookie etc.).
Ob und wie GG wen überwacht, wird wohl erst während des Verfahrens ersichtlich, sofern der Einblick gewährt wird.
Wie schwer oder einfach eine Umstellung ist - den Aufwand - muss der Softwareanbieter einschätzen. Gleiches gilt für den Einsatz von und welcher Alternativen (Framework, Plugins, Libraries, Popup für Einwilligung). Man sollte darauf achten, dass die Alternative nicht ebenfalls Daten in Drittstaaten ohne Einwilligung übermittelt.
Ich habe bisher noch keine Aufstellung gesehen, in der alle Daten - einschließlich Metadaten - aufgelistet sind, die von Crashlytics übermittelt werden können oder stets übermittelt werden.
Als DSB sollten wir nicht mutmaßen müssen, was eine App tut, welche von vielen Konfigurationsmöglichkeiten zutrifft, was Dritte damit anstellen werden.
D., dem selten jemand sagen konnte, was das Zeug das er anschleppt genau macht. Wer nicht genauer fragt kriegt keine Antwort. Oder nein, den Standard: “Es kommt drauf an.” Wobei wir dafür nicht mal den Möglichkeitsraum kennen.