WEBVTT
00:00:00.083 --> 00:00:13.230
33C3 Vorspannmusik
00:00:13.230 --> 00:00:19.090
Herald: Ich habe vorhin erzählt, dass
Snowden uns heute zugeschaltet wurde und
00:00:19.090 --> 00:00:29.810
er hat uns aufgerufen, etwas zu tun. Heute
hören wir hier einen Talk, und zwar „build
00:00:29.810 --> 00:00:37.350
your own NSA“ – „baue deine eigene NSA“.
Geheimdienste sammeln Daten, aber sie sind
00:00:37.350 --> 00:00:42.059
nicht die Einzigen. Es gibt auch die so
genannten Datenkraken – an wen denken wir
00:00:42.059 --> 00:00:48.729
da alle? An Google, an Facebook. Wer hier
hat einen Google-Account, Hände hoch,
00:00:48.729 --> 00:01:01.199
traut euch! Des sind ganz schön viele. Wer
hat einen Facebook-Account? Es sind
00:01:01.199 --> 00:01:07.320
allerdings nicht nur die großen Firmen wie
Facebook oder Google, die Daten sammeln.
00:01:07.320 --> 00:01:11.680
Es sind auch die kleineren Firmen oder
unbekannte, wo wir die Namen noch nie
00:01:11.680 --> 00:01:15.480
gehört haben und Leute, wo wir es nicht
erwarten, wie zum Beispiel ich auf der
00:01:15.480 --> 00:01:19.390
Bühne. Ich weiß jetzt wer einen Google-
und wer einen Facebook-Account bei euch
00:01:19.390 --> 00:01:22.450
hat. Vielen Dank für die Info.
00:01:22.450 --> 00:01:25.680
Diese Firmen, oder auch ich,
könnte jetzt hingehen,
00:01:25.680 --> 00:01:32.150
diese Daten tauschen oder einfach
an die Leute die zahlen, verkaufen.
00:01:32.150 --> 00:01:37.390
Mein kleines Experiment hier war
ziemlich lächerlich und natürlich banal,
00:01:37.390 --> 00:01:43.710
aber Svea Eckert und Andreas
Dewes haben ein größeres
00:01:43.710 --> 00:01:50.430
Experiment gemacht mit einfachen Techniken
des Social Engineerings und rausgefunden,
00:01:50.430 --> 00:01:55.150
was für Daten gesammelt werden können.
In diesem Talk werden sie uns nicht nur
00:01:55.150 --> 00:02:00.510
erzählen, wer, warum und wie Daten sammelt
sondern ob es auch noch eine Möglichkeit
00:02:00.510 --> 00:02:07.640
gibt, unsere Privatsphäre zu schützen.
Andreas ist Data Scientist und entwickelt
00:02:07.640 --> 00:02:14.909
Technologien, damit wir Wissen aus
Daten extrahieren können. Svea ist
00:02:14.909 --> 00:02:20.710
freiberufliche Journalistin und
recherchiert IT-Themen und berichtet
00:02:20.710 --> 00:02:24.510
darüber für die Tagesschau und die
Tagesthemen. Sie hat auch mitgewirkt bei
00:02:24.510 --> 00:02:32.260
Dokumentationen zu Themen wie Wikileaks,
Facebook und dem NSA-Skandal, wo gerade
00:02:32.260 --> 00:02:36.569
Edward Snowden einen großen Teil
eingenommen hat. Ich freue mich herzlich,
00:02:36.569 --> 00:02:42.349
die beiden hier zu begrüßen und bitte euch
jetzt um einen ganz, ganz lauten Applaus
00:02:42.349 --> 00:02:45.189
für die beiden und wünsche
euch allen viel Spaß.
00:02:45.189 --> 00:02:49.970
Applaus
00:02:49.970 --> 00:02:57.090
Svea Eckert: Danke.
Andreas Dewes: Ja, hallo zusammen, also
00:02:57.090 --> 00:03:01.580
wir freuen uns natürlich, dass wir hier
sein dürfen heute, ich hab wie gesagt die
00:03:01.580 --> 00:03:04.689
Datenanalyse für die Recherche
hier gemacht und darf mich daher
00:03:04.689 --> 00:03:07.519
erstmal entspannen jetzt und
übergebe dann das Wort an Svea.
00:03:07.519 --> 00:03:12.859
S: Ja ich bin Svea Eckart, arbeite für den
NDR, beziehungsweise die ARD, und wir haben
00:03:12.859 --> 00:03:16.469
’ne große Recherche gemacht, die ging
über den ganzen Sommer und mündete in
00:03:16.469 --> 00:03:20.239
der relativ aufsehenerregenden
Berichterstattung Anfang November unter
00:03:20.239 --> 00:03:26.759
dem Hashtag #NacktImNetz – der Eine oder
Andere hat vielleicht dazu sogar was
00:03:26.759 --> 00:03:34.059
gesehen. Was wir wissen: Also: Wir wissen,
dass, wenn wir uns im Netz bewegen dass
00:03:34.059 --> 00:03:40.109
Firmen das mitbekommen. Dass Firmen unser
Verhalten aufzeichnen und zumindest ein
00:03:40.109 --> 00:03:45.700
Stück weit sind da verschiedene Parteien
beteiligt, die sehen, auf welcher Webseite
00:03:45.700 --> 00:03:52.370
wir z. B. sind. Also hier jetzt mit einem
kleinen Tool, nur so kurz analysiert, sind
00:03:52.370 --> 00:03:57.620
das jetzt 68 Parteien, die wissen, dass
ich auf dieser Webseite bin und die zum
00:03:57.620 --> 00:04:02.920
Teil auch die Möglichkeit haben, mich
durchs Netz zu verfolgen. Ich denke, jeder
00:04:02.920 --> 00:04:10.430
hier im Publikum weiß das und – also das
ist bekannt. Trotzdem stört es die
00:04:10.430 --> 00:04:14.980
Allerwenigsten Also die allermeisten
Internetnutzer sagen „Ich habe doch nichts
00:04:14.980 --> 00:04:19.700
zu verbergen“ „Da wird schon nichts böses
damit passieren, die machen ja nichts
00:04:19.700 --> 00:04:24.420
mit meinen Daten, is ja sowieso nur für
Werbezwecke“ Und wenn man mal in der
00:04:24.420 --> 00:04:31.170
Industrie nachfragt, dann ist die Aussage
„Also diese Daten werden total gut
00:04:31.170 --> 00:04:35.590
anonymisiert“ „Da stecken wir ganz,
ganz großen Aufwand rein“ „Und
00:04:35.590 --> 00:04:44.569
verkaufen? Das macht niemand!“ „Sowas
würde niemand tun“ Wirklich? Das
00:04:44.569 --> 00:04:50.310
wollten wir genauer wissen: Wie komme
ich an solche Daten? Ich gründe eine
00:04:50.310 --> 00:04:56.639
Firma. Ich habe also im Juli eine
Webseite aufgesetzt – das ist relativ
00:04:56.639 --> 00:05:03.979
trivial. Content Management System, paar
schöne Fotos, Stockphotos und ein
00:05:03.979 --> 00:05:09.360
bisschen Marketing-Sprech. Meine Firma
„Meez Technology“, die Vereinigung von
00:05:09.360 --> 00:05:18.340
Technologie und Kreativität, macht
Data-Driven-Consulting und bot Kunden an,
00:05:18.340 --> 00:05:22.500
Customized-Campaigns zu machen.
Was brauchen wir dafür? Ganz viele
00:05:22.500 --> 00:05:27.869
Nutzer-Daten. Und diese Nutzer-Daten, an
die wollte ich gelangen. Da brauchte ich
00:05:27.869 --> 00:05:34.290
eine tatkräftige Mitarbeiterin, hier ist
sie. Ich habe sie mitgebracht: Anna.
00:05:34.290 --> 00:05:42.479
“Hello, Anna Rosenberg speaking! Hello,
hello?” Anna Rosenberg arbeitet also für
00:05:42.479 --> 00:05:46.720
Meez Technology, sitzt in Tel Aviv,
00:05:46.720 --> 00:05:50.050
spricht kein Wort Hebräisch,
konnte ich mir dann
00:05:50.050 --> 00:05:53.160
nicht aneignen für die Recherche,
war aber nicht schlimm,
00:05:53.160 --> 00:05:56.160
hat auch niemand nachgefragt
00:05:56.160 --> 00:05:59.250
und ich hatte Tel Aviv ausgesucht,
obwohl ich die Stadt eigentlich
00:05:59.250 --> 00:06:02.730
gar nicht kenne, aber ich hatte
Tel Aviv ausgesucht, weil mir
00:06:02.730 --> 00:06:05.720
jemand sagte, Israel sei
ziemlich gut für Daten,
00:06:05.720 --> 00:06:09.960
da wär man nicht so spitzfindig und ich
sollte ja kein deutsches Unternehmen
00:06:09.960 --> 00:06:14.430
gründen sonst würde ich gar nichts
bekommen. Also habe ich Meez Technology in
00:06:14.430 --> 00:06:19.750
Israel angesiedelt und Anna Rosenberg
hat sich auf Telefon-Jagd gemacht.
00:06:19.750 --> 00:06:24.189
Das waren die Firmen, die in
Frage kamen. Die Firmen, die
00:06:24.189 --> 00:06:30.249
von uns Internetnutzern Daten
sammeln, die Daten verarbeiten.
00:06:30.249 --> 00:06:36.209
Meine Frage an diese Firmen war,
ob sie mir als junges, aufstrebendes
00:06:36.209 --> 00:06:41.269
Startup ihre Daten verkaufen würden.
Oder viel eher noch, ob sie mir ein
00:06:41.269 --> 00:06:45.550
kostenloses Sample geben würden,
weil ohne ein kostenloses Sample könnte
00:06:45.550 --> 00:06:50.430
ich die Qualität der Daten gar nicht
beurteilen. Ich habe ziemlich viele von
00:06:50.430 --> 00:06:55.240
diesen Firmen angerufen, angeschrieben,
deren Webseiten mir angeschaut. Ihr seht
00:06:55.240 --> 00:07:00.810
dass es ein gigantisches Universum ist und
es sind noch längst nicht alle. Besonders
00:07:00.810 --> 00:07:07.300
interessant sind diese Firmen hier. Die
machen sozusagen, die analysieren den
00:07:07.300 --> 00:07:13.710
Internetmarkt, reichern Daten an, das sind
so ziemlich wichtige Player in diesem
00:07:13.710 --> 00:07:16.429
ganzen Spiel. Weil um den Internetmarkt
zu analysieren,
00:07:16.429 --> 00:07:19.429
brauchen die sehr viele Daten.
00:07:19.429 --> 00:07:22.789
Und, Ja, der eine oder andere war dann
auch tatsächlich bereit,
00:07:22.789 --> 00:07:27.139
mir ein kostenloses Sample
zur Verfügung zu stellen,
00:07:27.139 --> 00:07:29.579
damit ich die Güte, die Qualität
seiner Daten
00:07:29.579 --> 00:07:37.220
einordnen konnte. Also ein kostenloses
Sample. Dieses Sample kam dann auch. Also
00:07:37.220 --> 00:07:42.379
eines ist besonders groß, deswegen ist es
auch das, worüber wir dann sprechen.
00:07:42.379 --> 00:07:48.599
Was war da drin? Also wir hatten 14
Tage so eine Art quasi Live-Zugriff auf
00:07:48.599 --> 00:07:54.499
Nutzerdaten. Sprich: Nutzerdaten, die sich
immer wieder aktualisiert haben, die immer
00:07:54.499 --> 00:08:02.860
wieder frisch waren. Das waren 3 Millionen
deutsche Nutzer in diesem Datensatz und
00:08:02.860 --> 00:08:08.650
das waren sozusagen die
Klickstream-Daten von einem Monat.
00:08:08.650 --> 00:08:15.590
Das Klick-Stream ist sozusagen das
Buzzword für Browser-History.
00:08:15.590 --> 00:08:20.189
Am Anfang sind wir relativ explorativ
mit diesem Datensatz umgegangen
00:08:20.189 --> 00:08:25.839
haben einfach mal ge-grep-t, und mal
geschaut was passiert denn, wenn wir in
00:08:25.839 --> 00:08:31.360
diesem Datensatz nach @polizei.de suchen.
Ich setz meine Brille wieder ab, weil
00:08:31.360 --> 00:08:39.669
Annas Teil ist nämlich jetzt durch. So,
alles was ge-x-t ist, hab ich gemacht, um
00:08:39.669 --> 00:08:45.860
die Privatsphäre dieser Person zu
schützen. So sieht das dann aus, wenns ein
00:08:45.860 --> 00:08:53.840
bisschen aufbereitet ist. Man sieht jetzt
hier z. B. 01.08.2016 05:17 Uhr: Rechner
00:08:53.840 --> 00:09:01.051
an, Google. Dann wird relativ schnell nach
einem Auto geschaut. 05:30 Uhr: Das habe
00:09:01.051 --> 00:09:03.640
ich jetzt mal offen gelassen, kann man
dann auch alles gleich eingeben.
00:09:03.640 --> 00:09:08.490
Ah, alles klar, er sucht einen Volkswagen
00:09:08.490 --> 00:09:16.000
in der und der Kategorie. Interessant.
Gut, jetzt wollen wir natürlich wissen:
00:09:16.000 --> 00:09:21.480
Was hat der mit der Polizei zu tun?
Was für ein Mensch steckt
00:09:21.480 --> 00:09:28.240
hinter diesen Daten? Und wenn man jetzt
sozusagen sich da mal ein bisschen durch
00:09:28.240 --> 00:09:32.840
scrollt durch diese Daten – ich hab das
jetzt als Screen-Video gemacht, damit man
00:09:32.840 --> 00:09:37.730
mal so ein bisschen auch besser die
Dimensionen begreifen kann, wie groß die
00:09:37.730 --> 00:09:43.420
Tiefe dieser Daten ist und wie intensiv
die sind. Man kann also gucken: Was liest
00:09:43.420 --> 00:09:48.900
der, was sucht der und irgendwann ist er
mal auf der Webseite von der deutschen
00:09:48.900 --> 00:09:56.970
Polizeigewerkschaft und auf dem deutschen
Beamtenbund. Könnte ja ein Polizist sein.
00:09:56.970 --> 00:10:00.710
Schauen wir doch mal nach so einem
typischen Wort wie Ermittlungsverfahren
00:10:00.710 --> 00:10:13.420
Ah! Ok. Ein Google-Translate-Link.
Gelächter + Applaus
00:10:13.420 --> 00:10:20.090
Schauen wir doch mal. Schmeißen wir
es mal in den Decoder. Da ist es!
00:10:20.090 --> 00:10:23.220
„Sehr geehrte Damen und Herren,
im Rahmen eines hier bearbeiteten
00:10:23.220 --> 00:10:26.411
Ermittlungsverfahrens wegen
Computerbetrugs“ – Aktenzeichen habe ich
00:10:26.411 --> 00:10:31.311
jetzt rausgenommen – „benötige ich
Bestandsdaten zu folgender IP-Adresse“
00:10:31.311 --> 00:10:37.400
– habe ich rausgenommen – Zeitstempel
Und netterweise hat dieser Nutzer in
00:10:37.400 --> 00:10:42.180
Google-Translate auch seine
E-Mail-Adresse mit übersetzen lassen,
00:10:42.180 --> 00:10:47.560
seinen Vor- und Nachnamen, den Ort und
die Telefonnummer … So.
00:10:47.560 --> 00:10:55.050
Applaus
00:10:55.050 --> 00:11:01.550
Wir können jetzt schauen: Was erfahren wir
über diesen Menschen in diesen Daten?
00:11:01.550 --> 00:11:09.490
Können also noch mal weiter
scrollen durch sein Leben im Netz.
00:11:09.490 --> 00:11:16.380
Und sehen, dass er arbeitet,
also sehen, ungefähr, dass er
00:11:16.380 --> 00:11:21.940
Malware-Submissions macht z. B., dass er
IP-Adressen verfolgt, aber auch, dass er
00:11:21.940 --> 00:11:26.150
SWR hört und natürlich so die
00:11:26.150 --> 00:11:29.150
Peinlichkeiten im Leben
00:11:29.150 --> 00:11:46.860
Lachen - Applaus
00:11:46.860 --> 00:11:51.740
Sind da natürlich auch drin.
00:11:51.740 --> 00:11:54.740
Jetzt haben wir nur mal nach
@polizei.de gesucht.
00:11:54.740 --> 00:11:58.780
Was wäre, wenn wir mal hier gucken?
00:11:58.780 --> 00:11:59.780
Haben wir auch gemacht.
00:11:59.780 --> 00:12:01.780
So sieht dann so eine Abfrage aus.
00:12:01.780 --> 00:12:07.650
Wenn man das so, sag ich mal
so, explorativ einfach macht wie wir das
00:12:07.650 --> 00:12:12.280
gemacht haben. Wichtig ist das, was
zwischen den Anführungszeichen steht.
00:12:12.280 --> 00:12:17.180
Man sagt mit diesem Befehl dem Computer:
Gib mir alles, gib mir jeden Nutzer, der
00:12:17.180 --> 00:12:19.680
jemals diese Webseite besucht hat.
00:12:19.680 --> 00:12:21.850
Und man sieht also, dass auch Leute
00:12:21.850 --> 00:12:22.850
die, ich würde mal sagen,
00:12:22.850 --> 00:12:25.180
sicherheitskritisch sind,
00:12:25.180 --> 00:12:30.450
in diesen Daten drin sind.
00:12:30.450 --> 00:12:31.880
Was passiert nur, wenn man all diese
00:12:31.880 --> 00:12:34.720
Nutzer deanonymisieren würde?
00:12:34.720 --> 00:12:38.650
Könnte man sie denn
alle deanonymisieren?
00:12:39.530 --> 00:12:44.710
Andreas: Ja, wie wir gesehen
haben, ist es im besten Fall etwas
00:12:44.710 --> 00:12:47.880
peinlich, wenn man als Nutzer in solchen
Daten identifiziert wird.
00:12:47.880 --> 00:12:48.880
Schlimmstenfalls kann es auch gefährlich
00:12:48.880 --> 00:12:50.760
sein für die eigene Person.
00:12:50.760 --> 00:12:52.520
Deswegen möchte ich in den nächsten
00:12:52.520 --> 00:12:54.360
15 min ein bisschen darauf eingehen,
00:12:54.360 --> 00:12:56.270
was Deanonymisierung eigentlich heißt,
00:12:56.270 --> 00:12:58.150
wie das funktioniert und was das
00:12:58.150 --> 00:12:59.490
Problem dabei ist.
00:12:59.490 --> 00:13:02.460
Dafür können wir anfangen
mit dem Datensatz.
00:13:02.460 --> 00:13:04.500
Also es gibt immer einen Datensatz
00:13:04.500 --> 00:13:07.740
von anonymisierten Nutzerdaten am Anfang,
00:13:07.740 --> 00:13:09.480
den man analysieren möchte
00:13:09.480 --> 00:13:11.500
und dieser Datensatz enthält
00:13:11.500 --> 00:13:12.500
viele verschiedene Eigenschaften und
00:13:12.500 --> 00:13:15.121
einige von diesen Eigenschaften zumindest
00:13:15.121 --> 00:13:16.121
sind sensitiv, das heißt, sie sind nach
00:13:16.121 --> 00:13:18.900
Datenschutzrecht geschützt und dürfen
00:13:18.900 --> 00:13:22.670
nicht mit einer bestimmten Person
verknüpft werden, weswegen der Datensatz
00:13:22.670 --> 00:13:24.240
ja im Endeffekt auch anonymisiert wurde.
00:13:24.240 --> 00:13:26.970
Und statt einer Zuordnung zu einer
00:13:26.970 --> 00:13:28.580
konkreten Person hat man diesen
00:13:28.580 --> 00:13:30.760
Datensätzen daher einfach beispielsweise
00:13:30.760 --> 00:13:32.030
eine numerische ID oder einen Identifier,
00:13:32.030 --> 00:13:35.030
der keine Rückschlüsse—im Idealfall—auf
00:13:35.030 --> 00:13:37.360
die wirkliche Person, die sich hinter den
00:13:37.360 --> 00:13:39.980
Daten verbirgt, erlaubt.
00:13:39.980 --> 00:13:41.920
Auf der anderen Seite habe ich aber auch
00:13:41.920 --> 00:13:43.750
öffentliche Informationen z. B. aus
00:13:43.750 --> 00:13:45.390
dem Internet oder anderen Quellen,
00:13:45.390 --> 00:13:47.690
die ich mir frei zusammensuchen kann und
00:13:47.690 --> 00:13:49.600
und solche öffentlichen Informationen
00:13:49.600 --> 00:13:51.500
enthalten auch Eigenschaften von Personen
00:13:51.500 --> 00:13:53.860
und enthalten zudem oft den Namen oder
00:13:53.860 --> 00:13:58.350
andere Identifikationsmerkmale der Person,
00:13:58.350 --> 00:14:00.260
die also Rückschlüsse auf die wirkliche
Person zulassen.
00:14:00.260 --> 00:14:03.260
Und Deanonymisierung beinhaltet in diesem
00:14:03.260 --> 00:14:08.150
Sinne eine Suche nach Eigenschaften,
die ich in beiden
00:14:08.150 --> 00:14:13.410
Datensätzen entweder direkt oder indirekt
identifizieren kann und die mir erlauben,
00:14:13.410 --> 00:14:17.530
aufgrund von beispielsweise statistischen
Verfahren oder machine learning die
00:14:17.530 --> 00:14:22.900
möglichen Kandidaten aus dem
anonymisierten Datensatz so weit zu
00:14:22.900 --> 00:14:26.840
reduzieren, dass ich mit entweder
absoluter Sicherheit oder mit relativ
00:14:26.840 --> 00:14:30.420
hoher Wahrscheinlichkeit sagen kann,
dass ein Nutzer, den ich hier in den
00:14:30.420 --> 00:14:33.580
öffentlichen Daten gefunden habe,
dem Nutzer
00:14:33.580 --> 00:14:36.050
in dem anonymisierten Datensatz
entspricht.
00:14:36.060 --> 00:14:40.440
In dem Sinne habe ich diesen
User dann deanonymisiert.
00:14:43.680 --> 00:14:46.180
Wie Svea gesagt hatte, ist der Datensatz,
00:14:46.190 --> 00:14:47.190
den wir bekommen haben, absolut
00:14:47.190 --> 00:14:50.000
unzureichend anonymisiert worden,
00:14:50.000 --> 00:14:54.330
d. h., das war sehr, sehr einfach
möglich, aus den URL-Daten, die wir
00:14:54.330 --> 00:14:58.110
erhalten haben, entsprechende Nutzer
und Personennamen zu extrahieren.
00:14:58.110 --> 00:15:00.800
Im Zweifelsfall hat dafür eine einzige URL
ausgereicht.
00:15:00.800 --> 00:15:02.670
Hier habe ich zwei Beispiele.
00:15:02.670 --> 00:15:05.180
Einmal von Twitter und einmal von XING.
00:15:05.180 --> 00:15:06.680
Das sind also beides URLs,
00:15:06.680 --> 00:15:08.070
die Rückschlüsse
00:15:08.070 --> 00:15:09.700
entweder auf den Nutzernamen
00:15:09.700 --> 00:15:11.180
oder sogar auf den Klarnamen
00:15:11.180 --> 00:15:12.850
und weitere Angaben von
00:15:12.850 --> 00:15:14.630
der Person zulassen.
00:15:14.630 --> 00:15:17.080
Und das, was die Identifikation
hier ermöglicht,
00:15:17.080 --> 00:15:19.670
ist bei der ersten Adresse oben,
00:15:19.670 --> 00:15:22.670
dass diese Analytics-Page nur
– im Normalfall – dem
00:15:22.670 --> 00:15:23.740
eingeloggten Benutzer zur Verfügung steht,
00:15:23.740 --> 00:15:26.380
d.h. wenn ich diese URL in einem Datensatz
00:15:26.380 --> 00:15:28.040
sehe, kann ich mit relativ hoher
00:15:28.040 --> 00:15:30.040
Wahrscheinlichkeit davon ausgehen, dass
00:15:30.040 --> 00:15:31.390
der Nutzername, der hier auftaucht, dem
00:15:31.390 --> 00:15:34.080
Nutzernamen des anonymisierten Nutzers in
00:15:34.080 --> 00:15:35.550
meinem Datensatz entspricht.
00:15:35.550 --> 00:15:38.590
Im zweiten Fall ist es weniger
offensichtlich.
00:15:38.590 --> 00:15:40.590
man kann also nur sehen, dass man hier
00:15:40.590 --> 00:15:42.850
eine öffentliche Profiladresse hat,
00:15:42.850 --> 00:15:44.960
die man auch so im Internet finden kann,
00:15:44.960 --> 00:15:45.960
was aber den Unterschied macht, ist
00:15:45.960 --> 00:15:50.410
dieses spezielle Query, das hinten
dran hängt,
00:15:50.410 --> 00:15:53.110
und das nur in die URL hinzugefügt wird,
00:15:53.110 --> 00:15:54.740
wenn ich als eingeloggter Nutzer,
00:15:54.740 --> 00:15:56.440
auf mein eigenes Profilbild klicke
00:15:56.440 --> 00:15:58.290
d.h. hier ist wieder mit einer hohen
00:15:58.290 --> 00:16:01.300
Wahrscheinlichkeit die Möglichkeit
gegeben, einen Nutzer der in
00:16:01.300 --> 00:16:06.660
den Daten drin ist, eindeutig mit dem
Besitzer dieses Profils zu identifizieren.
00:16:06.660 --> 00:16:10.940
Und in unserm Datensatz haben wir über
100.000 Benutzer auf diese Weise
00:16:10.940 --> 00:16:14.780
identifiziert. Wir haben auch die
beiden Firmen übrigens auf diese
00:16:14.780 --> 00:16:18.700
Sicherheitsprobleme aufmerksam gemacht.
XING hat entsprechend schon Änderungen
00:16:18.700 --> 00:16:23.970
eingeführt und Twitter hält es nicht
für ein Problem in diesem Sinne und
00:16:23.970 --> 00:16:27.911
möchte da keine Änderungen machen
aktuell. Also als erstes Take-Away könnte
00:16:27.911 --> 00:16:31.730
man vielleicht von dem Vortrag auch
mitnehmen, dass man bitte, bitte keine
00:16:31.730 --> 00:16:36.570
persönlich identifizierbaren Informationen
in URLs packt. Wenn irgend möglich.
00:16:38.470 --> 00:16:44.330
Natürlich gibt’s noch etwas
weitergehende Verfahren, um auch
00:16:44.330 --> 00:16:49.440
Datensätze zu deanonymisieren, die etwas
besser anonymisiert wurden.
00:16:49.440 --> 00:16:52.090
Eine schöne Arbeit hierzu ist dieses Paper
00:16:52.090 --> 00:16:53.770
das aus dem Jahr 2007 stammt, und
00:16:53.770 --> 00:16:55.590
wo sich die Forscher
00:16:55.590 --> 00:16:57.360
mit einem Datensatz beschäftigt haben,
00:16:57.360 --> 00:17:00.360
der von Netflix publiziert wurde und
00:17:00.360 --> 00:17:03.199
der also anonymisierte Bewertungsdaten
00:17:03.199 --> 00:17:05.109
von Netflix-Usern enthielt.
00:17:05.109 --> 00:17:08.200
Der Datensatz wurde auf eine
Datenanalyseplattform hochgeladen
00:17:08.200 --> 00:17:10.790
mit dem Ziel, dass andere
Data-Sscientists,
00:17:10.790 --> 00:17:14.360
Datenforscher, sich mit den Daten
auseinandersetzen können und
00:17:14.360 --> 00:17:18.049
auf die Weise bessere Bewertungs-
oder Empfehlungsalgorithmen für neue
00:17:18.049 --> 00:17:24.149
Filme finden können. Und die
Deanonymisierung dieses Datensatzes war in
00:17:24.149 --> 00:17:28.169
diesem Fall möglich ebenfalls durch
die Nutzung von öffentlich verfügbaren
00:17:28.169 --> 00:17:32.730
Informationen – in diesem Fall war das
beispielsweise Bewertungen, die Nutzer auf
00:17:32.730 --> 00:17:38.170
der Plattform IMDB abgegeben haben, wo
also Nutzer auch Filme bewerten können wie
00:17:38.170 --> 00:17:42.450
bei Netflix und wo oft Nutzer-Accounts
oder Konten mit dem wirklichen Namen des
00:17:42.450 --> 00:17:47.600
Benutzers verknüpft sind. Und die
Forscher haben also geschafft, indem sie
00:17:47.600 --> 00:17:51.810
die Bewertung von IMDB herangezogen haben
und diese mit den Bewertungen auf Netflix
00:17:51.810 --> 00:17:57.070
verglichen, die User auf Netflix mit einer
hohen Wahrscheinlichkeit mit den Usern auf
00:17:57.070 --> 00:18:01.400
IMDB zu identifizieren D. h. hier war eine
Deanonymisierung einfach dadurch möglich,
00:18:01.400 --> 00:18:05.151
dass es sehr, sehr viele mögliche
Kombinationen von Filmen gibt und es sehr
00:18:05.151 --> 00:18:09.131
unwahrscheinlich ist, dass zwei Personen
die gleiche Anzahl von Filmen auf die
00:18:09.131 --> 00:18:11.600
gleiche Weise bewertet haben.
00:18:12.660 --> 00:18:15.660
Und diese Technik kann man auch auf
00:18:15.660 --> 00:18:17.980
unseren Datensatz anwenden,
00:18:21.010 --> 00:18:23.950
dieser enthält wie gesagt
ca. 3 Mrd. URLs
00:18:24.240 --> 00:18:27.150
von 9 Mio. Web-Domains und wurde
00:18:27.150 --> 00:18:29.300
von ca. 3 Mio. Usern generiert.
00:18:31.110 --> 00:18:32.650
So. Da die Daten wie gesagt
00:18:32.650 --> 00:18:34.690
unzureichend anonymisiert wurden, haben
00:18:34.690 --> 00:18:35.690
wir für die weitere Analyse
00:18:35.690 --> 00:18:37.400
einfach mal angenommen,
00:18:37.400 --> 00:18:41.161
dass der Anbieter wirklich ein Interesse
daran hätte die Anonymisierung korrekt
00:18:41.161 --> 00:18:45.270
oder möglichst gut durchzuführen und
dementsprechend sämtliche Informationen
00:18:45.270 --> 00:18:48.140
außer der Domain und der Nutzer-ID aus
dem Datensatz entfernt
00:18:48.140 --> 00:18:50.390
d.h. wir haben alle Informationen
weggeworfen,
00:18:50.390 --> 00:18:53.450
bis auf den Fakt:
Hat dieser Nutzer, diese Domain in
00:18:53.450 --> 00:18:55.240
dem Zeitraum besucht?
00:18:55.240 --> 00:18:56.470
Ja oder nein?
00:18:56.700 --> 00:18:58.670
So - Also man könnte annehmen, dass diese
00:18:58.670 --> 00:19:01.530
starke Form der Anonymisierung doch
ausreichend sein sollte,
00:19:01.530 --> 00:19:03.230
um die Nutzer davor zu schützen,
00:19:03.230 --> 00:19:04.910
wieder deanonymisiert zu werden.
00:19:05.170 --> 00:19:07.070
Wir haben weiterhin auch eine Auswahl
00:19:07.070 --> 00:19:09.010
getroffen von 1 Mio. Nutzern,
00:19:09.010 --> 00:19:11.710
von denen wir über 10 Datenpunkte haben,
00:19:11.710 --> 00:19:15.230
weil das die Analyse für die weiteren
Schritte vereinfacht und für Nutzer, die
00:19:15.230 --> 00:19:20.710
relativ wenige Datenpunkte haben, auch die
meisten Techniken nicht anwendbar sind.
00:19:21.460 --> 00:19:22.250
So.
00:19:22.250 --> 00:19:23.920
Wenn man sich jetzt die Verteilung
00:19:23.920 --> 00:19:25.816
der Häufigkeiten der Domains
00:19:25.816 --> 00:19:27.303
in dem Datensatz anschaut,
00:19:27.303 --> 00:19:28.743
Also hier auf der X-Achse ist
00:19:28.743 --> 00:19:30.330
immer der Popularitätsrang einer
00:19:30.330 --> 00:19:32.140
entsprechenden Domain aufgetragen
00:19:32.140 --> 00:19:34.500
d. h. je
weiter links die Domain hier auftaucht,
00:19:34.500 --> 00:19:35.500
um so populärer ist sie.
00:19:35.500 --> 00:19:39.210
Man hat hier bspw . Google, Facebook und
die anderen üblichen Kandidaten
00:19:39.210 --> 00:19:42.760
und auf der Y-Achse ist die
Anzahl der URLs aufgetragen,
00:19:42.760 --> 00:19:45.840
die von dieser entsprechenden Domain
in dem Datensatz stammen.
00:19:45.840 --> 00:19:48.120
Und wie man sieht: wenn man die
00:19:48.120 --> 00:19:54.790
100 populärsten Domains nimmt, sind die
schon bereits verantwortlich für mehr als
00:19:54.790 --> 00:19:59.580
99% der gesamten Daten in unserem
Datensatz. D. h. die meisten Seitenbesuche
00:19:59.580 --> 00:20:05.290
finden auf den Top 100 Domains dieser
Liste statt. Und wie man sieht, fällt die
00:20:05.290 --> 00:20:09.240
Verteilung danach relativ schnell ab. Also
es gibt eine Menge Domains, die nur ein
00:20:09.240 --> 00:20:13.050
paar hundert mal oder sogar nur 10 oder
ein einziges mal von einem Nutzer besucht
00:20:13.050 --> 00:20:16.420
wurden. Das hilft uns bei der
Anonymisierung, weil wir gleichzeitig die
00:20:16.420 --> 00:20:20.241
Möglichkeit haben, über diese populären
Domains, die fast jeder User besucht hat
00:20:20.241 --> 00:20:23.460
oder von denen jeder User fast eine
besucht hat,
00:20:23.460 --> 00:20:25.680
eine entsprechende Auswahl zu treffen und
00:20:25.680 --> 00:20:29.740
unsere Kombinatorik darauf anzuwenden aber
wir auch gleichzeitig Long-Tail-Domains
00:20:29.740 --> 00:20:33.710
haben, die also nur von wenigen Nutzern
besucht wurden und die entsprechend sehr
00:20:33.710 --> 00:20:37.300
gut sich eignen, um einzelne Nutzer
wirklich mit wenigen Datenpunkten wieder
00:20:37.300 --> 00:20:38.820
zu identifizieren.
00:20:40.040 --> 00:20:43.320
So, den ersten Schritt, den wir machen
müssen, um unsere
00:20:43.320 --> 00:20:48.180
Deanonymisierung vorzunehmen, ist das
Katalogisieren der Nutzer. Dafür legen wir
00:20:48.180 --> 00:20:53.620
eine einfache Tabelle an, wo wir in jede
Zeile entsprechend einen Eintrag für
00:20:53.620 --> 00:20:58.230
einen Nutzer machen und in jede Spalte
einen Eintrag für eine Domain anlegen und
00:20:58.230 --> 00:21:04.060
jedes Element hier ist entweder Null oder
Eins und ist genau Eins dann, wenn der
00:21:04.060 --> 00:21:08.120
entsprechende Nutzer die entsprechende
Domain besucht hat, d. h., das ergibt eine
00:21:08.120 --> 00:21:12.590
Matrix mit 9 Mio. Einträgen für die
Domains und 1 Mio. Einträgen für die
00:21:12.590 --> 00:21:16.840
User, wobei die meisten Elemente dieser
Matrix Null sind. Und so eine Matrix lässt
00:21:16.840 --> 00:21:20.770
sich sehr effizient auch repräsentieren
und kann leicht verarbeitet werden für
00:21:20.770 --> 00:21:22.380
die weiteren Schritte.
00:21:22.380 --> 00:21:25.560
So der Algorithmus,den wir einsetzen
zu der Deanonymisierung ist
00:21:25.560 --> 00:21:26.960
wirklich sehr, sehr einfach.
00:21:26.960 --> 00:21:30.040
Wir generieren im 1. Schritt die Matrix M
00:21:30.040 --> 00:21:31.480
die ich gerade gezeigt habe,
00:21:31.480 --> 00:21:34.290
generieren dann weiterhin einen Vektor V
00:21:34.290 --> 00:21:36.471
und in diesen Vektor packen wir
alle Domains,
00:21:36.471 --> 00:21:38.771
die wir aus anderen Informationsquellen,
00:21:38.771 --> 00:21:43.840
also aus unserer öffentlichen Information
gewonnen haben und die wir vergleichen
00:21:43.840 --> 00:21:47.700
wollen mit den Nutzern, die sich in in dem
Datensatz befinden d.h. für jede Domain
00:21:47.700 --> 00:21:51.470
die wir irgendwo gesehen haben, würden wir
eine 1 in diesen Vektor schreiben und
00:21:51.470 --> 00:21:55.380
würden dann entsprechend den Vektor
nehmen und mit der Matrix multiplizieren.
00:21:55.380 --> 00:22:01.070
Das Ergebnis enthält dann wieder für
jeden Nutzer eine einzige Zahl und in dem
00:22:01.070 --> 00:22:05.040
wir den Maximalwert dieser Zahl nehmen
können den Nutzer finden der in unserem
00:22:05.040 --> 00:22:08.570
Datensatz die beste Übereinstimmung hat
mit den Domain, mit denen wir ihn
00:22:08.570 --> 00:22:09.570
vergleichen wollen.
Also wirklich ein sehr,
00:22:09.570 --> 00:22:11.500
sehr einfaches Verfahren, das allerdings
00:22:11.500 --> 00:22:14.230
sehr robust und auch sehr,
wie man sehen wird,
00:22:14.230 --> 00:22:16.270
effektiv ist für die Deanonymisierung
00:22:16.270 --> 00:22:18.700
So, das ist natürlich alles sehr abstrakt
00:22:18.700 --> 00:22:21.740
deswegen habe ich hier mal ein Beispiel
von einem Nutzer,
00:22:21.740 --> 00:22:24.460
den wir zufällig ausgewählt haben
aus unserem Datensatz
00:22:24.460 --> 00:22:27.680
und wir gehen jetzt einfach mal
durch die einzelnen Punkte durch.
00:22:27.680 --> 00:22:29.330
Also hier würden wir jedes mal in
jedem Schritt
00:22:29.330 --> 00:22:31.440
eine Domain hinzunehmen, die der Benutzer
00:22:31.440 --> 00:22:34.400
entsprechend besucht hat und dann schauen,
00:22:34.400 --> 00:22:37.570
um wie viele Nutzer verringert das die
00:22:37.570 --> 00:22:41.950
möglichen Nutzer in unserem Datensatz, die
diese Domains besucht haben könnten.
00:22:41.950 --> 00:22:43.980
Wie wir sehen wir fangen hier links mit
00:22:43.980 --> 00:22:46.390
ca. 1,1 mio. Nutzern an, dann nehmen wir
00:22:46.390 --> 00:22:48.180
unsere 1. Domain das ist gog.com
00:22:48.180 --> 00:22:49.180
Das ist eine Gaming-Webseite und
00:22:49.180 --> 00:22:50.840
da sehen wir schon
00:22:50.840 --> 00:22:54.100
haben wir eine extreme Reduktion
in der Anzahl der möglichen Nutzer
00:22:54.100 --> 00:22:55.450
in dem Datensatz.
00:22:55.450 --> 00:22:58.570
Weil jetzt nur noch 15.000 Nutzer
dieser Domain drin sind, die
00:22:58.570 --> 00:23:02.980
wirklich diese Domain besucht haben und
die der potentielle Nutzer sein könnten.
00:23:02.980 --> 00:23:07.480
Wie wir auch sehen ist dieser Nutzer
Telekom-Kunde d.h. er hat auch diese
00:23:07.480 --> 00:23:11.760
kundencenter.telekom.de Domain besucht.
Was nochmal die Anzahl der möglichen
00:23:11.760 --> 00:23:13.830
Nutzer in dem Datensatz extrem reduziert.
00:23:13.830 --> 00:23:16.410
In diesem Falle auf 367.
00:23:16.410 --> 00:23:18.120
Er ist auch Sparda-Bank-Kunde,
00:23:18.120 --> 00:23:21.690
weswegen wir auch diese
banking.sparda.de hinzunehmen können, was
00:23:21.690 --> 00:23:26.210
nochmal die Anzahl auf 11 reduziert und
das finale Stück des Puzzles, das wir noch
00:23:26.210 --> 00:23:27.210
benötigen ist hier die Information, dass
00:23:27.210 --> 00:23:29.930
der Nutzer handelsblatt.com unterwegs war,
00:23:29.930 --> 00:23:32.280
was dann nur noch einen einzigen Nutzer
00:23:32.280 --> 00:23:35.030
ergibt in unserem Datensatz, der mit
00:23:35.030 --> 00:23:36.510
diesen Daten kompatibel ist.
00:23:36.510 --> 00:23:40.530
D.h. hätten wir diese vier Informationen
aus öffentlichen Quellen extrahiert,
00:23:40.530 --> 00:23:44.230
könnten wir schon mit Sicherheit
sagen, welcher Nutzer in unserem
00:23:44.230 --> 00:23:48.050
Datensatz hier entsprechend der richtige
Nutzer ist.
00:23:50.560 --> 00:23:52.370
So jetzt ist natürlich die Frage:
00:23:52.370 --> 00:23:55.700
Wie gut funktioniert das Verfahren
in Abhängigkeit auch davon, wieviele
00:23:55.700 --> 00:23:57.970
Informationen ich denn überwachen kann
von dem Nutzer.
00:23:57.970 --> 00:23:59.183
Wir haben ja gesehen,
00:23:59.183 --> 00:24:03.020
das wir in unserem Datensatz eigentlich
den Nutzer komplett überwachen können,
00:24:03.020 --> 00:24:06.900
D.h. wir können jede URL sehn, die der
Nutzer mit seinem Browser aufgerufen hat
00:24:06.900 --> 00:24:10.770
Aber viele Trecker sehen ja im Prinzip nur
einige hundert oder vielleicht einige
00:24:10.770 --> 00:24:14.800
tausend oder zehntausend Domains, auf den
entsprechende Skripte installiert sind.
00:24:16.630 --> 00:24:21.740
Was ich deswegen hier zeige, ist die
Effektivität dieser Methode in
00:24:21.740 --> 00:24:24.770
Abhängigkeit der Anzahl der Domain die
ich zur Verfügung habe.
00:24:24.770 --> 00:24:26.860
Wir fangen also an hier links,
00:24:26.860 --> 00:24:30.400
wo nur die Top 50 Domains in
unserem Datensatz zur Verfügung hätten
00:24:30.400 --> 00:24:35.309
und schauen uns an, wenn wir zufälliges
Sample von Usern, in diesem Fall 200,
00:24:35.309 --> 00:24:39.380
versuchen zu deanonymisieren,
wo befindet sich denn der korrekte User
00:24:39.380 --> 00:24:42.430
unter all den Nutzern, die wir in dem
Datensatz haben.
00:24:42.430 --> 00:24:44.340
Man sieht hier für 50 Domains ist das
00:24:44.340 --> 00:24:46.260
ungefähr 160.
00:24:46.260 --> 00:24:49.050
D.h. es gibt 160 andere Nutzer
im Schnitt, die eine höhere
00:24:49.050 --> 00:24:52.640
Wahrscheinlichkeit haben, mit den Daten
übereinzustimmen, als der wirklich
00:24:52.640 --> 00:24:53.590
gesuchte Nutzer.
00:24:53.590 --> 00:24:56.590
So, wenn wir jetzt die Anzahl der Domains
allerdings erhöhen:
00:24:56.590 --> 00:24:59.810
also wir können z.B. auf 100 gehen, sehen
wir, das der Wert schon rapide abfällt.
00:24:59.810 --> 00:25:03.470
D.h. hier habe ich schon die Anzahl der
möglichen Nutzer, die zu einem wirklichen
00:25:03.470 --> 00:25:06.220
Nutzer gehören könnten extrem reduziert.
00:25:06.220 --> 00:25:07.830
Auf ungefähr 25
00:25:07.830 --> 00:25:09.730
und wenn ich die Anzahl der Domains
00:25:09.730 --> 00:25:11.920
entsprechend erhöhe auf
200 oder 300 sogar,
00:25:11.920 --> 00:25:14.080
bin ich sehr schnell auch in der Lage
00:25:14.080 --> 00:25:16.820
wirklich den Nutzer eindeutig
wieder zu identifizieren .
00:25:16.820 --> 00:25:19.930
Also es gibt keine Fehler,
in diesem Sinne dann, für die
00:25:19.930 --> 00:25:22.930
Identifikation eines bestimmten Nutzers.
00:25:22.930 --> 00:25:27.971
So, das ist natürlich alles graue Theorie
und es stellt sich die Frage:
00:25:27.971 --> 00:25:31.631
Ist es überhaupt möglich, solche
öffentlichen Informationen zu gewinnen
00:25:31.631 --> 00:25:34.320
oder ist das eher unwahrscheinlich,
dass man an solche
00:25:34.320 --> 00:25:36.190
Informationen rankommen würde?
00:25:36.190 --> 00:25:38.950
Deswegen habe ich versucht anhand von
den Daten, die wir haben und anhand von
NOTE Paragraph
00:25:38.950 --> 00:25:43.070
öffentlichen Informationsquellen wirklich
Deanonymisierung durchzuführen, mit den
00:25:43.070 --> 00:25:46.810
Usern, die wir haben.
Und ich zeige jetzt drei Beispiele.
00:25:46.810 --> 00:25:49.620
Das erste beruht auf der Analyse von
Twitter-Daten.
00:25:49.620 --> 00:25:52.620
Da haben wir also einen Nutzer aus
unserem Datensatz
00:25:52.620 --> 00:25:57.540
der einen Twitter-Account hatte zufällig
rausgesucht. Haben uns dann angeschaut,
00:25:57.540 --> 00:26:01.730
welche URLs dieser Nutzer in dem
entsprechenden Zeitraum, über den wir die
00:26:01.730 --> 00:26:06.460
Daten hatten, geteilt hat und haben dann
aus diesen Tweets hier die entsprechenden
00:26:06.460 --> 00:26:10.880
URLs extrahiert, davon wieder Domains
generiert oder extrahiert und diese
00:26:10.880 --> 00:26:15.200
Domains dann mit unserem Algorithmus
genutzt.
00:26:15.200 --> 00:26:18.200
So. Wie wir sehen haben wir für
00:26:18.200 --> 00:26:19.500
diesen einen Nutzer dabei 8 Domains
extrahiert
00:26:19.500 --> 00:26:22.500
über den entsprechenden Zeitraum.
00:26:22.500 --> 00:26:27.220
Also wir haben hier relativ
populäre Domains wie GitHub, Change.org
00:26:27.220 --> 00:26:29.190
aber auch viele Blogs,
00:26:29.190 --> 00:26:31.370
Beispielsweise: rtorp.wordpress.com
00:26:31.370 --> 00:26:33.370
was nur von 129 Nutzern aus dem Datensatz
00:26:33.370 --> 00:26:38.830
besucht wurde und auch andere kleinere
Webseiten.
00:26:38.830 --> 00:26:44.070
Wenn wir jetzt uns anschauen, welche
Nutzer aus unserem Datensatz haben
00:26:44.070 --> 00:26:50.990
mindestens eine dieser Domains besucht, in
dem entsprechenden Zeitraum, und die Nutzer
00:26:50.990 --> 00:26:55.700
gegen die Anzahl der Domains, die sie aus
diesem Satz von Domains besucht haben
00:26:55.700 --> 00:26:58.461
auftragen, bekommen wir diese Grafik hier.
00:26:58.461 --> 00:27:01.001
Also die zeigt die ca. 110.000 Nutzer, die
00:27:01.001 --> 00:27:06.380
min. eine dieser Webseite besucht haben
und zeigt gleichzeitig an: Wieviele von
00:27:06.380 --> 00:27:09.809
den entsprechenden Domains der Nutzer
wirklich besucht hat. Und wir sehen:
00:27:09.809 --> 00:27:13.710
Also, es gibt sehr, sehr viele Nutzer,
die min. eine hiervon besucht haben.
00:27:13.710 --> 00:27:15.220
Wenn wir allerdings hochgehen zu
zwei, drei oder vier davon
00:27:15.220 --> 00:27:18.220
verringert sich die Anzahl sehr schnell.
00:27:18.220 --> 00:27:23.160
Und wir sehen hier, dass wir oben bei 7
einen einzigen Nutzer haben und dabei
00:27:23.160 --> 00:27:27.440
handelt es sich wirklich um den Nutzer, den
wir entsprechend deanonymisieren wollten.
00:27:27.440 --> 00:27:31.350
D.h. hier ist eine Zuordnung mit 100%ger
Sicherheit möglich für diesen Nutzer.
00:27:31.350 --> 00:27:36.240
Wir haben das auch für andere Nutzer
durchgespielt. Wir konnten nicht immer den
00:27:36.240 --> 00:27:39.840
korrekten Nutzer rausfinden. Aber wir
konnten in den meisten Fällen die Anzahl
00:27:39.840 --> 00:27:43.250
möglicher Nutzer auf ca. 10–20
reduzieren.
00:27:47.430 --> 00:27:49.550
Das zweite Beispiel, dass ich jetzt noch
00:27:49.550 --> 00:27:54.999
zeigen möchte, ist anhand von
YouTube-Daten gemacht worden.
00:27:54.999 --> 00:27:59.650
Oft ist es so, dass viele Daten in solchen
Datensätzen wirklich anonymisiert werden,
00:27:59.650 --> 00:28:03.870
aber bestimmte Daten davon ausgenommen
werden, weil es ein starkes Interesse gibt,
00:28:03.870 --> 00:28:05.220
seitens der Unternehmen, diese zu nutzen.
00:28:05.220 --> 00:28:08.220
YouTube-Videos sind ein gutes Beispiel
00:28:08.220 --> 00:28:12.600
dafür, weil Unternehmen bspw. wissen
möchten, welche Videos haben bestimmte
00:28:12.600 --> 00:28:16.830
Nutzer angeschaut, in welcher Kombination,
um daraus für ihr Marketing Erkenntnisse
00:28:16.830 --> 00:28:20.390
abzuleiten. Und man könnte auch meinen,
dass diese Information über öffentliche
00:28:20.390 --> 00:28:23.770
Videos, die eigentlich ja jeder sich
anschauen kann im Internet,
00:28:23.770 --> 00:28:25.110
auch nicht sehr kritisch ist.
00:28:25.110 --> 00:28:28.110
Was wir gemacht haben deswegen,
um zu zeigen, ob das wirklich so ist,
00:28:28.110 --> 00:28:32.320
ist, dass wir wieder aus unserem
Datensatz einen Nutzer extrahiert haben,
00:28:32.320 --> 00:28:37.140
von diesem Nutzer die Favoritenliste der
YouTube-Videos uns besorgt haben, die auch
00:28:37.140 --> 00:28:40.350
öffentlich ist im Normalfall, also man
kann das Einstellen natürlich, das es
00:28:40.350 --> 00:28:43.520
nicht öffentlich ist aber 90% der User
machen das nicht und haben das
00:28:43.520 --> 00:28:46.830
entsprechend dann in der Öffentlichkeit
und haben uns aus dieser Liste per
00:28:46.830 --> 00:28:52.020
YouTube-API automatisiert sämtliche
Video-IDs besorgt. Und mit diesen
00:28:52.020 --> 00:28:55.720
Video-IDs haben wir wieder unseren
Algorithmus gefüttert, diesmal allerdings
00:28:55.720 --> 00:28:59.280
mit den kompletten URL-Daten, da die
00:28:59.280 --> 00:29:01.990
Domains halt nicht die Video-IDs
enthalten.
00:29:01.990 --> 00:29:04.780
Ups... jetzt habe ich falsch
gedrückt ha so... also
00:29:04.780 --> 00:29:07.010
Wie vorher haben wir also
00:29:07.010 --> 00:29:10.890
diese IDs, das sind ungefähr 20 und
haben auf der anderen Seite sämtliche
00:29:10.890 --> 00:29:14.950
Nutzer, die min. 1 von diesen Videos
angeschaut haben. Wie wir sehen können
00:29:14.950 --> 00:29:19.990
sind das in dem Fall ca. 20.000, wobei
wieder eine Menge von den Nutzern sich
00:29:19.990 --> 00:29:25.360
min. 1 angeschaut haben. Aber die Anzahl
der potentiellen Nutzer, die sich mehrere
00:29:25.360 --> 00:29:29.799
angeschaut haben rapide runtergeht. Und
wir sehen hier Bspw. für vier oder fünf
00:29:29.799 --> 00:29:33.270
oder sechs haben wir nur noch eine
Handvoll User und wir haben wieder einen
00:29:33.270 --> 00:29:37.860
Treffer, der hier ganz oben liegt, bei 9
angeschauten Videos und dabei handelt es
00:29:37.860 --> 00:29:42.519
sich wieder um den Nutzer, den wir im
vorherigen Schritt extrahiert haben.
00:29:42.519 --> 00:29:44.440
Wir sehen also, es ist relativ einfach
00:29:44.440 --> 00:29:46.630
anhand von ner kleinen Anzahl von
Datenpunkten,
00:29:46.630 --> 00:29:48.900
selbst aus ner sehr großen Anzahl
von Nutzern,
00:29:48.900 --> 00:29:51.020
in diesem Fall über 1 Mio. Nutzer,
00:29:51.020 --> 00:29:55.100
entsprechend auf einen User
zurückzuschließen. Und man muss dazu
00:29:55.100 --> 00:29:58.231
sagen, dass solche Verfahren, dass
YouTube-Verfahren, sogar besser
00:29:58.231 --> 00:30:02.240
funktioniert hat, als die Anonymisierung
über Twitter. Weil, ich schätze mal, die
00:30:02.240 --> 00:30:05.650
Verteilung der Videos und Anzahl der
Videos auf YouTube noch mal höher ist als
00:30:05.650 --> 00:30:09.260
die Anzahl der entsprechenden Domains die
wir zur Verfügung haben. D.h. eine
00:30:09.260 --> 00:30:12.950
YouTube-Video-ID ist in dem Sinne sogar
ein stärkeres Deanonymisierungs-Signal
00:30:12.950 --> 00:30:15.810
als die entsprechende Domain aus dem
Twitter-Feed.
00:30:15.810 --> 00:30:17.820
So, dass letzte Beispiel:
00:30:17.820 --> 00:30:25.760
dass ich zeigen möchte - basiert auf der
Analyse von Geodaten. Dafür haben wir uns
00:30:25.760 --> 00:30:30.640
angeschaut, wie wir aus unserem Datensatz
Geodaten extrahieren oder Koordinaten
00:30:30.640 --> 00:30:34.360
extrahieren können. Und wir haben
rausgefunden, dass es relativ einfach
00:30:34.360 --> 00:30:39.070
über Google-Maps-URLs geht. Die also wenn
man sich einen bestimmten Bereich anschaut
00:30:39.070 --> 00:30:44.490
meisten oben in der URL die geographischen
Koordinaten enthalten. D.h. wir konnten
00:30:44.490 --> 00:30:48.930
aus unserem Datensatz einige Mio. von
diesen Koordinatenpaaren extrahieren und
00:30:48.930 --> 00:30:52.280
die auch nach entsprechenden Nutzer
gruppieren und können damit eine
00:30:52.280 --> 00:30:57.990
komplette Karte von der Nutzeraktivität
anfertigen. Also wir sehen z.B. welche
00:30:57.990 --> 00:31:01.680
Kartenausschnitte sich User angeschaut
haben. Wenn sie z.B. nach Urlaubszielen
00:31:01.680 --> 00:31:06.290
geschaut haben, vielleicht nach ihrem
Arbeitsort, nach einem Weg, nach einer
00:31:06.290 --> 00:31:09.670
Wegbeschreibung. Und können diese
Information also auch Nutzergenau
00:31:09.670 --> 00:31:14.581
verarbeiten. Und Geodaten sind besonders
interessant hierfür, weil es sehr viel
00:31:14.581 --> 00:31:20.960
schwieriger ist, diese selbst zu ändern,
da es ja relativ einfach ist seine
00:31:20.960 --> 00:31:24.910
Surfgewohnheiten oder Videogewohnheiten im
Zweifelsfall anzupassen aber es relativ
00:31:24.910 --> 00:31:29.710
schwierig ist, bspw. die Arbeitsstelle
oder den Wohnort oder sämtliche vertraute
00:31:29.710 --> 00:31:33.549
Orte zu wechseln. D.h. diese Information
sehr, in diesem Sinne sticky, in dem
00:31:33.549 --> 00:31:38.250
Sinne, dass sie dem User über lange Zeit
auch zuordenbar sind normalerweise. Und
00:31:38.250 --> 00:31:41.900
wir können auch wieder aus verschiedenen
öffentlichen Quellen Informationen
00:31:41.900 --> 00:31:44.500
extrahieren. Bspw. aus Google-Maps oder
00:31:44.500 --> 00:31:47.370
auch über Flickr, wo auch viele Fotos
geocodiert sind und
00:31:47.370 --> 00:31:50.860
können dann über diese Information
ein Matching mit den Daten, die wir in
00:31:50.860 --> 00:31:52.670
unserem Datensatz haben, durchführen.
00:31:52.670 --> 00:31:55.870
Und hier ist es auch so, dass wir
über eine relativ kleine Anzahl
00:31:55.870 --> 00:31:59.060
also weniger als 10 Datenp unkte im
Idealfall, ähm Normalfall,
00:31:59.060 --> 00:32:03.980
den einzelnen Nutzer aus dem Datensatz
extrahieren und identifizieren können.
00:32:07.230 --> 00:32:08.809
So, eine Frage die ich oft gestellt
bekomme, ist:
00:32:08.809 --> 00:32:11.809
Kann ich mich verstecken in meinen Daten?
00:32:11.809 --> 00:32:15.970
Also, ist es möglich dadurch,
dass ich mich unvorhergesehen verhalte,
00:32:15.970 --> 00:32:19.930
dass ich vielleicht Webseiten öffne,
die ich normalerweise nie anschauen
00:32:19.930 --> 00:32:23.870
würde, dass ich den Algorithmus verwirre
und dementsprechend nicht in den Daten
00:32:23.870 --> 00:32:30.330
auftauche werde? Da muss leider sagen,
dass funktioniert vermutlich nicht, aus
00:32:30.330 --> 00:32:36.760
dem einfachen Grund, dass wir ja ein
Matching machen über die Zuordnung von
00:32:36.760 --> 00:32:40.580
Eigenschaften, die entweder erfüllt oder
nicht erfüllt sind und ich als einzelner
00:32:40.580 --> 00:32:44.380
Nutzer ja nur die Möglichkeit habe,
zusätzliche Datenpunkte zu meinem
00:32:44.380 --> 00:32:48.080
persönlichen Vektor hinzuzufügen aber
meistens keine Datenpunkte von diesem
00:32:48.080 --> 00:32:52.640
entfernen kann. D.h. wenn ich hier schon
mit meinen bestehenden Datenpunkten zu
00:32:52.640 --> 00:32:56.111
100% identifiziert bin, kann ich
eigentlich so viele Punkte hinzufügen wie
00:32:56.111 --> 00:33:01.720
ich möchte und werde trotzdem nicht im
normalfall von dem Algorithmus mit einem
00:33:01.720 --> 00:33:06.170
anderen User verwechselt werden können.
D.h. diese Verfahren ist in dem Sinne sehr
00:33:06.170 --> 00:33:12.690
robust gegenüber der Perturbation oder
der Änderung der Daten durch den Nutzer.
00:33:12.690 --> 00:33:18.550
Als kleines Zwischenfazit kann man also
sagen, dass diese Art von Datensätzen die
00:33:18.550 --> 00:33:22.390
sehr viele Dimensionen und sehr viele
Eigenschaften enthalten extrem schwierig
00:33:22.390 --> 00:33:27.200
zu anonymisieren sind und auch bei
entsprechender Absicht man nicht immer
00:33:27.200 --> 00:33:29.650
sicher sein kann, dass
Anonymisierungsmaßnahmen,
00:33:29.650 --> 00:33:31.150
die man ergreift, wirklich
00:33:31.150 --> 00:33:34.050
ausreichend sind, um sämtliche Nutzer
oder sogar nur einen kleinen Teil
00:33:34.050 --> 00:33:36.330
von Nutzern in dem Datensatz zu schützen.
00:33:36.330 --> 00:33:38.100
Weiterhin ist es auch so, dass heute
00:33:38.100 --> 00:33:41.530
eigentlich immer mehr öffentlich
verfügbare Informationen über Personen
00:33:41.530 --> 00:33:46.410
zur Verfügung stehen, die auch genutzt
werden können, um Daten die anonymisiert
00:33:46.410 --> 00:33:51.040
wurden z.B. vor 10 Jahren oder vor 5
Jahren jetzt mit neuen Datenpunkten in dem
00:33:51.040 --> 00:33:55.030
Sinne besser zu deanonymisieren. D.h. es
wird immer einfacher möglich, auch aus
00:33:55.030 --> 00:33:58.280
bestehenden Datensätzen entsprechende
Nutzerdaten und
00:33:58.280 --> 00:34:02.630
Personen-Identifikationsmerkmale zu
extrahieren. Und wie wir gesehen haben,
00:34:02.630 --> 00:34:06.290
reichen dafür oft eigentlich schon sehr
wenige Datenpunkte aus, um wirklich
00:34:06.290 --> 00:34:10.819
einzelne Nutzer herauszusuchen und
eindeutig zu identifizieren.
00:34:10.819 --> 00:34:17.629
S: Ja was bedeutet das?
Was bedeutet das, wenn man mit seinen
00:34:17.629 --> 00:34:19.589
eigenen Daten konfrontiert wird?
00:34:19.589 --> 00:34:22.830
Also wenn jemand anders einen mit
seinen Daten konfrontiert?
00:34:22.830 --> 00:34:24.700
Also z.B. Ich?
00:34:24.700 --> 00:34:27.530
Wir haben, die Recherche war
für ein politisches Magazin
00:34:27.530 --> 00:34:29.520
und deswegen haben wir vor allem nach
00:34:29.520 --> 00:34:32.330
Politikern geschaut und auch die
Politiker selbst
00:34:32.330 --> 00:34:34.729
oder deren Mitarbeiter gefunden
in diesen Daten.
00:34:34.729 --> 00:34:37.449
Waren zwei Grüne dabei,
drei von der SPD,
00:34:37.449 --> 00:34:39.808
darunter auch Mitarbeiter aus dem
00:34:39.808 --> 00:34:42.808
Büro von Lars Klingbeil,
Netzpolitischer Specher,
00:34:42.808 --> 00:34:50.549
ein Europaparlamentarier und das
zog sich sozusagen bis ins Kanzleramt und
00:34:50.549 --> 00:34:54.239
auch dort in einem Büro, bei einem
Staatsminister bei der Bundeskanzlerin war
00:34:54.239 --> 00:34:58.599
auch ein Mitarbeiter betroffen. Wobei die
Mitarbeiter fast interessanter sind als
00:34:58.599 --> 00:35:02.389
die Politiker selbst, weil die Mitarbeiter
sehr viel inhaltliche Arbeit für die
00:35:02.389 --> 00:35:04.879
Politiker machen. Und auch sowas,
00:35:04.879 --> 00:35:08.209
wie deren Reisen planen,
Kontakte herstellen.
00:35:08.209 --> 00:35:13.139
Jetzt wollte selbstverständlich nicht
jeder gerne mit uns reden und
00:35:13.139 --> 00:35:16.199
vor allem nicht vor der Kamera.
00:35:16.199 --> 00:35:19.729
Einer hat es dann getan, das ist
Valerie Wilms.
00:35:19.729 --> 00:35:23.930
Bevor wir sie jetzt mal hören, schauen
mir doch erstmal in ihre Daten.
00:35:23.930 --> 00:35:26.430
lachen
00:35:26.430 --> 00:35:31.609
Sie hat es freigegeben für diesen Vortrag,
sage ich noch dazu. Weil hier habe ich
00:35:31.609 --> 00:35:36.489
jetzt sozusagen wirklich nichts
anonymisiert, wie in dem Datensatz davor.
00:35:36.489 --> 00:35:43.950
So 01.08., ist auch Frühaufsteherin, erst
mal Banking... noch mal Banking... d.h.
00:35:43.950 --> 00:35:49.930
man kann also hier ziemlich gut sehen z.B.
wo Leute ihre Konten haben. Auf die Konten
00:35:49.930 --> 00:35:55.269
selbst kann man nicht zugreifen, aber man
weiß wo. Bisschen unangenehmer wird's
00:35:55.269 --> 00:36:00.449
dann für sie sozusagen Ende August, da
haben viele Leute ihre in Deutschland ihre
00:36:00.449 --> 00:36:04.069
Steuererklärung gemacht. Das habe ich
auch als Video nochmal. Da kann man
00:36:04.069 --> 00:36:05.069
nochmal so ein bisschen runterscrollen,
00:36:05.069 --> 00:36:07.960
Dann sehen wir ein bißchen mehr von ihrer
00:36:07.960 --> 00:36:13.870
Steuererklärung. Also man kann jetzt hier
sozusagen auf Elster-Online nicht selbst
00:36:13.870 --> 00:36:18.160
zugreifen. Also wenn wir das jetzt machen
würden, würden wir sozusagen nicht
00:36:18.160 --> 00:36:22.299
weiter kommen, weil dann auch nach einem
Passwort verlangt wird. Aber wir können
00:36:22.299 --> 00:36:27.190
sehen, welche Vordrucke sie sich
angeschaut hat. Und können so
00:36:27.190 --> 00:36:31.040
Informationen gewinnen, über Dinge,
00:36:31.040 --> 00:36:37.200
die sie gedenkt zu versteuern.
Und es ist recht detailreich.
00:36:43.530 --> 00:36:49.359
Ja, was hat sie nur dazu
gesagt, als wir bei ihr im Büro saßen?
00:36:49.359 --> 00:36:54.269
Wir können Sie einmal kurz hören dazu.
00:36:54.269 --> 00:36:58.550
Valerie Wilms: Ist rechts alles zu sehen?
Scheiße!
00:36:58.550 --> 00:37:01.450
Gelächter
00:37:01.450 --> 00:37:12.360
Applaus
00:37:12.360 --> 00:37:17.180
S: Gab noch eine andere Geschichte,
auf die wir sie angesprochen haben.
00:37:17.180 --> 00:37:20.779
Gibt ja nicht nur Steuererklärungen
sondern man schaut ja auch sowas bei
00:37:20.779 --> 00:37:26.470
Google nach Tebonin nimmt man so
bei Hörsturz, Tinitus,
00:37:26.470 --> 00:37:29.160
Abgeschlagenheit. Ist natürlich gerade
00:37:29.160 --> 00:37:33.079
für Politiker ein großes Problem, wenn
solch Informationen an die Öffentlichkeit
00:37:33.079 --> 00:37:38.419
gelangen, Menschen dann falsche Schlüsse
daraus ziehen oder auch, ja, die Leute
00:37:38.419 --> 00:37:44.050
damit erpressen können. Z.B. haben wir
sie auch darauf angesprochen.
00:37:44.050 --> 00:37:47.329
Will ich die Reaktion nicht vorenthalten.
00:37:47.819 --> 00:37:51.519
Valerie Wilms: Ich weiß gar nicht in
welchem Zusammenhang ich dieses
00:37:51.519 --> 00:37:54.549
Tebonin mir da angeguckt habe,
das ist nicht schön,
00:37:54.549 --> 00:37:59.890
sowas nachträglich zu lesen. Vor allen
Dingen verknüpft mit dem eigenen Namen.
00:37:59.890 --> 00:38:05.480
S: Ja, das war Valerie Wilms zu ihren
Daten. An diesem ganz kleinen Ausschnitt
00:38:05.480 --> 00:38:10.940
sieht man wie Problematisch diese Daten
sind. Ich hab jetzt nicht die Beiträge
00:38:10.940 --> 00:38:17.640
gezeigt, wo Menschen ihre sexuellen
Vorlieben ausleben. Weil, dass betrifft
00:38:17.640 --> 00:38:22.039
natürlich auch Leute, die in
öffentlichen oder in relevanten
00:38:22.039 --> 00:38:27.369
Positionen stehen. Natürlich sind auch
Richter in diesen Daten. Natürlich sind
00:38:27.369 --> 00:38:34.819
auch Wirtschaftsbosse in diesen Daten. Und
natürlich sind das alles Menschen und die
00:38:34.819 --> 00:38:39.779
haben Träume und die haben Gedanken, und
es überhaupt nichts, was in dritte Hände
00:38:39.779 --> 00:38:44.859
gehört. Und deshalb war mit allen mit
denen wir gesprochen haben, im Zuge dieser
00:38:44.859 --> 00:38:51.930
Recherche, war das für alle Betroffenen
sehr schockierend. Aber wer hat sie
00:38:51.930 --> 00:38:57.489
ausgespäht? Woher kommen diese Daten? War
es irgendwie ein shady Trojaner oder so
00:38:57.489 --> 00:39:04.039
auf dem Rechner? Nein. Wir sind relativ
schnell drauf gekommen, dass es
00:39:04.039 --> 00:39:09.579
Browser-Plugins sind und haben dann einen
kleinen Test gemacht, haben einen Nutzer
00:39:09.579 --> 00:39:15.190
gebeten Add-Ons zu deinstallieren. Und
haben dann eines herausfinden können;
00:39:15.190 --> 00:39:26.069
Web-of-Trust - Was machen die so?
Safe Web Search & Browsing.
00:39:26.069 --> 00:39:28.220
Applaus
00:39:28.220 --> 00:39:34.200
Haben das dann noch mal mit einem sauberen
Browser sozusagen gegengetestet in der
00:39:34.200 --> 00:39:40.749
Zeit als wir eine Möglichkeit hatten Live
in die Daten zuzugreifen, das hat ein
00:39:40.749 --> 00:39:46.569
Securityspezialist für uns gemacht Mike
Kuketz und der hatte eine extra Webseite
00:39:46.569 --> 00:39:50.380
aufgesetzt, einen sauberen Browser, nur
dieses eine Plugin installiert und wir
00:39:50.380 --> 00:39:54.069
konnten ihn in den Daten sehen. Und
dadurch konnten wir sicher sein, dass es
00:39:54.069 --> 00:39:58.440
eben bei diesem einen Plugin auch
tatsächlich der Fall war, dass dieser Weg
00:39:58.440 --> 00:39:59.579
eben so gegangen ist.
00:39:59.579 --> 00:40:07.349
A: Ja, warum ist das Tracking per App oder
Extension eigentlich so interessant für
00:40:07.349 --> 00:40:10.880
die Anbieter? Nun für Unternehmen ist es
eigentlich immer sehr spannend ein
00:40:10.880 --> 00:40:15.380
möglichst detailliertes Bild von einem
entsprechenden Nutzer zu gewinnen. D.h.
00:40:15.380 --> 00:40:19.100
ich möchte, wenn möglich, sämtliche Daten
die über den Nutzer zur Verfügung
00:40:19.100 --> 00:40:23.099
stehen. Und bei normalen Treckern ist das
ja so, dass ich als Nutzer mir eine
00:40:23.099 --> 00:40:26.590
Webseite runterlade, in meinen Browser,
dann ein entsprechend ein
00:40:26.590 --> 00:40:30.159
JavaScript-Applet oder ein anderes
Tracking-Tag ausgeführt wird, dass eine
00:40:30.159 --> 00:40:32.369
entsprechende Verbindung aufbaut zu einem
00:40:32.369 --> 00:40:34.290
Tracking-Server und da Bspw. ein Cockie
00:40:34.290 --> 00:40:37.609
setzt oder eine andere Information
speichert, die mich dann als Nutzer
00:40:37.609 --> 00:40:42.319
nachverfolgt. In den letzten hat sich
dagegen, verständlicherweise, eine Menge
00:40:42.319 --> 00:40:47.319
Widerstand auch geregt und viele Leute
benutzen mittlerweile Blocker, die
00:40:47.319 --> 00:40:51.249
verhindern, dass solche Tracking-Scripte
ausgeführt werden. Oder die Verbindung zu
00:40:51.249 --> 00:40:54.899
den Tracking-Servern abfangen oder
blockieren. D.h. es wird immer schwieriger
00:40:54.899 --> 00:40:59.299
für die Tracking-Anbieter qualitativ
hochwertige Daten zu bekommen und da liegt
00:40:59.299 --> 00:41:04.870
es doch eigentlich nahe, dass man sich
solchen Mechanismen, in Form von einer
00:41:04.870 --> 00:41:09.020
Extension, zu Nutze macht, in dem man
die Sicherheitsmaßnahmen, die es in dem
00:41:09.020 --> 00:41:12.609
Browser eigentlich per Default gibt,
relativ einfach umgeht und dann über
00:41:12.609 --> 00:41:16.969
diesen Side-Channel sozusagen die
Information bei jeder einzeln aufgerufenen
00:41:16.969 --> 00:41:20.960
URL direkt an den Tracking-Server sendet.
Und das hat einen weiteren Vorteil für
00:41:20.960 --> 00:41:24.530
die Anbieter, weil damit nicht nur die
Seiten überwacht werden können, die
00:41:24.530 --> 00:41:28.160
wirklich Tracking-Codes auch explizit
beinhalten, sondern auch viele andere
00:41:28.160 --> 00:41:33.200
Webseiten, die überhaupt keine Codes auf
der Seite haben. Also Bspw. Seiten von
00:41:33.200 --> 00:41:37.349
öffentlich Rechtlichen Institutionen, die
ihre Nutzer im Normalfall nicht tracken.
00:41:37.349 --> 00:41:42.011
D.h. es ist also möglich über dieses
Verfahren von einer kleineren Anzahl an
00:41:42.011 --> 00:41:46.839
Usern allerdings ein sehr viel größeres
Spektrum an Daten, im Idealfall oder im
00:41:46.839 --> 00:41:51.440
schlimmsten Fall, je nachdem wie man das
sieht, die komplette Browsinghistory von
00:41:51.440 --> 00:41:56.009
diesem entsprechenden User zu gewinnen.
So, wir haben uns in unserem Datensatz
00:41:56.009 --> 00:42:00.759
dafür nochmal angeschaut, wie viele von
diesen Extensions es eigentlich gibt und
00:42:00.759 --> 00:42:05.079
wie viele Daten jede von diesen Extensions
generiert. Und hier haben wir wieder einen
00:42:05.079 --> 00:42:08.499
doppelt logarithmischen Plot, wo auf der
einen Seite hier der Rang der
00:42:08.499 --> 00:42:10.449
entsprechenden Extension aufgetragen ist
00:42:10.449 --> 00:42:12.859
d.h. je mehr Datenpunkte von
der Extension
00:42:12.859 --> 00:42:18.210
wir bekommen haben, umso weiter finden Sie
hier die Extension links. Und auf der
00:42:18.210 --> 00:42:21.879
anderen Achse haben wir die Anzahl der
Datenpunkte entsprechend aufgetragen. Und
00:42:21.879 --> 00:42:26.630
wir sehen hier, dass die populärste
Extension, das ist Web-of-Trust bereits
00:42:26.630 --> 00:42:31.319
für 1 Mrd. Datenpunkte in dem Datensatz
verantwortlich ist. Und wenn man die
00:42:31.319 --> 00:42:36.809
ersten 10 Extensions nehmen, sehen wir,
dass bereits 95% der Daten davon abgedeckt
00:42:36.809 --> 00:42:42.380
werden. D.h. es ist also eine kleine
Anzahl von Extension, die eigentlich die
00:42:42.380 --> 00:42:46.660
größte Masse an Daten hier für diesen
Anbieter produziert. Wobei es auch sehr
00:42:46.660 --> 00:42:50.990
viele, also hier fast 10.000 verschiedene
Application-IDs gibt, die teilweise einige
00:42:50.990 --> 00:42:57.200
100 oder bis zu einige 100.000 oder einige
Mio. Datenpunkte ihrerseits liefern. Es
00:42:57.200 --> 00:43:00.999
ist nicht unbedingt gesagt, dass es auch
10.000 Extensions sind, weil wir keine
00:43:00.999 --> 00:43:04.839
eindeutige Zuordnung zu der Application-ID
haben, d.h. das ist eher eine obere
00:43:04.839 --> 00:43:08.279
Abschätzung. Und um jetzt ein genaueres
Bild zu bekommen,
00:43:08.279 --> 00:43:10.939
wie verseucht eigentlich so ein Web-Store
00:43:10.939 --> 00:43:14.159
ist, haben wir eine
Verhaltensanalyse durchgeführt,
00:43:14.159 --> 00:43:17.189
wofür wir mit einem
Automatisierungsframework:
00:43:17.189 --> 00:43:19.839
Webdriver - uns einfach einen
Chrome-Browser
00:43:19.839 --> 00:43:23.419
genommen haben, da automatisiert
verschiedene Extensions installiert haben
00:43:23.419 --> 00:43:28.869
und dann mit diesem Webdriver entsprechend
verschiedene Webseiten angesurft haben,
00:43:28.869 --> 00:43:33.589
wobei wir über einen Python-basierten
Proxy-Server dann mitgeloggt haben, welche
00:43:33.589 --> 00:43:38.109
URLs bzw. welche Webseiten von dem
entsprechenden Browser geöffnet wurden,
00:43:38.109 --> 00:43:41.609
wenn wir bestimmte Seiten angesteuert
haben. D.h. darüber konnten wir
00:43:41.609 --> 00:43:46.069
verfolgen, ob der Browser beim Öffnen von
bestimmten Seiten oder von allen URLs
00:43:46.069 --> 00:43:50.980
vielleicht noch zusätzlich Informationen
eventuell an Dritte schickt. Und das haben
00:43:50.980 --> 00:43:54.680
wir für ca. 500 Plugins so ausgeführt
und wie man hier sehen kann, verhalten
00:43:54.680 --> 00:43:58.719
sich die meisten eigentlich so, wie man
es erwarten würde, d.h die öffnen nur die
00:43:58.719 --> 00:44:03.180
URLs, die entsprechende Anzahl der URLs,
die man erwarten würde für den
00:44:03.180 --> 00:44:08.289
Testdatensatz, den wir verwendet haben.
Und gleichzeitig gibt es auch einige
00:44:08.289 --> 00:44:12.750
Extensions, z.B. das hier, dass sich
merkwürdig verhält und sehr viele
00:44:12.750 --> 00:44:16.640
URL-Aufrufe hat. Und hier haben wir bei
einer genauen Analyse auch gesehen, dass
00:44:16.640 --> 00:44:20.710
das entsprechende Plugin oder die
Extension auch Daten an einen Drittserver
00:44:20.710 --> 00:44:25.150
schickt, bei jeder aufgerufenen URL. Wobei
man sagen muss, dass jetzt aus den 500
00:44:25.150 --> 00:44:30.449
untersuchten Extension nur einige dabei
waren, die wirklich eventuell schadhaftes
00:44:30.449 --> 00:44:33.599
Verhalten zeigen. D.h. die
Wahrscheinlichkeit, dass man sich mit
00:44:33.599 --> 00:44:37.430
Extension infiziert, in dem man Sachen
runterlässt aus dem Webstore ist aktuell
00:44:37.430 --> 00:44:43.990
noch relativ gering, scheint aber größer
zu werden. So, die letzte Frage ist
00:44:43.990 --> 00:44:48.559
natürlich: Wie oder kann ich mich
überhaupt gegen so etwas schützen? Und
00:44:48.559 --> 00:44:53.759
ich denke, daß in einigen Jahren es trotz
client-seitigen blockierens von Trackern
00:44:53.759 --> 00:44:57.680
immer schwieriger sein wird sich als
Nutzer anonym im Internet zu bewegen, weil
00:44:57.680 --> 00:45:01.999
es, wie wir gesehen haben, anhand von
einigen wenigen Datenpunkten möglich ist,
00:45:01.999 --> 00:45:06.069
eine Identifikation von an sich
anonymisierten Daten herzustellen.
00:45:06.069 --> 00:45:09.899
Dh. selbst wenn ich mit einem Tracker
oder eine Extension sämtliche Tracker
00:45:09.899 --> 00:45:13.320
blockiere, habe ich immer noch solche
Dinge wie: meine IP-Adresse, meinen
00:45:13.320 --> 00:45:17.200
User-Agent und die Kombination aus
mehreren solchen Eigenschaften kann schon
00:45:17.200 --> 00:45:20.989
ausreichen, um mich wieder eindeutig zu
identifizieren in größeren Datensätzen.
00:45:20.989 --> 00:45:25.579
D.h. wenn ich wirklich sicher im Internet
unterwegs sein möchte, müsste ich
00:45:25.579 --> 00:45:28.950
zumindest darauf achten, dass ich
möglichst viele dieser Eigenschaften
00:45:28.950 --> 00:45:33.200
ständig rotiere und ändere in dem
ich bspw. VPN-Lösungen benutze, die auch
00:45:33.200 --> 00:45:37.630
rotierende IP-Adressen verwenden. Wobei
das auch keine Garantie natürlich ist,
00:45:37.630 --> 00:45:41.900
dass man nicht getrackt werden kann.
D.h. es wird also immer schwieriger sich
00:45:41.900 --> 00:45:48.160
im Internet zu bewegen, ohne dem Risiko
der Deanonymisierung ausgesetzt zu sein.
00:45:48.160 --> 00:45:57.440
S: Genau, was ist so das Ergebnis von der
Recherche gewesen? Also WOT verschwand
00:45:57.440 --> 00:46:02.499
relativ kurz nach der Veröffentlichung
des Berichts zunächst mal aus dem
00:46:02.499 --> 00:46:08.519
Chrome-Webstore und aus dem Mozilla-Store
und es haben natürlich sehr viele Nutzer
00:46:08.519 --> 00:46:12.910
wie verrückt Plugins deinstalliert.
Deswegen können wir davon ausgehen, dass
00:46:12.910 --> 00:46:20.390
auch der Datenstrom dann eingebrochen ist.
Aber natürlich die Plugins, die weiterhin
00:46:20.390 --> 00:46:26.239
installiert sind und Nutzer, die es jetzt
nicht deinstalliert haben, da läuft es
00:46:26.239 --> 00:46:30.650
natürlich weiter. Und auch inzwischen,
jetzt ein paar Wochen nach der Recherche,
00:46:30.650 --> 00:46:40.150
ist WOT wieder im Google-Chrome-Store
verfügbar. So mein persönliches Fazit
00:46:40.150 --> 00:46:46.210
daraus ist, ein Stück weit defend
yourself. Sprich, Andreas hatte schon
00:46:46.210 --> 00:46:51.259
angedeutet, man kann sich nicht auf die
Stores verlassen, man muss sich ein Stück
00:46:51.259 --> 00:46:55.999
weit selbst schützen und selbst
überlegen, was kann ich tun um dieser
00:46:55.999 --> 00:47:00.690
Überwachung zu entgehen. Ja, also wir
sind recht am Ende von unserem Talk aber
00:47:00.690 --> 00:47:05.079
trotzdem ganz wichtig nochmal der Dank an
ein relativ großes Team was uns
00:47:05.079 --> 00:47:08.950
unterstützt hat in dieser Zeit ja vor
allem meine Kollegin die Jasmin Klofta
00:47:08.950 --> 00:47:12.249
sitzt in der ersten Reihe, ja Dankeschön.
00:47:12.249 --> 00:47:18.390
Applaus
00:47:29.830 --> 00:47:32.569
Herald: So, wir haben noch ein wenig Zeit
für Fragen.
00:47:32.569 --> 00:47:35.569
Wer eine Frage hat, bewegt sich bitte zu
00:47:35.569 --> 00:47:44.789
bitte zu einem der Mikrofone. So, ich sehe
Bewegung. Aber ein paar flüchten erstmal.
00:47:44.789 --> 00:47:52.919
War vielleicht doch nicht ganz so einfach
für die Nichtdeutschsprachigen., aber sehr
00:47:52.919 --> 00:47:55.900
spannend. Dahinten haben wir
eine Frage an Mikrofon 6 bitte.
00:47:55.900 --> 00:48:01.940
Mikrofon 6: Hallo, angenommen die Person,
über die man die öffentlichen Daten
00:48:01.940 --> 00:48:06.390
sammelt, ist nicht im Pool von den
anonymisierten Daten. Dann gibts ja eine
00:48:06.390 --> 00:48:09.780
Möglichkeit für einen False-Positive.
Oder kann man das ausschließen?
00:48:09.780 --> 00:48:15.309
A: Ja, natürlich gibt es auch die
Möglichkeit von einem False-Positive. Das
00:48:15.309 --> 00:48:21.289
das hängt natürlich immer ein bisschen von
der Nutzung der Daten ab, ob das
00:48:21.289 --> 00:48:25.200
problematisch ist oder nicht für den
Anbieter. Es kann ja auch sein, wenn ich
00:48:25.200 --> 00:48:29.469
Bspw. Nutzern Werbung anzeigen möchte, es
vielleicht auch gut genug ist, wenn ich
00:48:29.469 --> 00:48:33.020
den Nutzer mit einer Wahrscheinlichkeit
von 10% schon identifiziere.
00:48:33.020 --> 00:48:35.099
D.h. ich kann auch mit False-Positives
00:48:35.099 --> 00:48:36.119
oder der Anbieter kann auch mit
00:48:36.119 --> 00:48:37.709
False-Positives entsprechend leben.
00:48:37.709 --> 00:48:39.159
Aber es ist natürlich immer die
00:48:39.159 --> 00:48:40.880
Möglichkeit gegeben, das der Nutzer,
00:48:40.880 --> 00:48:42.649
wenn er nicht in dem Datensatz vorhanden
00:48:42.649 --> 00:48:45.189
ist, auch entsprechend identifiziert wird,
00:48:45.189 --> 00:48:48.570
obwohl gar nicht drin ist. Und das kann
natürlich für den Nutzer selber zu großen
00:48:48.570 --> 00:48:50.889
Problemen führen. Wenn ich da Bspw. an
Credit-Scoring denke,
00:48:50.889 --> 00:48:52.289
über Machinelearning,
00:48:52.289 --> 00:48:55.960
wo ich also vielleicht mit jemandem in
Verbindung gebracht werde, der ich gar
00:48:55.960 --> 00:49:00.329
nicht bin und Datenpunkte, die ich nicht
kontrollieren kann, entsprechend meine
00:49:00.329 --> 00:49:03.130
Kreditwürdigkeit dann beeinflussen kann.
00:49:03.130 --> 00:49:06.769
Herald: Gut, an Mikro 3 bitte.
00:49:06.769 --> 00:49:12.619
Mikrofon 3: Meine persönliche Frage ist,
was genau kostet das? Also kann sich eine
00:49:12.619 --> 00:49:17.880
kleinere, mittelgroße, Privatdetektei die
auf Datenschutz scheißt, können die sich
00:49:17.880 --> 00:49:18.880
Zugang holen?
00:49:18.880 --> 00:49:24.369
S: Ja, weiß nicht was die für ein Budget
haben aber diese Daten werden lizensiert.
00:49:24.369 --> 00:49:29.970
I.d.R. zahlt man für die Lizenz so für
einen Monat und im Jahr ist das so
00:49:29.970 --> 00:49:33.760
im 6-stelligen Bereich.
00:49:33.760 --> 00:49:36.899
Mirofon 2:
Sie hatten von den 10 Schlimmsten
00:49:36.899 --> 00:49:38.989
gesprochen, aber die Liste vergessen.
00:49:38.989 --> 00:49:40.599
Lachen
Applaus
00:49:40.599 --> 00:49:44.869
A: Den 10 Schlimmsten, ach so, ja.
00:49:44.869 --> 00:49:47.599
Applaus
S: lachen genau
00:49:47.599 --> 00:49:51.110
A: Also wir haben auch lange überlegt ob
wir die Extensions entsprechend
00:49:51.110 --> 00:49:54.560
veröffentlichen können, wir haben
allerdings noch keine Zeit gehabt jetzt
00:49:54.560 --> 00:49:58.340
eine detaillierte Analyse zu machen. Und
ich möchte keine Namen jetzt nennen von
00:49:58.340 --> 00:50:02.069
Dingen, wo sich am Ende herausstellt, dass
es eigentlich gar nicht problematisch ist.
00:50:02.069 --> 00:50:04.289
Wir werden auf jeden Fall dran
bleiben und versuchen alle von diesen
00:50:04.289 --> 00:50:08.139
Extension, die in dem Datensatz drin sind
zu identifizieren. Aber wir wollen
00:50:08.139 --> 00:50:12.129
natürlich eine Gewissheit haben, dass auch
entsprechend wir die korrekten Extensions
00:50:12.129 --> 00:50:15.130
rausfiltern können, bevor wir
die Namen dann veröffentlichen.
00:50:15.130 --> 00:50:21.060
Applaus
00:50:21.060 --> 00:50:24.190
Herald: So, wir haben auch Fragen aus dem
Internet. Eine mal dazwischen.
00:50:24.190 --> 00:50:30.950
Signal Engel: Also ich nehme jetzt mal ein
paar Fragen aus dem Internet zusammen.
00:50:30.950 --> 00:50:35.030
Im wesentlichen lässt sich das
runterdampfen auf: Gibt es irgendwelche
00:50:35.030 --> 00:50:39.319
technischen, juristischen oder sonstwie
gearteten Mittel um sich davor zu
00:50:39.319 --> 00:50:43.799
schützen, oder dagegen vorzugehen? Oder
wurde da schon versucht da z.B. zu klagen?
00:50:43.799 --> 00:50:46.300
A: Möchtest du das beantworten?
00:50:46.300 --> 00:50:50.099
S: Ja, also einen Teil kann ich
beantworten. Also jetzt von unseren
00:50:50.099 --> 00:50:54.811
Betroffenen hat da noch niemand geklagt.
So technisch gibt es natürlich
00:50:54.811 --> 00:50:57.849
Möglichkeiten sich zu schützen.
Zumindest ein gutes Stück weit.
00:50:57.849 --> 00:51:01.729
A: Ja, es gibt für den Nutzer natürlich
bedingte Möglichkeiten sich zu schützen.
00:51:01.729 --> 00:51:06.049
Das Problem ist ja, das viele Nutzer das
Problem gar nicht kennen oder nicht sich
00:51:06.049 --> 00:51:08.780
bewusst sind, dass ihre Daten entsprechend
gesammelt werden. Da ist also im
00:51:08.780 --> 00:51:12.100
Zweifelsfall die Verantwortung bei den
Browser-Herstellern und wir sind auch ein
00:51:12.100 --> 00:51:15.019
bisschen enttäuscht darüber, dass
Web-Of-Trust wieder in dem Chrome-Store
00:51:15.019 --> 00:51:19.339
drin ist und auch weiterhin fleißig Daten
sammelt. Und auch die entsprechenden
00:51:19.339 --> 00:51:20.339
Extensions, die schon vorher installiert
00:51:20.339 --> 00:51:22.690
wurden, auch nicht entfernt wurden in dem
00:51:22.690 --> 00:51:23.690
Sinne. D.h. im Zweifelsfalle ist wirklich
00:51:23.690 --> 00:51:25.950
der Hersteller des Browsers am besten in
00:51:25.950 --> 00:51:29.339
der Lage, den Nutzer vor solcher
Schadsoftware zu schützen, indem er ein
00:51:29.339 --> 00:51:33.149
korrektes Auditing von den Extensions
durchführt, bevor sie in dem Store landen
00:51:33.149 --> 00:51:34.809
und auch entsprechende Extensions,
00:51:34.809 --> 00:51:36.580
die gegen diese Bedingungen verstoßen
00:51:36.580 --> 00:51:37.879
schnell wieder entfernt.
00:51:37.879 --> 00:51:42.020
S: Und es macht auch Sinn sich mal
verschiedene Browser, Browseranbieter
00:51:42.020 --> 00:51:47.419
anzuschauen, weil es gibt ja auch neben
den Großen Kleinere, die noch mal mehr Wert
00:51:47.419 --> 00:51:50.720
legen eben darauf, dass man z.B. gar
keine Plugins installieren kann.
00:51:50.720 --> 00:51:56.710
Herald: An Nummer 5 bitte.
00:51:56.710 --> 00:52:02.089
Mikrofon 5: Gibt es die Möglichkeit, dass
ihr die Liste, die ihr für eure Recherche
00:52:02.089 --> 00:52:06.109
erstellt habt, von Unternehmen die Daten
verkaufen, veröffentlicht. Quasi als
00:52:06.109 --> 00:52:10.829
not-to-work-for-Liste. Ich mein unsereins
baut ja im Zweifelsfall irgendwelchen
00:52:10.829 --> 00:52:14.420
Scheiß, also liegt es
auch an uns es zu lassen.
00:52:14.420 --> 00:52:17.970
Applaus
00:52:17.970 --> 00:52:23.749
S: Ja, es fehlt natürlich ein Name, hier
in diesem ganzen Vortrag. Der Name des
00:52:23.749 --> 00:52:25.689
Datenhändlers oder auch tatsächlich die
00:52:25.689 --> 00:52:27.550
Namen der Firmen mit denen ich auch ein
00:52:27.550 --> 00:52:29.350
bisschen ernsthafter ins Geschäft
gekommen bin.
00:52:29.350 --> 00:52:30.890
Das sind eigentlich juristische
00:52:30.890 --> 00:52:34.299
Gründe, warum wir das nicht
veröffentlichen können oder dürfen.
00:52:34.299 --> 00:52:37.309
Einfach, ehrlich gesagt aus Furcht vor
00:52:37.309 --> 00:52:42.430
diesen Unternehmen, aus sozusagen
Angst vor Klagen, die da kommen können.
00:52:42.430 --> 00:52:46.759
Und deshalb sieht es
zumindest im Moment so aus, als dürften
00:52:46.759 --> 00:52:51.390
wir die Namen nicht veröffentlichen. Aber
das ist noch work-in-progress sage ich mal.
00:52:51.390 --> 00:52:53.770
Zwischenruf
Wikiwleaks
00:52:53.770 --> 00:52:54.190
Lachen
00:52:54.190 --> 00:53:00.220
Applaus
00:53:00.220 --> 00:53:03.010
Engel: Mikro 1
00:53:03.010 --> 00:53:08.280
Mikrofon 1: So einer der Klassiker ist ja
JavaScript aus und Cockies aus und nur für
00:53:08.280 --> 00:53:12.349
irgendwie bestimmte Seiten, denen man
vertraut, zulassen. Jetzt sagen Sie aber
00:53:12.349 --> 00:53:15.949
auch... Aber wie weit würden Sie denn
kommen, wenn man jetzt wirklich sowas
00:53:15.949 --> 00:53:20.710
wegnimmt und nur über ip-basierte Daten
und sowas, wie weit würde man da mit der
00:53:20.710 --> 00:53:22.219
Deanonymisierung kommen?
00:53:22.219 --> 00:53:25.930
A: Also meines Wissens setzen viele
Anbieter bereits Verfahren ein die
00:53:25.930 --> 00:53:29.259
eigentlich nicht mehr auf Cockies
basieren, also nur noch, wenn diese
00:53:29.259 --> 00:53:33.190
verfügbar sind und die statt dessen auf
anderen Identifikationsmerkmalen basieren
00:53:33.190 --> 00:53:38.450
die entsprechend schwerer zu ändern sind.
Bspw: der IP-Adresse, der Device-ID oder
00:53:38.450 --> 00:53:42.280
anderen IDs, die entsprechend fix sind und
getrackt werden können über die Zeit.
00:53:42.280 --> 00:53:46.599
D.h. ist relativ einfach zumindest mit
einer hohen Wahrscheinlichkeit möglich
00:53:46.599 --> 00:53:51.460
Nutzer über verschiedene Endgeräte zu
identifizieren. Und ich kann mich
00:53:51.460 --> 00:53:55.239
natürlich über das Client-Seitige
Browser-Tracking schützen, aber das heißt
00:53:55.239 --> 00:53:59.459
nicht, dass ich mich gegen diese anderen
Tracking-Maßnahmen auch schützen kann.
00:53:59.459 --> 00:54:01.249
Engel: Mikro 6.
00:54:01.249 --> 00:54:09.619
Mikrofon 6: Zur Deanonymisierung. Ist es
möglich, so Deanonymisierung, stark zu
00:54:09.619 --> 00:54:16.720
erschweren oder zu verhindern durch so
Methoden wie Differential Privacy?
00:54:16.720 --> 00:54:21.450
A: Ja, dass ist in bestimmten Kontexten
anwendbar. Hier bei den Daten ist das
00:54:21.450 --> 00:54:25.140
Problem, dass ich selbst als Nutzer
eigentlich nicht kontrolliere, was ich von
00:54:25.140 --> 00:54:29.410
mir generiere, weil die Daten entweder
unbewusst oder ohne meine Zustimmung
00:54:29.410 --> 00:54:34.099
erhoben werden. D.h. das einzige was ich
tun kann als Nutzer ist zusätzlich
00:54:34.099 --> 00:54:37.890
Datenenpunkte zu liefern, ich habe aber
keine Möglichkeit Datenpunkte zu fälschen
00:54:37.890 --> 00:54:42.839
oder nur in sehr geringem Umfang zumindest
oder auch Datenpunkte wieder zu entfernen.
00:54:42.839 --> 00:54:48.599
D.h. in dem Sinne wäre das vermutlich eher
weniger angebracht aber klar im
00:54:48.599 --> 00:54:51.949
Zweifelsfall ist es immer besser möglichst
wenige Informationen rauszugeben.
00:54:51.949 --> 00:54:54.739
Obwohl eigentlich schon ausreicht wenige
00:54:54.739 --> 00:54:58.549
kleine Informationsschnipsel zu haben,
die man dann relativ schnell auch
00:54:58.549 --> 00:55:00.679
zusammen fügen kann, wie wir gesehen
haben.
00:55:00.679 --> 00:55:03.049
D.h. es ist auch wirklich schwer
abzuschätzen und
00:55:03.049 --> 00:55:05.179
hängt auch immer sehr stark von der Natur
00:55:05.179 --> 00:55:10.129
des Datensatzes ab, wie verräterisch
einzelne Datenpunkte von mir sein können.
00:55:10.129 --> 00:55:13.289
Engel: Mikro 5.
00:55:13.289 --> 00:55:17.930
Mikrofon 5: Ich würde gerne ein bisschen
eine naive Frage stellen. Wieso ist das
00:55:17.930 --> 00:55:22.819
eigentlich quasi möglich oder erlaubt,
also die juristische Frage. Und auf der
00:55:22.819 --> 00:55:26.789
anderen Seite, scheint mir doch ein
gewisses Gefälle zu sein zu dem, was auf
00:55:26.789 --> 00:55:31.829
der einen Seite gemacht wird und sie die
jetzt Sorge haben, diese Namen zu nennen,
00:55:31.829 --> 00:55:35.490
auf der anderen Seite, da scheint es mir
ein gewisses juristisches Gefälle
00:55:35.490 --> 00:55:38.339
zu geben, das ich gerne verstehen würde.
00:55:38.339 --> 00:55:44.169
Applaus
00:55:44.169 --> 00:55:47.989
S: Sehr gute Frage, vielen Dank dafür. Wir
haben tatsächlich diesen juristischen
00:55:47.989 --> 00:55:50.649
Aspekt für diesen Vortrag ein Stück weit
ausgeklammert.
00:55:50.649 --> 00:55:53.249
Und der ist aber trotzdem hochspannend.
00:55:53.249 --> 00:55:57.519
Und wir haben viele Gespräche mit
Datenschützern darüber geführt,
00:55:57.519 --> 00:56:01.970
mit Juristen darüber geführt und haben
tatsächlich auch Paragraphen gewälzt weil
00:56:01.970 --> 00:56:06.160
uns genauso diese Frage beschäftigt hat,
kann das überhaupt erlaubt sein. Also
00:56:06.160 --> 00:56:10.760
zumindest was man für Deutschland sagen
kann, das ist nicht erlaubt. Und zwar ganz
00:56:10.760 --> 00:56:15.259
einfach aus dem Grund, weil keiner der
Nutzer irgendwo dazu zugestimmt hat. Also
00:56:15.259 --> 00:56:19.360
keiner der Nutzer hat, die wir besucht
haben, hat irgendwo irgendwas angeklickt:
00:56:19.360 --> 00:56:23.329
„Ja ich möchte bitte, dass meine Daten in
diesem Umfang...“ Keiner. Und das kann
00:56:23.329 --> 00:56:30.289
sogar nach Aussage vom Datenschützer
eventuell strafrechtlich relevant sein,
00:56:30.289 --> 00:56:39.030
also sprich in Richtung Abhören gehen.
Bislang hat sich noch niemand berufen
00:56:39.030 --> 00:56:45.829
gefühlt, da tatsächlich Klage oder Anklage
zu führen. Was wir jetzt sozusagen machen
00:56:45.829 --> 00:56:49.930
trägt ja vielleicht dazu bei, dass es mal
eine Eingabe gibt beim Datenschützer und
00:56:49.930 --> 00:56:52.459
dass tatsächlich sich auch
mal jemand dahinter klemmt.
00:56:52.459 --> 00:56:56.129
A: Gerade bei Ausländischen Unternehmen
ist es natürlich immer sehr schwierig
00:56:56.129 --> 00:56:59.799
auch entsprechend eine Handhabe zu
bekommen, um die auch juristisch belangen
00:56:59.799 --> 00:57:04.299
zu können. D.h. da ist auch nochmal
sicherlich ein Gefälle vorhanden und auch
00:57:04.299 --> 00:57:08.710
die Strafen, die Unternehmen im
Zweifelsfall drohen, sind im Vergleich zu
00:57:08.710 --> 00:57:12.619
dem Schaden, der oder zu dem Risiko, das
Jemand eingeht, indem er diese Dinge
00:57:12.619 --> 00:57:16.770
veröffentlicht, eigentlich relativ gering.
Weswegen es auch relativ wenig zu solchen
00:57:16.770 --> 00:57:18.430
Dingen kommt, denken wir.
00:57:18.430 --> 00:57:21.079
Engel: Gut, ich denke wir haben
noch Zeit für zwei Fragen.
00:57:21.079 --> 00:57:22.880
Wir haben noch eine
aus dem Internet.
00:57:22.880 --> 00:57:26.530
Signal Engel: Das Internet lässt fragen,
in wie fern man sein eigenen
00:57:26.530 --> 00:57:30.379
Informationen, sofern sie auftauchen, von
euch bekommen kann oder auch nicht.
00:57:30.379 --> 00:57:32.940
A: Uh... schwierige Frage.
00:57:32.940 --> 00:57:33.940
Applaus
00:57:33.940 --> 00:57:41.400
S: Das ist recht einfach die Antwort. Gar
nicht. Die Daten gibts nicht mehr. Sorry.
00:57:41.400 --> 00:57:42.420
Applaus
00:57:42.420 --> 00:57:49.609
Herald:
Kommen wir zu unserer letzten Frage.
00:57:49.609 --> 00:57:56.650
Mikrofon: Ja, also, Hallo, hört man das?
Ok. Ich bin dann immer ein Freund von
00:57:56.650 --> 00:58:02.170
Selbstverteidigung und so wie sie sagten,
aber die Frage ist, ist das überhaupt
00:58:02.170 --> 00:58:06.349
möglich? Also ich würde sagen, dass Thema
ist so komplex, dass sich wahrscheinlich
00:58:06.349 --> 00:58:09.969
die meisten, die hier sind, nur dann
schützen können, wenn sie wirklich viel
00:58:09.969 --> 00:58:16.550
Zeit reinstecken in diese Arbeit. Und ich
frage mich: meine Mutter, mein Vater, mein
00:58:16.550 --> 00:58:18.910
Onkel, wie sollen die
sich vor sowas schützen?
00:58:18.910 --> 00:58:22.089
A: Willst du oder soll ich?
S: Ja, mach ruhig.
00:58:22.089 --> 00:58:26.049
A: Ja, das ist das Problem, dass ich auch
eben kurz angesprochen habe. Und zwar,
00:58:26.049 --> 00:58:29.849
dass viele Nutzer auch gar nicht wissen,
dass sie getrackt werden und auch nicht
00:58:29.849 --> 00:58:34.109
die technischen Kenntnisse haben, um sich
effektiv gegen sowas zu schützen. Wir
00:58:34.109 --> 00:58:38.240
haben ja gesehen, obwohl die Leser von
Fefes-Blog eher technik-affin sind, gibts
00:58:38.240 --> 00:58:42.109
immer noch 3.000 Nutzer, die in dem
Datensatz auftauchen, die also auch
00:58:42.109 --> 00:58:45.859
getrackt wurden in dem Sinne. D.h. dass
selbst Leute mit IT-Kenntnissen und
00:58:45.859 --> 00:58:49.710
IT-Sicherheitserfahrung sind nicht dagegen
gefeit auch entsprechend getrackt zu
00:58:49.710 --> 00:58:54.150
werden. Weil es auch unglaublich schwierig
ist, auch für mich, sämtliche Methoden
00:58:54.150 --> 00:58:57.790
nachzuvollziehen und immer auf dem
aktuellen Stand zu sein. Und es ist auch
00:58:57.790 --> 00:59:01.999
sehr schwer abschätzbar, was man mit den
Daten eigentlich machen kann. Also es
00:59:01.999 --> 00:59:05.960
stimmt wirklich, ja, es ist wirklich, es
gibt keine gute Lösung momentan dafür.
00:59:05.960 --> 00:59:11.069
Herald: So es gibt zwar noch weitere
Fragen aber die Zeit ist leider vorbei.
00:59:11.069 --> 00:59:14.810
Wer noch fragen an die Beiden hat, kann
hier gleich einfach kurz nach vorne
00:59:14.810 --> 00:59:18.249
kommen. Erstmal möchte ich mich aber
herzlich bei euch beiden für diesen
00:59:18.249 --> 00:59:20.499
spannenden und interessanten
Vortrag bedanken.
00:59:20.499 --> 00:59:36.629
Applaus
00:59:36.629 --> 00:59:42.599
Abspannmusik
00:59:42.599 --> 01:00:01.000
Untertitel erstellt von c3subtitles.de
im Jahr 2017. Mach mit und hilf uns!