02.09.2016

Seite 1 von 9

eBlocker Labs: Smart-TV Studie v1

1 Einleitung Smarte Geräte sind im Trend und halten immer mehr Einzug in die Haushalte. Leider bergen sie häufig ein Risiko für die Privatsphäre, da sie unbemerkt Daten über das Nutzungsverhalten des Anwenders aufzeichnen und an Dritte weitergeben. Diese Studie in der Version v1 beschäftigt sich mit der Analyse der von Smart-TVs erfassten und weitergegeben Nutzungsdaten. In der ersten Version haben wir uns auf ein aktuelles Gerät von Samsung beschränkt. In weiteren Updates werden in den nächsten Monaten weitere Geräte hinzugenommen und die Untersuchung fortgeschrieben.

2 Zusammenfassung Bereits diese erste Untersuchung hat gezeigt, dass ein Samsung Smart-TV direkt nach Inbetriebnahme und dauerhaft während des Betriebs zahlreiche Internet-Anfragen (sog. Requests = Senden an und Abrufen von Daten eines Servers)an unterschiedliche Anbieter sendet. Diese Requests senden dabei in der Regel Daten über das Verhalten des Nutzers. Einige dieser Requests sind geeignet genaue Nutzungs- und Persönlichkeitsprofile zu erstellen. Viele Requests gehen an diverse Server von Samsung selbst. Aber darüber hinaus werden auch sehr viele Requests an kommerzielle Anbieter wie Netflix, Maxdome, TV-Digital, Ampya und andere gesendet. Dabei ist es ganz unerheblich, ob der Nutzer entsprechende Apps auf dem Gerät verwendet oder überhaupt einen Account bei einem dieser Anbieter besitzt. Requests im Kontext von HbbTV beziehen sich auf den gerade eingeschalten Sender. Entsprechende Requests an Serveradressen von ARD, ProSieben und anderen wurden beobachtet. Hierbei ist es wiederum unerheblich, ob der Nutzer HbbTV explizit aktiviert hat („Red Button“) oder nur das laufende Programm verfolgt. Requests an die Sender werden bereits abgesendet, sobald auf das Programm umgeschaltet wird. Bemerkenswert ist, dass einige dieser Requests sogar im StandBy-Modus abgesendet werden. Also wenn der normale Nutzer eigentlich davon ausgeht, dass das Gerät „ausgeschaltet“ ist. Einige Requests enthalten Identifizierungs-Cookies oder andere eindeutige Gerätekennungen, die sich auch nach Aus- und Wiedereinschalten des Gerätes nicht ändern. Diese sind daher geeignet, den Nutzer während der gesamten Lebensdauer des Smart-TV immer wieder zu erkennen.

3 Versuchsaufbau Untersucht wurde ein aktuelles Samsung Serie5 Smart-TV aus dem Jahr 2016 (UE40K5579). Das Smart-TV wurde in der Standardkonfiguration belassen, so wie es wohl die meisten Kunden verwenden würden.Das Gerät wurde bei keinem Inhalteanbieter aktiv registriert oder angemeldet und es wurde kein Abonnement für einen Pay-TV-Sender oder für andere Dienste abgeschlossen. Das Smart-TV wurde per Antennen-Kabel an das Netz von Kabel Deutschland angeschlossen. Im Sendersuchlauf wurden nur „freie“ Kanäle verwendet. Das Gerät wurde per WLAN in ein abgeschlossenes lokales Netz integriert. In diesem lokalen Netz wurden außer dem Smart-TV und dem WLAN-Router nur ein eBlocker sowie ein Laptop zur Auswertung der Daten betrieben. Das lokale Netz war per Kabel-Modem mit dem Internet verbunden.

4 Durchführung Das Smart-TV-Gerät wurde wie ein normales Fernsehgerät in verschiedenen Anwendungsfällen getestet. Der eBlocker wurde dazu verwendet, die vom Smart-TV jeweils abgesendeten http/https-Requests zu protokollieren und zu analysieren. Mit dieser Analyse ist der eBlocker anschließend in der Lage, die Requests zu Datensammlern und damit die Profilbildung aktiv zu unterbinden.

02.09.2016

Seite 2 von 9

Hierbei ist zu beachten, dass bei es sich bei den meisten untersuchten Anwendungsfällen nicht um spezifische Smart-TV-Anwendungen handelt, sondern um ganz normales „Fernsehen“, wie es auch schon vor 50 Jahren mit einem Röhrengerät möglich gewesen wäre. Folgende „Fernseher“-Anwendungsfälle wurden im Einzelnen untersucht: < Gerät im Standby-Modus < Einschalten des Geräts nach Trennung von Stromversorgung < Einschalten des Geräts aus dem StandBy < Längere Zeit im gleichen Programm verweilen < Kanalwechsel (verschiedene Wechsel zwischen ÖR und kommerziellen Sendern)

Es wurde jeweils untersucht, ob und welche https- oder http-Requests an Server im Internet geschickt wurden und was ggf. deren Inhalt ist. Insbesondere ob der RequestDaten enthält, die geeignet sind, das Gerät bzw. den Nutzer dauerhaft wieder zu erkennen und damit ein Persönlichkeitsprofil zu bilden.

4.1 https-Verbindungen (SSL-Verschlüsselung) Auf Grund der Ende-zu-Ende-Verschlüsselung von https-Verbindungen, kann der eBlocker bei solchen Requests nur feststellen, zu welcher Domäne bzw. zu welcher IP-Adresse die Verbindung aufgebaut wird. Er kann jedoch nicht den Inhalt der Anfrage analysieren.

4.2 http-Verbindungen Bei unverschlüsselten http-Requests kann der eBlocker die genaue URL sowie etwaige Meta-Daten der Anfrage analysieren und protokollieren. Hier ist insbesondere interessant, ob der Request Identifizierungs-Cookies oder ähnliche, eindeutige IDs enthält, über die das Gerät und damit der Nutzer dauerhaft erkannt werden kann und somit ein Profil der Gerätenutzung erstellt werden kann.

5 Ergebnisse In den folgenden Abschnitten sind die Untersuchungsergebnisse zu den unterschiedlichen Anwendungsfällen dokumentiert. Hierbei ist festzuhalten, dass Zeitpunkt, Reihenfolge und genaue URLs der Requests nicht konstant sind, so dass eine erneute Messung nicht immer exakt dieselben Ergebnisse liefert. Einige Requests werden regelmäßig abgesendet - selbst wenn sich das Gerät im StandBy-Modus befindet. Diese Requests sind also grundsätzlich unabhängig vom konkreten Anwendungsfall und werden nicht in jedem Abschnitt erneut aufgelistet, auch wenn sie immer wieder protokolliert wurden. Andere Requests werden dagegen nur abgesendet, wenn das Gerät sichtbar eingeschaltet ist, wenn ein bestimmter Sender ausgewählt ist, oder wenn zusätzliche Funktionen (wie HbbTV oder Apps) aktiviert wurden. Die Protokolle sind in diesem Sinne als Momentaufnahmen zu verstehen. Es wurde versucht, die Systematik zu ermitteln und entsprechend zu dokumentieren. Eine gewisse Unschärfe ist beim aktuellen Stand der Untersuchung jedoch unvermeidbar.

5.1 Gerät im StandBy-Modus Selbst im StandBy-Modus werden regelmäßig https- und http-Requests abgesendet. Bei https-Requests wird der Datenstrom zwischen dem Gerät und dem Server verschlüsselt. Bei http erfolgt die Datenübermittlung ohne Verschlüsselung und kann so von Dritten mitgelesen werden.

5.1.1 https-Requests Im StandBy-Modus wurden https-Requests zu folgenden Serveradressen beobachtet:

Domäne www.youtube.com (216.58.213.14)

02.09.2016

Seite 3 von 9

Ziel YouTube

Domäne i.ytimg.com (216.58.213.46) Ziel YouTube

Domäne www.google.com (216.58.213.36) Ziel Google

Domäne tvdstv.api.watchmi.tv (176.28.1.240) Ziel TV Digital

Domäne api-global.netflix.com (54.246.102.195) Ziel Netflix

Domäne ichnaea.netflix.com (46.137.159.196) Ziel Netflix

Domäne 50.112.116.33 Ziel Amazon AWS

Domäne multiscreen.samsung.com (52.25.243.102) Ziel Samsung

Domäne fkp.samsungcloudsolution.com (175.41.134.166) Ziel Samsung

Domäne noticecdn.samsungcloudsolution.com (54.192.77.5) Ziel Samsung

Domäne osb-eusvc.samsungqbe.com (52.28.38.189) Ziel Samsung

Domäne osb.samsungqbe.com (52.58.18.97) Ziel Samsung

5.1.2 http-Requests Im StandBy-Modus wurden folgende http-Requests aufgezeichnet. Da alle Daten bei http unverschlüsselt übertragen werden, konnte hier der Inhalt und der damit verbundene Zweck der Daten betrachtet werden.

Domäne samsung.images.dvbdata.com Ziel Axel Springer SE / dvbData / TV DIGITAL Online Vermuteter Zweck Standbilder (viele Requests) Tracking-Cookie/ID Nein

Domäne tv.ampya.com

02.09.2016

Seite 4 von 9

Ziel Ampya Vermuteter Zweck Musik-Empfehlungen Tracking-Cookie/ID X-SAMSUNG-PSID:

KA2JJ5WILFFA7DCMP6W3KK3312345678

Domäne cdn.samsungcloudsolution.com Ziel Samsung Vermuteter Zweck Verbindungstest Tracking-Cookie/ID Nein

Domäne 104.25.80.14 Ziel CloudFlare Vermuteter Zweck unbekannt Tracking-Cookie/ID Nein

Domäne youtube.com Ziel YouTube Vermuteter Zweck unbekannt Tracking-Cookie/ID Cookie: VISITOR_INFO1_LIVE=GZyhzXaABCD;

PREF=f1=50000000; yt-dev.persistent-cookie=1; GPS=1; YSC=KGlckI6XYZ0

Domäne s.ytimg.com Ziel YouTube Vermuteter Zweck Unbekannt / Bilder Tracking-Cookie/ID Nein

5.2 Einschalten nach Trennung von Stromversorgung Das Gerät wurde auf den Sender „ARD HD“ eingestellt, ausgeschaltet, ca. 30 Sekunden vom Stromnetz getrennt und wieder eingeschaltet. In den ersten zwei Minuten nach dem Einschalten wurden die folgenden Requests protokolliert:

5.2.1 https-Requests

Domäne lcprd2.samsungcloudsolution.net (54.246.181.131) Ziel Samsung

Domäne osb.samsungqbe.com (52.29.248.210) Ziel Samsung

Domäne script.ioam.de (91.215.103.64) Ziel InfoOnline (Datensammler zur Reichweitenanalyse)

Domäne 54.93.206.68 Ziel Amazon AWS

02.09.2016

Seite 5 von 9

Domäne configprd.samsungcloudsolution.net (54.229.31.255) Ziel Samsung

Domäne www.samsungotn.net (157.55.184.57) Ziel Samsung

Domäne otnprd9.samsungcloudsolution.net (54.235.198.13) Ziel Samsung

5.2.2 http-Requests

Domäne itv.ard.de Ziel ARD Vermuteter Zweck Website mit Bildern etc. (Overlay für Fernsehbild), viele Aufrufe Tracking-Cookie/ID Cookie: ardstart=rbp*1*rangeid*201608*ra*201608

*u*987654329278e27c8708ca54d9e4*v*3*ts*14719587

Domäne cdn.samsungcloudsolution.com Ziel Samsung Vermuteter Zweck unbekannt Tracking-Cookie/ID Nein

Domäne az43064.vo.msecnd.net Ziel unbekannt Vermuteter Zweck unbekannt – vermutlich Firmware Updates Tracking-Cookie/ID Nein

5.3 Andere Server und Kanalwelchsel Grundsätzlich wurde festgestellt, dass das Smart-TV-Gerät direkt nach einem Kanalwechsel Requests an eine Website des jeweiligen Senders schickt. Diese Requests enthalten in der Regel Identifizierungs-Cookies oder andere, eindeutige IDs, über die das Gerät und damit der Nutzer identifiziert werden kann. Einige Beispiele sind hier aufgeführt. Dabei ist zu beachten, dass je nach Sender in der Regel eine Vielzahl weiterer Requests abgesschickt wird.

Domäne prosieben.de URL http://redbutton-lb-prod.prosieben.de/subscribe/?

c=PRO7&amp;timeout=60000&amp;callback=rbcb1456796710845 Programm Pro 7 Tracking-Cookie/ID

Cookie: wt3_eid=%3B349963160860786%7C2147100842300020506; wrapped_proxy_v2=N4IgzgLg9gTgpiAXKAlgE.....PRVqXPNVVX8/ygA; wt3_sid=%3B349963160860786

Domäne sat1.de

02.09.2016

Seite 6 von 9

URL http://redbutton-lb-prod.sat1.de/subscribe/ ?c=SAT1&amp;timeout=60000&amp;callback=rbcb4204975981265

Programm Sat.1 Tracking-Cookie/ID

Cookie: wt3_eid=%3B349963160860786%7C2147100841600529408; wrapped_proxy_v2=N4IgzgLg9gTgpiAXKAlgE.....IesrykqipeV5QA=; wt3_sid=%3B349963160860786

Domäne rtl.de URL http://cdn.digitaltext.rtl.de/launchbar/index.html

Programm RTL Tracking-Cookie/ID

Cookie: smartns_uuid=91fc662f-xxxx-xxxx-xxxx-5eb0e152427c

Domäne rtl2.de URL http://hbbtv.rtl2.de/redbutton.php?cc=de

Programm RTL2 Tracking-Cookie/ID

Cookie: smartns_uuid=3b3edb4b-yyyy-yyyy-yyyy-6ef04c62b81c

Diese oder ähnliche Requests werden regelmäßig (z.B. minütlich) wiederholt, so dass der Sender im Prinzip recht genau verfolgen kann, ob und wie lange eine Sendung gesehen wird. Die Requests von Sendern aus der gleichen Sendefamilie gehen zwar an unterschiedliche URLs (z.B. „prosieben.de“ und „sat1.de“). Sie sind aber sehr ähnlich aufgebaut und verwenden teilweise die gleichen IDs in den Cookies, so dass es technisch kein Problem ist, diese Daten und damit das Fernsehverhalten auch senderübergreifend auszuwerten. Dazwischen sind immer wieder direkte Requests an bekannte Tracking-Dienste zu finden, die offfenbar im Kontext des jeweils gewählten Programms aktiv sind. Hier zwei Beispiele von RTL bzw. RTL2:

Domäne de.ioam.de URL http://de.ioam.de/tx.io?st=ctvrtldi&amp;cp=dbrscwf_tve_redbutton&amp;

co=%2Frtl_hbbtv_red_button&amp;pt=CP&amp;rf=&amp;r2=&amp; ur=cdn.digitaltext.rtl.de&amp;xy=1920x1080x24&amp; lo=DE%2FNordrhein-Westfalen&amp;cb=000d&amp;vr=308&amp; id=ap8m7o&amp;lt=1472652048688&amp;ev=&amp; cs=jdnp5o&amp;mo=0

Programm RTL Tracking-Cookie/ID

Cookie: i00=002e7cf1011730c5957a9f3ca0001%3B57a9f3ca%3B58f4c12d

Domäne etracker.de

02.09.2016

Seite 7 von 9

URL http://www.etracker.de/cnt.php?et=xjVHpm&amp;amp;v=3.0&amp;

amp;java=n&amp;amp;et_easy=0&amp;amp; et_pagename=Button_16&amp;amp;et_areas=HBB-TV&amp;amp; et_ilevel=0&amp;amp;et_target=,0,0,0&amp;amp;et_lpage=0&amp; amp;et_trig=0&amp;amp;et_se=0&amp;amp;et_cust=0&amp;amp; et_basket=&amp;amp;et_url=&amp;amp;et_tag=&amp;amp; et_sub=&amp;amp;et_organisation=&amp;amp;et_demographic=

Programm RTL2 Tracking-Cookie/ID

Nein

6 Fazit Das untersuchte Gerät ist unter Datenschutz- und Privatspähreaspekten eine Katastrophe. Es sendet permanent personenbezogenen Daten (wie die IP-Adresse des Nutzer) ohne Nutzerinteraktion und ohne dessen Einwilligung. Zudem werden eindeutige IDs und Cookies verwendet, die auch bei dynamischen, wechselnden IP-Adressen eine eindeutige Zuordung ermöglichen. Diese Daten sind geeignet sehr genaue Persönlichkeitsprofile über den Nutzer, seine Interesse und seine häuslichen Gewohnheiten wie z.B. Anwesenheitszeiten aufzuzeichnen. Der Datenversand ist durch Konfigurationseinstellungen nicht ohne weiteres abstellbar. Der Einsatz des Gerätes ohne weitere Schutzfunktion birgt daher große Risiken für die Privatsphäre des Anwenders.

7 Wie der eBlocker schützt Der eBlocker schützt in der aktuellen Version bereits vor dem unbemerkten Datenabgriff bei der Verwendung von HbbTV, da dort in der Regel „normale“ Datensammler verwendet, die dem eBlocker bereits bekannt sind. Dank der integrierten eBlocker Analysefunktion, die auch für diese Studie verwendet wurde, kann der über HbbTV hinausgehende Datenversand an Hersteller und Drittanbieter leicht erkannt und mit einfacher Definition von Blockierregeln unterbunden werden. Aktuell arbeiten wir an dem Aufbau einer Datenbank mit Regeldefinitionen für häufig verwendete smarte Geräte, die dann ganz einfach durch Nutzer dieser Geräte aktivert werden können. Es ist geplant, das eBlocker Anwender, die Geräte-spezifischen Regeln mit eBlocker und anderen Nutzern teilen können, so dass durch den Community-Effekt in kurzer Zeit viele smarte Geräte in der eBlocker Datenbank erfasst und abgesichert werden können.

02.09.2016

Seite 8 von 9

8 Anhang Beispiele für Protokoll-Daten des eBlockers (Screenshots):

8.1 Verschlüsselte https-Verbindungen

8.2 Protokollierte http-Requests Beispielhafte Darstellung von protokollierten Requests beim Einschalten des Gerätes:

02.09.2016

Seite 9 von 9

8.3 Requestdetails mit Cookie Beispielhafte Daten eines Requests bei dem ein Cookie gesetzt wird: