Am 25. Mai 2018 trat die Datenschutzgrundverordnung (DSGVO) in Kraft. Sie stellt Regeln zur Verarbeitung personenbezogener Daten von EU-Bürgern auf und vereinheitlicht die Datenschutzregeln für mehr Klarheit und Transparenz. Auch dass die DSGVO bewirken soll, dass jeder Einzelne aktiv bestimmen kann, was/wann/wie/wo mit seinen persönlichen Daten geschieht, ist in der Grundidee eine gute Sache.

Enormer Umsetzungsaufwand in der Praxis

Aus Unternehmersicht ist die Regelung jedoch außerordentlich kompliziert und aufwändig umzusetzen. So habe Google um die 500 Jahre Arbeit in die Vorbereitung auf die neue Rechtslage investiert.

Obwohl es ja auch in der Vergangenheit schon teils hohe Datenschutzregelungen gab, wird die Situation durch neue Anforderungen verschärft:

• Die Schutzregeln richten sich nicht nach dem Sitz des Unternehmens, sondern nach dem Land des Dateneigentümers. Das heißt, sobald Daten von EU-Bürgern verarbeitet werden, greift die DSGVO. Daher sind Unternehmen in allen Ländern weltweit betroffen.
• Einerseits ist nahezu jede Form von Datenerfassung potenziell problematisch, andererseits ist Datenaufzeichnung ganz normaler Bestandteil heutiger Technologien. Jeder einfache Webserver protokolliert z.B. Zugriffe und IP-Adressen, die als persönliche Daten angesehen werden können. Es ist also gut möglich, dass datenschutzrechtlich relevante Vorgänge in Deinem Projekt stattfinden, obwohl Du selbst gar keine Daten sammelst oder auswertest.
• Du bist verantwortlich, auch für Deine Geschäftsbeziehungen. Wenn Du also z.B. Google Analytics einsetzt, bist Du dafür verantwortlich, dass sich die Datenverarbeitung von Google an die Rechtslage hält und alle Anforderungen erfüllt.
• So gut wie alle Vorgänge bei denen Daten verarbeitet werden, müssen offengelegt und erklärt werden, wodurch sehr lange Rechtstexte entstehen, denen die Benutzer zustimmen müssen.
• Die Regeln gelten für jeden, der Daten erfasst. Egal, ob es der Turnverein, ein Webseitenanbieter oder ein großer Internetkonzern ist. Daten werden nahezu überall verarbeitet. Es muss sich noch nichtmal um Nutzerverfolgung (Tracking) handeln. Jede Kundenkartei und sogar jede E-Mail ist theoretisch betroffen.
• …und vieles mehr.

DSGVO ist auch für Spieleentwickler relevant

Wenn Du Spiele entwickelst, bist Du ebenfalls von der DSGVO betroffen. Selbst wenn Du ein Spiel ohne jegliche Online-Funktion (z.B. Auto-Update) und Datenaufzeichnung (z.B. User-Name) programmieren würdest, kämst Du spätestens bei der Veröffentlichung im Internet (Webseite, Online-Shop, usw.) mit personenbezogenen Daten in Berührung.

Einziger Ausweg wäre möglicherweise ein Publisher, der das Spiel für Dich vertreibt. Dieser übernimmt dann alle datenschutzrelevanten Verpflichtungen, sofern Du rein als Entwickler im Hintergrund bleibst, Deine Technik keinerlei Daten erfasst und der Publisher komplett alle Aufgaben übernimmt, bei denen Daten verarbeitet werden (Webseite, Werbung, Newsletter, Vertrieb, Updates, usw.).

Dein Unity-Spiel könnte betroffen sein

Doch weißt Du überhaupt mit Sicherheit, dass Dein Spiel keine Daten sammelt? Der Teufel steckt hier im technischen Detail: Um nicht ständig das Rad neu erfinden zu müssen, verwendet man normalerweise Bibliotheken und Softwaremodule, also letztlich kurz gesagt eine GameEngine, um ein Spiel herzustellen. Du musst also sicherstellen, dass die Engine auch keine Daten sammelt.

Mit der Unity-Engine erstellte Spiele sammeln grundsätzlich (aber nicht ständig) Daten und schicken sie über das Internet an den Hersteller.

Nach Unitys Angaben zum Datenschutz werden folgende Informationen von Deinen Spielern erfasst:

Unity has collected some or all of the following information about your device: unique device identifiers (e.g., IDFV for iOS devices and Android ID for Android devices); IP address; country of install (mapped from IP address); device manufacturer and model platform type (iOS, Android, Mac, Windows, etc.) and the operating system and version running on your system or device; language; CPU information such as model, the number of CPUs present, frequency, and instruction set support flags; the graphics card type and vendor name; graphics card driver name and version (e.g., “nv4disp.dll 6.10.93.71”); which graphics API is in use (e.g., “OpenGL 2.1” or “Direct3D 9.0c”); amount of system and video RAM present; current screen resolution; version of the Unity Editor used to create the game; sensor flags (e.g., device support for gyroscope, touch pressure or accelerometer); application or bundle identification (“app ID”) of the game installed; unique advertising identifiers provided for iOS and Android devices (e.g., IDFA or Android Ad ID); and a checksum of all the data that gets sent to verify that it transmitted correctly.

Heikel könnte die Kombination aus Geräte-ID sowie der IP-Adresse sein, da sich Anwender damit eindeutig identifizieren lassen. Die IP wurde in der Vergangenheit ohnehin meist zu den persönlichen Daten gezählt, wenn es um Auslegung von Datenschutzregeln ging. Allerdings erklärt Unity auch, dass diese Daten in der Regel anonymisiert und zu statistischen Zwecken nicht-personenbezogen gespeichert werden. Das lässt hoffen, ebenso wie das Bemühen seitens Unity, die DSGVO-Konformität für alle Beteiligten so einfach wie möglich umzusetzen.

Unitys Datenerfassung ist übrigens nicht neu, sondern besteht schon eine Weile. Mit den verschärften Datenschutzregelungen gewinnt diese Situation aber an Bedeutung, zumal Du als Spiele-Hersteller ja für die von Deinem Produkt (auch über Module Dritter) gesammelten Daten verantwortlich bist.

Update: Mittlerweile hat Unity ein Plugin im AssetStore online gestellt, mit dem sich ein Button ins Spiel integrieren lässt, der den Spieler zu einer Webseite mit Datenschutz-Infos und einer Anonymisierungs-Option führt.

Dauer-Nervthemen Analytics und Ads

Etwas komplizierter wird es, wenn Du in Deinem Spiel Analysen, Werbung und andere Dienste mit hohem Interesse an möglichst persönlichen Daten integrierst. Bereits beim Einsatz von Google Analytics auf Webseiten ist die datenschutzrechtliche Situation seit Jahren kompliziert und relativ umständlich umzusetzen. Unity bietet mit Unity Analytics ein Werkzeug an, das Entwicklern aufschlussreiches Feedback über Technik und Spielereignisse liefert. Doch entstehen durch die Datenerfassung höhere Anforderungen an den Datenschutz.

Zu den von Unity Analytics erfassten Daten gehören:

If a game developer or publisher enables Unity Ads or Unity Analytics for their game, we collect data such as device type, country, device language, in-game behavior and purchases, IP address, Apple’s Advertising Identifier (IDFA), and Google Play advertising ID. This information helps developers and publishers tailor games and ads for players and their devices, such as providing ads designed for specific device types, player languages, and game preferences.

Weiter heißt es, dass diese Informationen genutzt werden, um zielgerichtete Produkte und Werbung auszuliefern. Entwickler können seit 25. Mai 2018 ein aktualisiertes SDK für die Einbindung des Werbesystems Unity Ads nutzen, mit dem es den Spielern möglich sein soll, sich aus der Datenerfassung auszutragen.

Bibliotheken Dritter auf Konformität prüfen!

Es gibt noch weitere Anbieter für die Integration von Analyse- oder Werbe-Diensten. Auch diese sind jeweils hinsichtlich der Rechtskonformität und ggf. für Entwickler notwendige Schritte zu untersuchen. Möglicherweise müssen z.B. Zustimmungen der Spieler eingeholt werden, damit das Modul zum Einsatz kommen kann.

Ein Aspekt der DSGVO sieht vor, dass Daten erhoben werden dürfen, wenn ein „berechtigtes Interesse“ besteht. Es geht dabei scheinbar darum, dass nicht willkürlich Daten im großen Stil gesammelt werden, sondern dass die Daten auch wirklich gebraucht werden. Unity greift diesen Punkt auf, um sich (und letztlich uns Entwickler) weiter abzusichern:

Unity is SDKs, it’s plugins, and it’s the engine itself. So, Unity’s profiling is compatible with other, more legitimate interests than merely ads. Crash reports, bug fixes, enabling user-user communication, etc., are each of legitimate interest to our gamers and developers. Our profiling enables those purposes. Unity is in a unique position because our profiling is compatible to those legitimate interests.

Dadurch dass Unity aus einer Komposition von Entwicklungssystemen, Plugins und der eigentlichen GameEngine besteht, gehe der Nutzen der Datensammlung über das zuschneiden von Werbung hinaus. Auch Fehleranalyse und -behebung sieht Unity Technologies als berechtigtes Interesse von Spielern und Entwicklern. Wegen diesem Zusammenspiel sei Unity in einer besonderen Stellung, die z.B. bei der Datenerfassung von anderen, externen Diensten nicht gegeben ist.

Was tun?

Was jetzt zu tun ist, hängt vom Einzelfall ab und muss individuell, ggf. mit Hilfe einer Rechtsberatung, ausgearbeitet werden.

Einige Gedanken und Anregungen für erste Schritte:

1. Analysiere Dein Produkt und finde heraus, wann und wo Daten von Dir oder Dritten erfasst werden.
2. Frage Dich, ob es wirklich nötig ist, Daten zu erfassen. Falls nicht, kann es die Sache enorm vereinfachen, auf die Datenerfassung schlichtweg zu verzichten! Bedenke, dass die Umsetzung der DSGVO nicht nur die Erstellung der Datenschutzerklärung bedeutet, sondern dass den Nutzern nun ausgiebige Auskunfts- und Löschungsrechte zustehen.
3. Lies Dir Ratgeber zum Thema DSGVO durch, um die Details zu verstehen (z.B. Überblick bei e-recht24). Es werden mittlerweile zahlreiche Checklisten (meist für Webseiten) angeboten, mithilfe derer man auch an Dinge erinnert wird, die man sonst schnell übersehen könnte.
4. Erstelle eine Datenschutzerklärung für Deine Spieler. Evtl. kann ein Datenschutzgenerator (z.B. hier) helfen, die korrekten Texte und erforderlichen Angaben zu erzeugen. Wenn Du Plattformen (z.B. Steam) oder Bibliotheken/Engines (z.B. Unity) verwendest, kann ein Hinweis mit Link zu den jeweiligen Datenschutzerklärungen erforderlicher Bestandteil Deiner Datenschutzerklärung sein.
5. Wenn eine Zustimmung zur Datenerfassung erforderlich ist, dann kann es nötig sein, diese in der Software einzuholen. Im Zweifelsfall muss die Art und der Zeitpunkt der Zustimmung protokolliert und nachgewiesen werden können. Manche Vertriebsplattformen, wie z.B. Google Play, verlangen die Angabe einer URL oder Upload der Datenschutzerklärung bereits für die Darstellung des Produkts im Online-Shop.

Zusammenfassung

• Wenn Du ein Spiel nach normalem Stand der heutigen Technik entwickelst und veröffentlichst, ist die DSGVO für Dich als Anbieter relevant.
• Mit Unity erstellte Spiele erfassen Geräte- und Nutzerdaten, die zu Unity Technologies (vermutlich in die USA) übertragen und dort angeblich anonymisiert verarbeitet werden.
• Unity Technologies ist sehr bemüht, die gesamte Technik für alle Beteiligten möglichst einfach DSGVO-konform zu machen und hat seine Dienste wie z.B. Ads und Analytics entsprechend angepasst. Ein Plugin für einen Datenschutz-Button ist jetzt im AssetStore kostenlos erhältlich.
• Datenschutzerklärungen und Auskünfte über die Datenerfassung seitens Unity finden sich hier: Aktualisierte Privacy Policy und Unity Statement on GDPR Readiness
• Prüfe, welche Daten in Deinem Projekt erfasst werden und welche Umsetzungen der Datenschutzregeln erforderlich sind.

 

[disclaimer_rechtsthemen]

 

Verschiedene Möglichkeiten, um Felder im Inspektor anzuzeigen

Die Felder einer MonoBehaviour-Klasse lassen sich im Inspector des Unity-Editors direkt bearbeiten sofern sie als public deklariert und von einem durch den Inspector unterstützten Typ sind.

Der Hack mit [SerializeField]

Felder, die mit private oder auch protected geschützt sind, erscheinen im Inspektor nicht. Unity bietet allerdings ein Attribut namens SerializeField an, das die Sichtbarkeit im Inspektor auch für private Elemente erzwingt.

In der Unity-Dokumentation der SerializeField-Anmerkung heißt es gleich zu Beginn, „you will almost never need this“, also „dies wirst Du so gut wie nie brauchen“. Ein solcher Hinweis sollte schon die Vermutung nahelegen, dass die Verwendung des SerializeField-Attributs nicht der korrekte Weg ist, um Felder im Inspector sichtbar zu machen. Der Begriff selbst sagt außerdem schon aus, dass er für etwas anderes entworfen wurde: „Serialize Field“ heißt soviel wie „speichere das Feld“. Das bezeichnet technisch also etwas anderes als die Anzeige im Inspektor, denn sonst würde es nicht SerializeField, sondern ShowInInspector heißen.

Die Bedeutung von Sichtbarkeitsmodifikatoren

Sehen wir uns den semantischen, also bedeutungsbezogenen, Unterschied etwas näher an.

Eine Klasse kann verschiedene Elemente beinhalten und die Klasse selbst hat immer Zugriff darauf. Kommt nun eine zweite Klasse dazu, so wird durch Sichtbarkeitsmodifikatoren geregelt, worauf diese Klasse zugreifen darf. Der Modifikator public macht das Element nach außen sichtbar, so dass die andere Klasse darauf zugreifen darf. Private dagegen schützt das Element, so dass die äußere Klasse keinen Zugriff hat.

Was SerializeField wirklich macht

Die andere Klasse kann z.B. auch der Serialisierer bzw. Deserialisierer sein, der einen Mechanismus implementiert, um die Werte, die Elementen zugewiesen wurden in eine Datei zu speichern bzw. aus dieser wiederum zu laden. Aufgrund der C#-Sichtbarkeitskonzepte werden hier nur public-Elemente einbezogen. Um eine Klasseninstanz, also ein Objekt, vollständig zu speichern, kann es aber nötig sein, auch private Elemente mitzuspeichern. Um dies schnell und einfach möglich zu machen, stellt Unity das Attribut SerializeField zur Verfügung, das den Serialisierer anweist, die so markierten Elemente ebenfalls mitzuspeichern – unabhängig von deren Sichtbarkeitsregel.

Der entscheidende Unterschied

Der Inspector im Unity-Editor ist letztlich nichts anderes als eine grafische Benutzeroberfläche, für diesen Serialisierungsvorgang, d.h. die gespeicherten Daten werden nicht mehr nur direkt über die Datei, sondern auch über ein Eingabeformular gelesen und geschrieben.

Wenn man nun den Inspector als außenstehende Klasse ansieht, was technisch auch der Fall ist, dann umgeht SerializeField die Sichtbarkeitseinstellung und gibt externen Komponenten Zugriff auf die internen Elemente einer Klasse, auf die es konzeptuell eigentlich keinen Zugriff haben sollte. Von der Code-Architektur her macht es so gesehen nicht viel Sinn SerializeField zu nutzen, denn entweder dürfen aussenstehende Klassen auf die Felder zugreifen – dann können sie auch public sein – oder sie dürfen eben keinen Zugriff haben, dann sollte das auch konsequent im Code so umgesetzt und private oder protected verwendet werden.

[kursbanner thema=“csharp“]

 

 

 

Neulich kam im Support-Forum meines C#-Unity-Kurses die Frage auf, warum wir im Kurs den Spielstand in XML-Dateien und nicht in Unitys PlayerPrefs speichern. Dem Teilnehmer erschien die Serialisierung nach XML sehr viel aufwändiger und außerdem wäre die Schutzstufe des textuellen XML-Formats sehr niedrig, da jeder, also auch Spieler, die Datei verändern könnten.

 

Weshalb wir im Kurs PlayerPrefs nicht verwenden

PlayerPrefs sind in ihrer Struktur sehr begrenzt und eigenen sich nur zur Speicherung einzelner Werte (z.B. Float, Int, String). Komplexere Strukturen (fängt z.B. schon bei den häufig benutzten Typen Vector3 und Quaternion an, von eigenen Klassen ganz zu schweigen) sind nicht möglich. Im Verlauf des C#-Videokurses wechseln wir später von statischen Werten zu dynamischen Listen, so dass eine beliebige Anzahl von Objekten und Werten flexibel in das Savegame eingebunden werden kann. Das ist mit PlayerPrefs ebenso wenig möglich wie z.B. die Verwaltung mehrerer paralleler Spielstände. (Technisch ganz präzise: theoretisch zwar möglich, aber man müsste ein sehr aufwändiges Indizierungssystem selbst programmieren, das dann Listenfunktionen nachahmt.)

PlayerPrefs eigenen sich meiner Meinung nach deshalb eher im Sinne einer ‚Cookie‘-Logik, also für das schnelle und einfache Sichern und Laden von einzelnen Werten, wie z.B. Programmeinstellungen.

PlayerPrefs sind zudem schwer zu überprüfen und zu verwalten. Um eine Liste der gespeicherten Werte zu sehen, müsste man Tools schreiben oder in der Windows-Registry wühlen. Auf MacOS oder anderen Geräten wird es noch schwieriger, zumal sich auch die Speicherorte technisch noch unterscheiden. Insbesondere für einen eLearning-Kurs, bei dem die Nachvollziehbarkeit im Vordergrund stehen sollte, ist das denkbar ungüstig.

Weshalb wir hier XML verwenden

XML kann beliebige verschachtelte Strukturen ausdrücken und bleibt dabei lesbar und nachvollziehbar. Da ich davon ausgehe, dass viele Teilnehmer des Kurses verstehen wollen, wie die Technik funktioniert, eignet es sich daher hervorragend, um den Prozess zu erklären, weil transparent ist, welche Daten wie/wann/wohin fließen.

Mit solchen dateibasierten Serialisierungsformaten ist es sehr leicht möglich, Spielstände zu öffnen, anzusehen, zu speichern, weitere parallel dazu anzulegen und komplexe Strukturen in einem Zug zu speichern und zu löschen. Dass .net hierfür bereits Serialisierungsmechnismen zur Verfügung stellt, die die Umwandlung vom Arbeitsspeicher in XML und zurück übernehmen, macht die Sache noch viel einfacher.

Zu den Nachteilen von XML gehört ein gewisser Overhead an strukturgebenden Daten.

[kursbanner thema=“csharp“]

Das Problem der Offenheit

Die Einsehbarkeit von XML kann natürlich unerwünscht sein, da nicht nur Entwickler, sondern auch jeder mit ein wenig technischer Sachkenntnis Veränderungen vornehmen kann. Eine Alternative wäre dabei die binäre Serialisierung, die im Prinzip ähnlich arbeitet, aber kein XML, sondern eine Binärdatei generiert. Diese ist nicht mehr so intuitiv zu verstehen.

Die „Sicherung“ von Dingen wie z.B. Savegames ist ein seit jeher kontrovers diskutiertes Thema. Meine persönliche Meinung ist (mittlerweile), dass es sich in den seltensten Fällen lohnt, viel Aufwand in Schutzmaßnahmen zu stecken. Insbesondere als kleines Team oder Einzelentwickler sollte man seine Schaffenskraft statt dessen lieber auf die Verbesserung der eigentlichen Spielinhalte konzentrieren, denn:

• PlayerPrefs sind genauso (wenn nicht sogar noch einfacher) zu manipulieren wie XML-Dateien, sie liegen nur an anderer Stelle.
• Binärformate können ebenso manipuliert werden, es erfordert nur mehr Sachkenntnis. Nicht ohne Grund gibt es seit es Spiele gibt auch Trainer und Cheat-Tools, die genau das machen. Einige dieser Tools greifen sogar auf den Arbeitsspeicher zu, so dass es egal ist, wie/wo das Savegame gespeichert wird.
• Anti-Cheats sind meiner Meinung sowieso nur bei Multiplayer oder irgend einer Form von Wettbewerb zwischen Spielern (z.B. Highscores) relevant und dann eigentlich nur durch Integration von Server-Komponenten absicherbar. Wenn ein Single-Player auf seinem Gerät durch Verändern des Savegames schummeln will – soll er doch. Warum ist das ein Problem – er betrügt nur sich selbst. 🙂
• Man kann Verschlüsselungen einsetzen, um die Lesbarkeit der Datei zu erschweren, aber auch das ist nicht vollkommen sicher, insbesondere da C#-Programme leicht zurück zu kompilieren und die Logik somit zu analysieren und replizieren ist. (Davon abgesehen kann es sein, dass man beim Einsatz von Verschlüsselungstechnik gegen die Exportregelungen der USA verstößt und damit das Produkt für amerikanische Plattformen wie Steam oder Google Play Store disqualifiziert.)
• … und sicher noch vieles mehr.

Zusammengefasst

Wir verwenden im Kurs XML, gerade weil es durch seine Lesbarkeit für Menschen sehr einfach manuell zu überprüfen ist und dabei eine große Flexibilität bietet. Zusätzlichen Aufwand durch Umsetzung der Objektserialisierung hat man nur am Anfang, später dreht es sich um und die Speicherung über PlayerPrefs wäre unter Umständen sogar sehr viel aufwändiger.