Editorial: Firma pleite, Produkt platt, die Zweite
Wie können ans Internet angebundene Geräte weiter funktionieren, wenn der Hersteller pleite geht?
(c) dpa
An dieser Stelle richte ich meinen Dank an die vielen Leser, die mit
ausführlichen und konstruktiven Forumsbeiträgen auf meine sicher sehr
weitgehende Forderung aus dem
letzten Editorial
reagiert haben: Es wäre kein kleiner Eingriff in
die Gewerbefreiheit, wenn Hersteller künftig für alle Produkte, die auf
einen externen Server angewiesen sind, den Betrieb ebendieses Servers
auf geeignete Weise versichern lassen müssten. Denn neben dem Abschluss
der Versicherung müsste der Hersteller auch nötige Quellcodes und
Konfigurationsanleitungen bei der Versicherung hinterlegen, damit diese
im Versicherungsfall den Serverbetrieb übernehmen kann. Die Verbraucher
hätten so natürlich die Gewissheit, dass ihre Produkte nicht schon
wenige Tage nach dem Kauf unbrauchbar werden, die Hersteller aber eben
auch erheblichen zusätzlichen Aufwand.
Etliche Leser erwähnten weitere Geräte, die wegen Abschaltung von herstellereigenen Servern vorzeitig zu Elektroschrott wurden. Zwei Beispiele aus dem Bereich Fernsehen: Der Grundig Selexx PDR 5000 S DIG war einer der ersten digitalen Videorekorder. Er bezog aber das elektronische Fernsehprogramm von einem proprietären Server, der dann plötzlich abgeschaltet wurde. Danach konnte man seine alten Aufzeichnungen noch abspielen, aber keine neuen mehr anfertigen. Ein ähnliches Problem bekamen dieses Jahr auch Entertain-Altkunden der Telekom: Durch den Wechsel zu Magenta TV wurde der alte Receiver wertlos - ein Teil der Kunden hatte diesen anfangs als Kauf- und nicht als Mietgerät erworben. Und egal, ob Receiver-Kauf oder -Miete: Mit der Umstellung auf die neue Plattform waren die alten Aufzeichnungen alle futsch.
Möglichst auf IoT-Server verzichten
Wie können ans Internet angebundene Geräte weiter funktionieren, wenn der Hersteller pleite geht?
(c) dpa
User a1x
schreibt,
dass die
Internetprovider mit Schuld an dem Problem hätten, da die ganzen
IoT-Geräte hinter dem Heimrouter nicht aus dem Internet erreichbar
seien. Würden die Provider feste IPv6-Adressen verteilen und ihre
Router so konfigurieren, dass sie Verbindungsaufbauanfragen aus dem
Internet an die IoT-Geräte durchlassen, dann würden viele der
Herstellerserver überflüssig. Um nicht generell allen Traffic für
alle Geräte freizugeben, was viele Sicherheitslücken mit sich bringen
würde, würde es nach User a1x dabei reichen, wenn es eine
Standardmethode gäbe, mit der die Geräte einzelne Ports im Router
für Internet-Traffic freischalten könnten.
Ich pflichte a1x bei, dass so mancher externer Server überflüssig werden würde, wenn Smart-Home-Geräte verstärkt selber als Server agieren würden. Aber es gibt auch Gründe, die dagegen sprechen: Viele IoT-Geräte haben nur eine langsame CPU und sie müssen auch mit wenig RAM und ROM auskommen. Da passiert es schnell, dass die zusätzliche Einbindung eines embedded Servers den Hersteller zwingt, den nächstgrößeren und damit natürlich auch nächstteureren Chip zu verbauen. Auch die Gefahr von Prozessabstürzen, die dann die Nutzer jeweils zum Reboot des Geräts nötigen, ist bei Servern höher als bei Clients. Sind Smart-Home-Geräte fest verbaut, wird dazu der Anwender in vielen Fällen die Sicherung kurz ausschalten und dann wieder einschalten müssen. Es macht keinen Spaß, das zu tun, nur, weil ein "Script Kiddie" mal wieder Klingelstreiche spielt, also DDoS-Attacken gegen die bekannten Ports von smarten Türklingeln fährt.
Vor allem aber ist jeder offene Port auch eine potenzielle Sicherheitslücke. Wenn wir massenhaft IoT-Geräten erlauben, passiv auf Verbindungen aus dem Internet zu lauschen, dann müssen wir sicherstellen, dass diese Geräte regelmäßig mit Updates versorgt werden, und das insbesondere auch und gerade dann, wenn sie bereits kompromittiert sind. Man müsste also den IoT-Geräten ein besonders gehärtetes "inneres System" spendieren, das zum Beispiel nach dem Booten aus einem gesicherten ROM übernimmt, zunächst auf Updates prüft (wofür man wahrscheinlich dann doch wieder einen externen Server braucht) und erst dann die eigentliche Anwendung startet. Was passiert dann eigentlich, wenn gerade jemand auf die smarte Türklingel drückt, während die im Update-Prozess steckt?
Schnittstellen veröffentlichen statt Server versichern
User Beklugscheiden schreibt, dass die Kosten im Versicherungsfall in der Regel ziemlich hoch wären: "Da kann man locker pro KMU, welches pleite geht, mit einem Mitarbeiter kalkulieren." Und dieser Mitarbeiter muss dann so lange beschäftigt werden, wie die garantierte Betriebszeit des Servers beträgt. Bei einem wenig erfolgreichen Produkt - schließlich ist der Hersteller pleite gegangen - würde der ganze Aufwand dann für nur wenige Nutzer getrieben werden.
Beklugscheiden schlägt stattdessen vor, "eine offene passive Schnittstelle, mit der alle Funktionalität repliziert werden kann", zu spezifizieren. Diese Schnittstelle würde erst im Insolvenzfall veröffentlicht werden. Nach der Veröffentlichung könnten dann Drittanbieter oder ambitionierte Hobbyentwickler die entsprechende Lösung bauen. Damit vermeidet Beklugscheiden natürlich das Problem, dass Server für unter Umständen nur wenige Nutzer weiterbetrieben werden.
Warum ich generell eher gegen passive Schnittstellen bin, habe ich im vorherigen Abschnitt bereits erläutert. Die von Beklugscheiden vorgeschlagene Umstellung der IoT-Geräte von aktiver (Client-) auf passive (Server-)Betriebsart im Fall der Insolvenz des Herstellers beinhaltet aber noch weitere Probleme: Denn die Hersteller müssen bei dieser Lösung eine Schnittstelle implementieren, die im Regelbetrieb gar nicht verwendet wird, da sie ja erst bei Ausfall des Hersteller-Servers zum Tragen kommen soll. Entsprechend hoch ist die Gefahr, dass diese zusätzliche Schnittstelle suboptimal getestet wird, und am Ende daher nicht oder nur unzureichend funktioniert.
Stichhaltig ist Beklugscheidens Argument, dass die Versicherung einen hohen Aufwand mit dem Weiterbetrieb des Servers haben könnte. Nur: Versicherungen sind Spezialisten darin, die Höhe eines möglichen Schadens und die Eintrittswahrscheinlichkeit desselben im Vorhinein zu kalkulieren und ihre Kunden danach in Risikoklassen einzuteilen. Wer in einer Gegend mit hoher Einbruchsrate wohnt, zahlt viel mehr für eine Hausratversicherung als ein Bewohner einer besonders sicheren Gegend. Analog bei der Server-Weiterbetriebs-Versicherung: Wer seinen Code so organisiert, dass auf dem Server nur eine Standard-Datenbank läuft, die als Service von Cloud-Anbietern bezogen werden kann, der zahlt bei der Versicherung entsprechend viel weniger Beitrag als jemand, der 100 000 Zeilen proprietären Python-Code einreicht.
Durch die Risiko-Beurteilung der Server-Versicherungen dürfte es daher zunehmend zur Standardisierung der auf IoT-Geräte bezogenen Cloud-Server kommen. In der Folge davon könnten die Kosten für die Hersteller sogar mittelfristig sinken, weil eben nicht jeder Hersteller "das Rad neu erfinden" muss.
Vertrauen der Verbraucher verbessern
Einige Nutzer schreiben es direkt so, bei anderen meine ich, es zwischen den Zeilen herauslesen zu können: Weil sie schonmal erlebt haben, dass Produkte wegen Server-Abschaltung plötzlich unbrauchbar wurden, sind die User beim Kauf neuer Geräte eher zurückhaltend. Die genannte Versicherung würde somit zwar auf der einen Seite die Kosten für die Hersteller erhöhen, auf der anderen Seite aber das Vertrauen der Verbraucher steigern. Letzteres steigert dann auch die Umsätze. Ich persönlich gehe davon aus, dass die positiven Effekte überwiegen würden.