Jusletter IT

Datenschutz im Future Internet: rechtliche Aspekte und technische Maßnahmen

  • Authors: Christoph Sorge / Ronald Petrlic
  • Category: Articles
  • Region: Germany
  • Field of law: Data Protection
  • Collection: Tagungsband IRIS 2014
  • Citation: Christoph Sorge / Ronald Petrlic, Datenschutz im Future Internet: rechtliche Aspekte und technische Maßnahmen, in: Jusletter IT 20 February 2014
Das Future Internet soll den Anforderungen heutiger und zukünftiger daten-intensiver Internet-Anwendungen besser gerecht werden als dies heute der Fall ist. Seit einigen Jahren wird an unterschiedlichen Verfahren geforscht, die das «Future Internet» ermöglichen sollen – diese Ansätze gehen weit über die Ziele von IPv6 hinaus. In diesem Beitrag stellen wir einige Kernpunkte der Future-Internet-Initiativen vor und identifizieren Gemeinsamkeiten der unterschiedlichen Konzepte. Wir beleuchten die Konsequenzen aus datenschutzrechtlicher Sicht und geben einen Überblick über Ansätze, die die identifizierten Datenschutz-Probleme durch technische Maßnahmen bis zu einem gewissen Grad verhindern.

Inhaltsverzeichnis

  • 1. Einleitung
  • 2. Gemeinsamkeiten von Future-Internet-Architekturen
  • 3. Folgen für den Datenschutz aus technischer Sicht
  • 4. Rechtliche Fragestellungen
  • 4.1. Fehlende Trennung zwischen Inhalten und Kommunikation
  • 4.2. Kontrolle über Verbreitung von Inhalten
  • 4.3. Inhaltsbasiertes Sicherheitskonzept
  • 4.4. Kenntnisnahme abgerufener Inhalte durch Dritte
  • 5. Fazit
  • 6. Danksagung
  • 7. Literatur

1.

Einleitung ^

  Die Architektur des Internets ist im Kern bereits mehrere Jahrzehnte alt – ein Zeitraum, in dem sich die über das Internet genutzten Anwendungen und damit die Anforderungen an die Architektur drastisch verändert haben. Dass das Internet auch neue Anforderungen erfüllen kann, spricht zwar für die Qualität des ursprünglichen Entwurfs; dennoch sind im Laufe der Zeit Probleme entstanden, die nicht befriedigend innerhalb der ursprünglichen Systematik dieses Entwurfs gelöst werden konnten.Das Internet Protocol (IP) ermöglicht es – sowohl in der momentan noch am weitesten verbreiteten Version 4 als auch in der aktuelleren Version 6 – jedem Teilnehmer des Internets, jedem anderen Teilnehmer, dessen IP-Adresse er kennt, Daten in Form einzelner, voneinander unabhängiger IP-Pakete zu schicken. Alle darüber hinausgehenden Dienste wie beispielsweise die Übertragung von Websites über das Hypertext Transfer Protocol bauen letztlich auf IP auf: Soll auf einem Rechner eine Website angezeigt werden, muss der Server identifiziert werden, der diese Website anbietet, und dann eine Verbindung zu diesem Server hergestellt werden. Insbesondere beim Abruf großer Datenmengen (wie z.B. Videos) ist dieser Ansatz problematisch, da bei einem einzelnen Server und in dessen netztopologischer Umgebung eine große Last entsteht.Die Quelle, von der er die Inhalte bezieht, ist für den Abrufenden (Client) jedoch irrelevant, solange die Inhalte selbst unverändert sind. Der heute übliche Lösungsansatz für die Bereitstellung von großen Datenmengen, die von einer Vielzahl von Nutzern abgerufen werden sollen, besteht in der Nutzung sogenannter Content Delivery Networks (CDN). Die Betreiber der CDNs schließen Verträge mit den Inhalteanbietern und übernehmen die Verteilung; für diesen Zweck werden die Inhalte auf geographisch und netztopologisch verteilten Servern bereitgehalten. Nach einer Schätzung von Cisco1 wird im Jahr 2017 etwa die Hälfte des globalen Internetverkehrs von CDNs herrühren. Es muss sich jeder Inhalteanbieter selbst darum kümmern, dass seine angebotenen Inhalte auf diese Weise erreicht werden können – oder er muss die entstehenden Überlastsituationen in Kauf nehmen.Unbefriedigend ist die Verwendung von CDNs aus Sicht der IT-Sicherheit. Üblicherweise wird die Authentizität von Inhalten im heutigen Internet nur indirekt durch Etablierung eines sicheren Transportkanals mit Hilfe des Transport Layer Security (TLS)-Protokolls garantiert. Der Client kann überprüfen, ob er mit dem gewünschten Server kommuniziert; der Server muss dazu ein Zertifikat vorlegen und die Kenntnis des zugehörigen privaten Schlüssels nachweisen. Soll dies auch beim Einsatz eines CDNs ermöglicht werden, benötigt jeder Server des CDNs ein für die jeweilige Website passendes Zertifikat nebst dem zugehörigen privaten Schlüssel.Insgesamt kann also das Problem von Überlastsituationen bei einzelnen Servern sowie im Netz gelöst werden, doch ist die Lösung recht komplex. Ähnliches gilt für andere Probleme, die beispielsweise durch eine wachsende Anzahl mobiler Endgeräte oder – im Kontext des Internets der Dinge – durch eine zu erwartende Explosion der Gesamtzahl aller teilnehmenden Endgeräte ausgelöst werden.Die genannten Probleme – und weitere, die sich für die (zukünftige) Internet-Architektur stellen – werden seit einigen Jahren in einer Reihe von Forschungsinitiativen untersucht, die unter dem Oberbegriff «Future Internet» neue Herangehensweisen an die Kommunikation im Internet – weit über die Ziele von IPv6 hinausgehend – propagieren. Sowohl eine schrittweise Evolution als auch «clean slate»-Ansätze werden dabei diskutiert. Ein Schwerpunkt liegt dabei auf Lösungen für die Verteilung von Inhalten (im Gegensatz zu interaktiven Anwendungen wie Online-Banking oder Online-Shops, die allerdings nur einen kleinen Anteil des im Internet transportierten Datenvolumens ausmachen). Erste Ansätze hin zu einem «data-oriented network», bei dem der Fokus auf der Bereitstellung und dem Abruf von Daten im Future Internet liegt, und nicht auf (einfachen) Punkt-zu-Punkt-Verbindungen wie es im heutigen Internet der Fall ist, gehen auf das TRIAD-Projekt aus dem Jahre 2000 zurück.2 Sicherheit spielte bei diesem Ansatz, wie auch beim ursprünglichen Design des heutigen Internets, keine wesentliche Rolle. In der «Data-Oriented Network Architecture» (DONA)3 wurde ein Fokus auf das Caching von Inhalten im Future Internet gelegt. Seit dem Vorschlag von «content-centric networking»4 im Jahre 2009 wird wieder vermehrt am «Future Internet» geforscht. In diesem Beitrag werden wir uns auf diese Ansätze, die als «information-centric networks» oder «content-centric networks» bezeichnet werden, beschränken. Zwar sind die vorgeschlagenen Ansätze nicht deckungsgleich, aber einige Gemeinsamkeiten lassen sich identifizieren – eine Übersicht über Gemeinsamkeiten von Future-Internet-Architekturen folgt im nächsten Abschnitt.

2.

Gemeinsamkeiten von Future-Internet-Architekturen ^

[1]

Ghodsi et al.5 identifizieren als Gemeinsamkeiten der vorgeschlagenen Ansätze die folgenden Konzepte:

  • Publish/Subscribe-Konzept: Beim Publish/Subscribe-Konzept gibt es die zwei Grundfunktionen «Publish» und «Subscribe». Inhalteanbieter geben per «Publish» die Verfügbarkeit von bestimmten Inhalten bekannt. Inhalte werden über «Subscribe» angefragt und bezogen. Im Unterschied zum bisherigen Angebot z.B. von Websites, das sich ebenfalls durch diese Grundfunktionen beschreiben ließe, ist das Publish/Subscribe-Konzept in Future-Internet-Konzepten bereits Teil der Architektur. In der Regel muss der Nutzer den Namen des Inhalts kennen, um eine Subscribe-Operation durchführen zu können. Publish/Subscribe erlaubt eine örtliche und zeitliche Entkopplung von Anfragen und Antworten: Anfrager und Bereitsteller von Inhalten müssen die Adressen der Partner nicht kennen (wie es bei der IP-basierten Kommunikation im Internet der Fall ist); außerdem müssen Anfrager und Bereitsteller nicht zur selben Zeit online sein. Im TRIAD-Projekt wurde erstmals vorgeschlagen, das Publish/Subscribe-Konzept als das dem Internet zugrundeliegende Paradigma umzusetzen.6
  • Universales und universelles Caching: Netzknoten (z.B. Router), die eine Anfrage für einen bestimmten Inhalt erhalten, prüfen in einem ersten Schritt ob, sie den Inhalt im lokalen Cache vorhalten und antworten im Erfolgsfall mit diesem Inhalt. Andernfalls fragt der Knoten den Inhalt bei (Nachbar-)Knoten an, speichert den Inhalt in seinem lokalen Cache für mögliche zukünftige Anfragen und leitet den Inhalt an den anfragenden Knoten weiter. Caching wird auf allen Netzwerkknoten der Infrastruktur7 implementiert (universell) und erfolgt unabhängig von dem Kommunikationsprotokoll (universal). Eine weitere wesentliche Eigenschaft des Caching im Future Internet – im Gegensatz zu CDNs im heutigen Internet – ist die Anwendung für jeglichen Inhalt von allen Teilnehmern (universell). Dies «demokratisiert»8 die Bereitstellung von Inhalt.
  • Inhaltsbasiertes Sicherheitskonzept: Das Sicherheitsmodell im «heutigen» Internet basiert im Wesentlichen auf der Quelle des Inhalts: Der Client baut eine Verbindung zum Inhalteanbieter (Server) auf und bezieht die Daten direkt von diesem Server; kommt TLS zum Einsatz, so kommuniziert der Client vertraulich mit dem Server und beide Instanzen können sowohl die Authentizität des Datenursprungs als auch die Unversehrtheit während der Übertragung sicherstellen. Bei allen bisher vorgestellten Ansätzen zum Future Internet ist dieser Sicherheits-Ansatz nicht möglich: Es gibt keine direkte logische Ende-zu-Ende-Verbindung zwischen Client und Server; der Inhalt der vom Client angefragt wird, kann von einem beliebigen Knoten im Netz bereitgestellt werden. Damit ergibt sich die Anforderung für ein inhaltsbasiertes Sicherheitskonzept. Die Grundidee hinter diesem Ansatz besteht darin, dass der ursprüngliche Inhalteanbieter den Inhalt digital signiert und die weiterleitenden Netzwerkknoten sowie der anfragende Client die Authentizität und Integrität des Inhalts durch die Verifikation der Signatur sicherstellt.

3.

Folgen für den Datenschutz aus technischer Sicht ^

[2]

Lauinger et al.9 identifizieren die Preisgabe von Informationen durch Caches («Information leakage through caches») und Zensur und Überwachung («Censorship and surveillance») als potentielle Gefahren hinsichtlich Datenschutz beim Named Data Networking, das einen Ansatz zur Implementierung des Future Internets darstellt. Die Cache-Privacy-Problematik wird im Future Internet zu einem größeren Problem als im heutigen Internet.

[3]
Bereits heute sind im Internet Angriffe10 bekannt, die auf Antwortzeiten von DNS-Caches zielen. Ein DNS-Server, der z.B. nach der IP-Adresse zur Domain www.upb.de gefragt wird, kann schneller antworten, falls die Antwort bereits in seinem Cache liegt («Cache Hit»). Dies ist genau dann der Fall, wenn der DNS-Server bereits kurz vorher nach der gleichen Domain gefragt wurde und die Antwort daraufhin im Cache zwischengespeichert hat. Allerdings ist es schwierig, die gewonnenen Informationen eindeutig Nutzern zuzuordnen, weil oft eine Vielzahl von Nutzern denselben DNS-Resolver nutzt.
[4]
Da in vorgeschlagenen Future-Internet-Architekturen, wie in Abschnitt 2 besprochen, ein universales Caching eingesetzt wird, trifft die Cache-Privacy-Problematik nicht nur auf DNS-Anfragen zu, sondern vielmehr auf Informationen zu Inhalten. Damit wird es nicht nur möglich nachzuvollziehen welche Websites bspw. ein Nutzer angefragt hat, sondern vielmehr auch welche Inhalte. Durch die Kombination von Abbildungen, die in einem Online-Shop verwendet werden, lässt sich bspw. Nachvollziehen, für welche Produkte sich Nutzer interessieren. Verschärft wird diese Problematik im Future Internet dadurch, dass die Zahl von Nutzern, die einen gemeinsamen Cache verwenden – etwa in einem gemeinsamen Haushalt oder im Unternehmen – wesentlich geringer sein kann als bei der gemeinsamen Verwendung von DNS-Resolvern. Zudem führt das universelle Caching dazu, dass Caches an (nahezu) allen Netzwerkknoten im Future Internet verwendet werden und damit die Angriffsfläche weiter steigt.
[5]
Die zweite Problematik, die Lauinger et al. identifizieren, liegt darin, dass durch die Verwendung von eindeutigen Namen im Future Internet – und hier speziell beim Named-Data-Networking-Ansatz – mehr Informationen zu den übertragenen Daten preisgegeben werden, als es im heutigen Internet der Fall ist. Dies erleichtert es unter Umständen Regierungen und Unternehmen, bestimmte Inhalte (basierend auf deren Namen) zu blockieren.
[6]

Acs et al.11 begegnen in ihrem Ansatz der Cache-Privacy-Problematik dadurch, dass sie eine künstliche (zufällige) Verzögerung für Caches vorschlagen. Die Autoren weisen darauf hin, dass nicht sämtlicher Inhalt als «privat» (in unserem Sinne: problematisch aus Datenschutzsicht) eingestuft werden sollte, da dies zu unverhältnismäßigen Verzögerungen führen würde. Stattdessen schlagen sie vor, ein «privacy bit» einzuführen, das von Nutzern und/oder Inhalteanbietern nur für bestimmte Inhalte gesetzt werden sollte und damit die Netzwerkknoten zu künstlichen Cache-Verzögerungen dieser Inhalte auffordert. Im Online-Shopping-Beispiel von oben könnte dies bedeuten, dass die Produkt-Abbildungen vom Shop-Betreiber als privat markiert würden und es Angreifern damit nicht mehr möglich wäre, anhand von Cache-Antwortzeiten auf angesehene/bestellte Produkte von Nutzern zu schließen – einzig, dass die Website des Online-Shops aufgerufen wurde, lässt sich gegebenenfalls feststellen (da das «privacy bit» nicht gesetzt wurde, die Website aber im Cache vorgehalten wurde).

4.

Rechtliche Fragestellungen ^

[7]
Zwar sind die vorgeschlagenen Änderungen an der Internet-Architektur eigentlich technischer Natur, doch haben sie auch juristische Konsequenzen, die wir (auf Basis des deutschen Rechts) an dieser Stelle anreißen. Im Wesentlichen zeichnen sich vier Problemfelder ab:
  • Der Abruf einer Website bzw. eines Inhalts lässt sich bislang leicht in einen reinen Telekommunikationsvorgang (an dem mehrere Dritte beteiligt sein können) und den eigentlichen Informations- oder Kommunikationsdienst (der ausschließlich zwischen Diensteanbieter und Nutzer abgewickelt wird) unterteilen. Diese Trennlinie verschwimmt in Future-Internet-Architekturen, da die Bereitstellung von Inhalten bereits in die Internet-Architektur integriert wird (Publish/Subscribe-Konzept).
  • Durch universelles Caching verliert derjenige, der Inhalte bereitstellt, die Kontrolle über deren Verbreitung.
  • Das inhaltsbasierte Sicherheitskonzept ist nicht dazu geeignet, Vertraulichkeit von Inhalten sicherzustellen, sondern sichert nur die Integrität und Authentizität.
  • Durch Caching werden ggf. auch Informationen über abgerufene Inhalte für unbefugte Dritte verfügbar.
[8]
Wir diskutieren diese Problemfelder in den folgenden Abschnitten.

4.1.

Fehlende Trennung zwischen Inhalten und Kommunikation ^

[9]

Future-Internet-Konzepte unterscheiden sich von Content Delivery Networks darin, dass Inhalte nicht nur von einer anderen Stelle bereitgestellt werden als dem eigentlichen Inhalteanbieter, sondern bereits die Anfrage nicht spezifisch an den Inhalteanbieter gerichtet ist. Die Abgrenzung zwischen Telekommunikationsdiensten (§3 Nr. 24 TKG), telekommunikationsgestützten Diensten (§3 Nr. 25 TKG) und Telemedien (§1 Abs. 1 Satz 1 TMG) ist bereits in der derzeitigen Internetarchitektur nicht immer unproblematisch, wie sich beispielsweise beim Versuch einer Einordnung von Peer-to-Peer-Systemen zeigt12.

[10]

Für Future-Internet-Architekturen ist zunächst die Frage zu beantworten, ob und durch wen hier Telekommunikationsdienste erbracht werden, also «in der Regel gegen Entgelt erbrachte Dienste, die ganz oder überwiegend in der Übertragung von Signalen über Telekommunikationsnetze bestehen» (§3 Nr. 24 TKG). Wird eine Anfrage nach einem Video durch einen (mit einem Cache versehenen) Router beantwortet, werden nicht ausschließlich Signale übertragen; auch die Zwischenspeicherung ist ein wesentliches Merkmal des Dienstes. Für diese Auffassung spricht auch, dass der Gesetzgeber die Frage nach der Verantwortlichkeit für in Caches vorgehaltene Inhalte im TMG (§9) regelt13 – dies wäre systemwidrig, würde man Caches ausschließlich als Teil der Signalübertragung ansehen. Dieses Ergebnis ist zunächst unabhängig von der konkreten Ausgestaltung der Internet-Architektur.

[11]
Damit ist allerdings noch nicht ausgeschlossen, dass Caches Teil eines Dienstes sind, der überwiegend in der Übertragung von Signalen über Telekommunikationsnetze besteht. Ein solcher Dienst wäre nach wie vor Telekommunikationsdienst, aber nach §1 Abs. 1 Satz 1 TMG gerade nicht aus dem Anwendungsbereich des TMG ausgenommen. In der Tat lässt sich die Auffassung vertreten, es sei letztlich das Ziel auch von Future-Internet-Ansätzen, Daten (in Form von Signalen) zwischen zwei Kommunikationspartnern zu übertragen. Dass aus technischer Sicht gar keine Kommunikationsverbindung zwischen dem Ersteller der Inhalte und deren Nutzer hergestellt wird, würde demnach keine Rolle spielen; letztlich könnte man von einer Übertragung ausgehen, die nur ggf. durch eine Zwischenspeicherung unterbrochen oder verzögert wird.
[12]
Andererseits ist aber die Grundlage der vorgestellten Future-Internet-Architekturen die Idee, keine Verbindung zwischen dem Ersteller der Inhalte und deren Nutzer herzustellen, sondern die Inhalte selbst möglichst effizient bereitzustellen. Diese Sichtweise spricht für die Einordnung der Caching-Infrastruktur als Informations- bzw. Kommunikationsdienst und somit letztlich als Telemediendienst.
[13]
Von der Entscheidung zwischen beiden Ansätzen hängt ab, welche datenschutzrechtlichen Regelungen zur Anwendung kommen. Für Telemedien, die nicht auch Telekommunikationsdienste sind, gelten lediglich die Datenschutzvorschriften des TMG (sowie ggf. ergänzend das Bundesdatenschutzgesetz bzw. die jeweiligen Landesdatenschutzgesetze). Für Telekommunikationsdienste, die überwiegend in der Übertragung von Signalen über Telekommunikationsnetze bestehen, gelten nach §11 Abs. 3 TMG aus dem Datenschutzabschnitt des TMG lediglich § 15 Abs. 8 (betreffend die Speicherung von Nutzungsdaten bei Anhaltspunkten für die Nutzung des Dienstes in der Absicht, das dafür vorgesehene Entgelt nicht bzw. nicht vollständig zu entrichten) und die zugehörige Bußgeldvorschrift (§ 16 Abs. 2 Nummer 4); ansonsten kommen die Regelungen des TKG zur Anwendung.
[14]
Der jetzige Entwicklungsstand der vorgeschlagenen Internet-Architekturen lässt allerdings noch keine Entscheidung zu, welcher der beiden Einordnungen zutreffend sein wird; entscheidend wird hier die Schnittstelle für den Nutzer und die Frage sein, ob ihm gegenüber der Eindruck einer Übertragung von einem bestimmten Diensteanbieter vermittelt wird, also letztlich durch den Nutzer ein Telekommunikationsvorgang mit diesem Diensteanbieter intendiert ist.

4.2.

Kontrolle über Verbreitung von Inhalten ^

[15]
Aus datenschutzrechtlicher Sicht ist wünschenswert, auch die Entfernung von Inhalten zu ermöglichen. Werden personenbezogene Daten gespeichert, können sich z.B. Berichtigungs- oder Löschungsansprüche nach §35 BDSG ergeben. Durch die Verankerung von Caches in der Internet-Architektur wird es dem Anbieter von Inhalten erschwert, solche kurzfristig zu löschen. Das Problem lässt sich allerdings auf technischem Weg lösen.

4.3.

Inhaltsbasiertes Sicherheitskonzept ^

[16]
Das inhaltsbasierte Sicherheitskonzept der Future-Internet-Architekturen betrachtet lediglich Authentizität und Integrität von Daten; die Vertraulichkeit der Übertragung kann damit jedoch nicht sichergestellt werden. Eine vertrauliche Übertragung der Inhalte würde auch nicht zu den Architekturen passen, die ja gerade die Vorteile des Caching ausnutzen sollen. Eine Möglichkeit zu vertraulicher Kommunikation muss also daneben zusätzlich vorgesehen werden.
[17]
Für diejenigen Inhalte, die gemäß den Future-Internet-Konzepten verteilt werden, besteht auch keine gesetzliche Anforderung, wonach deren Vertraulichkeit sichergestellt werden soll. Vielmehr fordert §13 Abs. 4 Nr. 3 TMG, dass «der Nutzer Telemedien gegen Kenntnisnahme Dritter geschützt in Anspruch nehmen kann» – es ist also lediglich der Schutz von Metadaten erforderlich.

4.4.

Kenntnisnahme abgerufener Inhalte durch Dritte ^

[18]
Das größte Datenschutzproblem bestehender Future-Internet-Konzepte dürfte allerdings im Bereich des Abrufs von Inhalten aus Caches liegen. Die Integration von Caches in die Internet-Architektur führt zunächst dazu, dass der Betreiber eines Caches nicht mehr zwingend in einem Vertragsverhältnis mit dem Diensteanbieter (wie bei Content Delivery Networks) oder dem Nutzer (wie es beispielsweise beim Einsatz von Web-Caches in heutigen Unternehmensnetzen vorkommt) steht. Dies macht ihn nicht zwingend zu einem «Dritten» im Sinne des §13 Abs. 4 Nr. 3 TMG, vergrößert aber den Kreis derjenigen, die davon Kenntnis haben, welche Nutzer einen bestimmten Inhalt abgerufen haben. Problematisch ist dies insbesondere dann, wenn auch die Rechner von Privatpersonen beim Caching mit einbezogen werden – eine Option, die allerdings in den gängigen Future-Internet-Konzepten nicht notwendig ist.
[19]
An der jeweiligen Diensterbringung und dem zugehörigen Telekommunikationsvorgang nicht beteiligt – und damit ohne Zweifel «Dritte» sind aber andere Nutzer des jeweiligen Caches. Wie in Abschnitt 3 beschrieben, lässt sich durch Analyse der Antwortzeiten bestimmen, ob ein bestimmter Inhalt aus dem Cache geliefert wird. Ist dies der Fall, bedeutet dies, dass ein anderer Nutzer des Caches den jeweiligen Inhalt abgerufen hat. Zwar steht damit noch nicht fest, welcher Nutzer dies war; gegebenenfalls kommen aber nur wenige Nutzer in Frage. Der Diensteanbieter, der den Inhalt bereitstellt, kann also nicht garantieren, dass Dritte keine Kenntnis darüber erlangen, wer diesen Inhalt abgerufen hat.
[20]
Auch der Cache-Betreiber ist aber Diensteanbieter im Sinne des §2 Satz 1 Nr. 1 TMG, da hierfür nur erforderlich ist, dass er «eigene oder fremde Telemedien zur Nutzung bereithält oder den Zugang zur Nutzung vermittelt». Er hat also ebenfalls Schutzmaßnahmen zu treffen.

5.

Fazit ^

[21]
Momentan diskutierte Future-Internet-Architekturen versprechen erhebliche Effizienzgewinne durch die verteilte Speicherung von Daten, so dass Inhalte netztopologisch nah an den Nutzern liegen und automatisch repliziert werden, wenn dies nötig ist. Damit können nicht nur Anwendungen beschleunigt werden, die einen Großteil des Internetverkehrs ausmachen, sondern es geht damit auch eine Vereinfachung im Vergleich zum jetzigen Status Quo einher. Auch Kritik an diesen Ansätzen, wie sie beispielsweise Ghodsi et al. geäußert haben, soll aber nicht verschwiegen werden.
[22]
Gleichzeitig entstehen mit den Vorschlägen für die Zukunft des Internets neue Risiken für den Datenschutz, die erst seit kurzem in der technischen Literatur diskutiert werden – insbesondere das universale Caching führt zu Problemen. Bestehende Lösungsansätze sind zwar vielversprechend; es ist aber die Aufgabe des Rechts, im Fall einer Umsetzung der Future-Internet-Konzepte auch die tatsächliche Umsetzung technischer Lösungen einzufordern, um nicht hinter das momentan bestehende Datenschutzniveau zurückzufallen.

6.

Danksagung ^

[23]
Der vorliegende Beitrag wurde durch finanzielle Unterstützung der Deutschen Forschungsgemeinschaft im Rahmen des Sonderforschungsbereichs 901 «On-The-Fly Computing» an der Universität Paderborn ermöglicht.

7.

Literatur ^

Acs, Gergely/Conti, Mauro/Gasti, Paolo/Ghali, Cesar/Tsudik, Gene, Cache Privacy in Named-Data Networking, Proceedings of the 33rd International Conference on Distributed Computing Systems (ICDCS), IEEE Computer Society Library (2013).

Cheriton, David R./Gritter, Mark, TRIAD: A New Next-Generation Internet Architecture, http://gregorio.stanford.edu/triad/ aufgerufen 3. Januar 2014 (2000).

CISCO, Cisco Visual Networking Index: Forecast and Methodology, 2012–2017, White Paper, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white
_paper_c11-481360.pdf
aufgerufen 3. Januar 2014 (2013).

Elschner, Günter. Teil 22.1 Elektronische Arbeitnehmerüberwachung, in Hoeren/Sieber/Holznagel, Handbuch Multimedia-Recht: Rechtsfragen des elektronischen Geschäftsverkehrs. C.H. Beck, München, auf dem Stand der 35. Ergänzungslieferung (2013).

Ghodsi, Ali/Shenker, Scott/Koponen, Teemu/Singla, Ankit/Raghavan, Barath/Wilcox, James, Information-Centric Networking: Seeing the Forest for the Trees, Proceedings of the 10th ACM Workshop on Hot Topics in Networks (HotNets-X), New York, Association for Computing Machinery (ACM), S. 1–6 (2011).

Jacobson, Van/Smetters, Diana K./Thornton, James D./Plass, Michael F./Briggs, Nicholas H./Braynard, Rebecca L., Networking named content, Proceedings of the 5th international conference on Emerging networking experience and technologies (CoNEXT’09), New York, Association for Computing Machinery (ACM), S. 1–12 (2009).

Koponen, Teemu/Chawla, Mohit/Chun, Byung-Gon/Ermolinskiy, Andrey/Kim, Kye Hyun/Shenker, Scott/Stoica, Ion, A data-oriented (and beyond) network architecture, Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM’07), New York, Association for Computing Machinery (ACM), pp. 181–192 (2007).

Krishnan, Srinivas/Monrose, Fabian, DNS prefetching and its privacy implications: when good things go bad, Proceedings of the 3rd USENIX conference on Large-scale exploits and emergent threats: botnets, spyware, worms, and more (LEET’10), Berkeley, USENIX Association (2010).

Lauinger, Tobias/Laoutaris, Nikolaos/Rodriguez, Pablo/Strufe, Thorsten/Biersack, Ernst/Kirda, Engin, Privacy risks in named data networking: what is the cost of performance, ACM SIGCOMM Computer Communication Review, New York, Association for Computing Machinery (ACM), S. 54–57 (2012).

Sorge, Christoph, Rechtliche Einordnung Peer-to-Peer-basierter Dienste, in: 10 Jahre IRIS: Bilanz und Ausblick. Tagungsband des 10. Internationalen Rechtsinformatik Symposions IRIS 2007, S. 336–344, Richard Boorberg (2007).


 

Christoph Sorge

Universität Paderborn, Institut für Informatik, Fachgebiet Sicherheit in Netzwerken

Warburger Straße 100, 33098 Paderborn, DE

christoph.sorge@uni-paderborn.dehttp://www.cs.uni-paderborn.de/

 

Roland Petrlic

Universität Paderborn, Institut für Informatik, Fachgebiet Sicherheit in Netzwerken

Warburger Straße 100, 33098 Paderborn, DE

ronald.petrlic@uni-paderborn.dehttp://www.cs.uni-paderborn.de/

 


 

  1. 1 Vgl. CISCO, Cisco Visual Networking Index: Forecast and Methodology, 2012–2017, White Paper (2013).
  2. 2 Cheriton/Gritter, TRIAD: A New Next-Generation Internet Architecture (2000).
  3. 3 Koponen/Chawla/Chun/Ermolinskiy/Kim/Shenker/Stoica, A data-oriented (and beyond) network architecture, Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM‘07), ACM, 2007.
  4. 4 Jacobson/Smetters/Thornton/Plass/Briggs/Braynard, Networking named content, Proceedings of the 5th international conference on Emerging networking experience and technologies (CoNEXT'09), ACM, 2009.
  5. 5 Vgl. Ghodsi/Shenker/Koponen/Singla/Raghavan/Wilcox, Information-Centric Networking: Seeing the Forest for the Trees, Proceedings of the 10th ACM Workshop on Hot Topics in Networks (HotNets-X), New York, ACM, S. 1–6 (2011).
  6. 6 Ebda.
  7. 7 Darüber hinaus ist auch Caching auf den Systemen der Endnutzer denkbar.
  8. 8 Vgl. Ghodsi et al. (oben Fn. 5).
  9. 9 Lauinger/Laoutaris/Rodriguez/Strufe/Biersack/Kirda, Privacy risks in named data networking: what is the cost of performance, ACM SIGCOMM Computer Communication Review, ACM (2012).
  10. 10 Krishnan/Monrose, DNS prefetching and its privacy implications: when good things go bad, Proceedings of the 3rd USENIX conference on Large-scale exploits and emergent threats: botnets, spyware, worms, and more (LEET’10), USENIX Association (2010).
  11. 11 Acs/Conti/Gasti/Ghali/Tsudik, Cache Privacy in Named-Data Networking, Proceedings of the 33rd International Conference on Distributed Computing Systems (ICDCS), IEEE Computer Society Library (2013).
  12. 12 Sorge, Rechtliche Einordnung Peer-to-Peer-basierter Dienste, in: 10 Jahre IRIS: Bilanz und Ausblick. Tagungsband des 10. Internationalen Rechtsinformatik Symposions IRIS 2007, S. 336–344, Richard Boorberg, 2007.
  13. 13 Darauf weist, noch auf das (durch das TMG abgelöste) Teledienstegesetz bezogen, bereits Elschner in Hoeren/Sieber/Holznagel, Multimedia-Recht, Teil 22.1 Rn. 122, hin.