Davinci Resolve 14

You can be this guy.

I previously praised Blackmagic Design for their ability to democratize video production on the hardware end, enabling live broadcast production at a cutthroat price.

Now they’re promising to do the same on the software side. They somehow shoehorned a full NLE into their acquisition, Davinci Resolve, a color editing suite. And they managed to somehow merge the recent acquisition, Fairlight Audio into Davinci Resolve as well, in just six months.

So, after that little love letter of a press announcement from NAB, they now have a fully featured video NLE, a non-music DAW, and color correction suite. Cross-platform on Mac, Windows, and Linux (!), with the light, yet very useful version being free (as in beer), and the full Studio version at $299, down from $999, matching FCP X’s pricing.

Now granted, this is still in beta, and Blackmagic doesn’t have the very best track record of shipping super stable products all the time, every time. But this just might be the missing link between the non-existing open source NLE and Audacity at the bottom free end, and the Mac-bound FCP X, and the subscription-ridden Premiere Pro. There even is a fair(light) chance that the DAW part could be a good fit for audio podcasting use.

They also announced collaboration features, a free server that can simply run on a workstation, and visual diffing of versioned timelines.

Mind. Blown.

Try the beta!

Seat Leon: Stumme Pause

2006 präsentierte Steve Jobs den Fortschritt bei der iPod-Integration in der Autoindustrie: “70 percent of the new cars sold in the US offer iPod connectivity as an option.” Inzwischen hatten die Autohersteller über 10 Jahre Zeit, zumindest Bluetooth-Audio als standardmäßigen Nachfolger in die Fahrzeuge zu bringen. Abseits von Android Auto und CarPlay. Einfach nur Audio vom Telefon in das Autoradio. Was soll schon schiefgehen? Hier in einem brandneuen Seat Leon, vermutlich auch ähnlich bei anderen VW-Einsteiger-Radios:

Mangels Play/Pause-Taste am Lenkrad wird die Lautstärke dafür mitgenutzt. Lautstärke 0 = Pause. Lautstärke hoch = Play. Die Siri/Sprachbedienungs-Taste am Lenkrad ist in diesem Modell ohne Funktion, und während der Fahrt den resistiven Touchscreen zu bedienen ist lebensgefährlich. Im geparkten Auto bekommt man wenigstens nur einen Herzinfarkt, weil die Bedienung so grausam ungenau ist. Das iPhone über die eingebaute USB-Buchse zu laden, scheitert. Der Zigarettenanzünder für seriösen Strom ist in der Mittelarmlehne, und das Auto sähe bald wieder aus wie der Kabelsalat hinter meinem Fernseher.

Gut, die digitale Automobilindustrie bewegt sich langsamer als die übrige IT, aber sollten nicht wenigstens nach 10 Jahren mit Smartphones die Basics halbwegs bedienbar sein? Vor 6 Jahren habe ich hier die Integration in einem nicht sehr viel teureren BMW gezeigt:

Das war noch eine recht umständliche Lösung mit einer Dock-Connector-Cradle, aber das lief schon wesentlich runder als einfach nur den Seat als Bluetooth-Lautsprecher zu nutzen.

Gut, Hörer schreiben, dass die verkabelte CarPlay-Integration im größeren Radio bei Seat weniger stinkt (Aufpreis 600-1000 Euro), dafür ist Bluetooth und USB wohl auch bei Opel eine Katastrophe. VW musste wohl eine Reihe von neueren Fahrzeugen überarbeiten, weil der USB für CarPlay so wie hier im Seat auch zu wenig Strom geliefert hat.

Was das restliche Auto angeht:

Ich bin dieses Wochenende die ersten 1000km in diesem Seat gefahren, und der Blech- und Öl-Teil ist soweit klassentypisch akzeptabel, wenn auch keine große Freude am Fahren aufkommt. Insbesondere die Tempomat-Bedienung ist ganz besonders unintuitiv und ein permanentes Ärgernis, weil drei Tasten mit vier Funktionen belegt sind. Das bedeutet jeweils einen zusätzlichen Blick ins Display, um den State des Tempomats vor jedem Tastendruck zu erkennen. Ansonsten ist unklar, was der Klick jetzt gerade bedeutet. Der Tempomat-Zustand hat zwei Elemente: Eine grüne LED zeigt an, ob die Geschwindigkeit gerade aktiv geregelt wird. Die zuletzt gewählte Geschwindigkeit steht links unten im Display. An der gleichen Stelle, an der auch FrontAssist, der Radar-Abstandswarner und Bremsassistent recht großzügig ein zu dichtes Auffahren anzeigt. Diese Entscheidung kann ich nicht recht nachvollziehen, eine Position im Display für eine reine Information und gleichzeitig eine Gefahrenanzeige zu nutzen. Wie das System reagiert, wenn der Abstand wirklich kritisch wird, habe ich glücklicherweise nicht ausprobieren müssen. Vergleich zu Mercedes: Dort sind die vier Tempomat-Funktionen narrensicher auf zwei Achsen eines Hebels (rauf, runter, vor, zurück), und der Status wird als Leuchtring um den Tacho und als Einblendung im Display gezeigt.

Ein ähnliches Problem bei der Auswahl der Information, die im Mitteldisplay zwischen Tacho und Drehzahlmesser angezeigt werden: Die Auswahltaste am Lenkrad (Pfeil links/rechts) zeigt die Kategorien an (Audio / Fahrzeug / …) und hält diese Überschrift eine Sekunde auf dem Display, bevor die eigentliche Information angezeigt wird. Im Zweifel schaut der Fahrer eine Sekunde länger als nötig auf das Display statt auf die Straße, während er auf den Computer wartet. Gegenbeispiel bei Mercedes: Die Kategorie hat keinen eigenen Screen. Blättern auf dem Lenkrad zeigt sofort die Information (Bayern 3 / 100km/h / …). Bonus-Aufgabe für das Seat-Radio: Stell einen Sender ein, der noch nicht abgespeichert ist. Ich habe es nicht geschafft.

Im Bereich der rechten B-Säule ist bei höheren Geschwindigkeiten ein sehr aufdringliches Flattergeräusch (Wind?), das links fehlt und vermutlich nicht so gedacht ist. Der Beifahrer auf der Rückbank hat sich über einen kalten Luftzug beschwert und die Winterjacke wieder angezogen.

Fazit: 80 Jahre Erfahrung beim Blechbiegen helfen kein Stück bei UI und UX. Nach dieser ausführlichen Probefahrt ist klar: Die größten Schwächen von dem Auto sind nur in Software und nur ein Firmware-Update könnte aus dem vernichtenden Urteil eine mittelmäßige Empfehlung machen.

iOS App Review Subscription Metadata Rejection

I hope this saves someone from unnecessary rounds of App Store Review rejections. I needed three rounds to satisfy this new requirement. I think their language is, as observed previously, a little too unspecific, when they have a very clear idea of what they actually want to see in the app.

We noticed that your Application Content and Metadata did not fully meet the terms and conditions for auto-renewing subscriptions, as specified in Schedule 2, Section 3.8(b).

  • links to the privacy policy and terms of use

Naturally, that information was available inside the app for years already, since I started selling subscriptions, behind a “i” button in the navbar. It also had label directing users to tap the “i” for more information on the subscriptions. That didn’t fly.

What App Review actually wants is one-tap links or buttons labelled “Privacy Policy” and “Terms of use” or comparable.

Another new requirement: State the actual current price of the subscriptions in the app description. This appears to work around the broken list of in-app items in the App Store. Many apps list multiple prices for the same thing there.

Steve Jobs Confirmed the App Store Before the iPhone Launched

This video is from late May 2007, a month before the launch of the iPhone.

Buried in the Q&A section, there is this interesting statement about what would become the App Store. Starts at 49:50.

Question: Brian Dear from Eventful. Steve, all indications so far are that the iPhone is like you say, a beautiful piece of software wrapped in a beautiful piece of hardware.

Steve: Oh, thanks.

Brian Dear: And the fact that it’s running on OS X is a fantastic development. I think I would speak for many developers, perhaps thousands of independent developers who would love to write apps for that platform ’cause I believe it’s gonna be a tremendous platform for the future. But the indications are so far that it’s closed. If you could comment on that, and do you see it opening up for developers in the future?

Steve: Sure, it’s a good question. This is a very important trade off between security and openness, right? And what we want is: we want both. We wanna have our cake and eat it too. And so we’re working through a way… we’ve got some pretty good ideas that we’re working through. And I think some time later this year we will find a way to do that, because that is our intent.

Walt Mossberg: Find a way to open it up so that third party developers…

Steve: Find a way to let third parties write apps and still preserve the security.

Walt: But at the start until you get that in place…

Steve: Find a way… we can’t compromise the security of the phone. This is something that you have to…

Walt: Is this a network issue, is this an AT&T issue? What, when you say the security of the phone?

Steve: You know, I won’t mention names, but I’ve used, we’ve all used a lot of smart phones that crash more than once a day, and with the number of third party apps you put on them, the more they crash. And we don’t… we’re gonna… nobody’s perfect, but we’d sure would like our phone not to crash once a day or more. And so: We would like to solve this problem. I think we’re going down some really good avenues to do it. If you could just be a little more patient with us I think everyone can get what they want.

The question is about native apps like on OS X, and Steve confirms that they’re working on it, and that they want to lock down the platform.

At the WWDC Keynote in June 2007, just a few days later, at the end of the Mac-centric keynote, Steve did the spiel about the “Sweet Solution” for developers on iPhone, HTML Webapps in Safari. Starts at 1:13:20.

The real SDK wasn’t finished, and Steve’s slide says, there is no SDK, spinning it as something good.

Forstall even admits at the end of his demo that they had to look for some kind of a developer story for WWDC, while they were secretly already working on the real App Store that would launch one year later in the summer of 2008.

I think this shows that the narrative that Steve had to get convinced to let third party developers make apps very late in the game, and that the iPhone OS SDK and the App Store were not planned from the start, is wrong. The “Sweet Solution” was a classic RDF by Steve. The SDK simply wasn’t ready for the launch in 2007.

IT für bewegte Bilder

Wir haben in der Sondersendung Bits und so #503 (A Tape a Day) ausführlich über digitales Video gesprochen. Die Sendung gibt in rund drei Stunden einen Überblick über Soft- und Hardware für digitale Videoproduktion und spricht einige der Schwierigkeiten und Lösungsansätze und Workflows an.

Ich möchte hier nochmal einen Teilaspekt ansprechen, der auch in der Sendung kurz genannt wird, aber vielleicht zu kurz gekommen ist:

Ich glaube, an der Schnittstelle zwischen der Videoproduktion und der IT existiert eine interessante Unterversorgung. Die Systeme sind nicht mehr schwarze, unveränderbare Kisten von Sony, sondern lassen sich in größere IT-Umgebungen einbinden.

Es gibt viele Beispiele von erfolgreichen Firmen, die die Reibung an diesen Grenzen reduziert haben. Im Consumerbereich offensichtlich YouTube, Periscope oder Snapchat, die den Zugang zur Videodistribution erheblich vereinfacht haben und damit einer breiten Masse zugänglich gemacht haben.

Im B2B-Umfeld gibt es eine Anzahl von Firmen, die mit mehr oder weniger simplen Anwendungen erfolgreich sind. Einige nicht zwangsläufig repräsentative Beispiele:

  • SnappyTV ermöglicht das einfache Teilen von Ausschnitten von eigenem Bewegtbild auf sozialen Medien. Knapp $3M Finanzierung, von Twitter aufgekauft.
  • Bitmovin ist ein Wolkenservice, der Video in streambare Formate reenkodiert. Praktisch unabhängig von der Menge und Länge ist das Video in 10 Minuten verarbeitet. $10M Finanzierung.
  • Kasper Skaarhoj baut Control Surface Hardware für die Videoproduktion.
  • LiveU scheint Videozuspielung, traditionell über Satellit, erfolgreich auf (drahtlose) IP-Netze umgebogen zu haben.

Fast alle großen Cloud-Anbieter (AWS, Google, Azure etc.) haben eigene Videoangebote von der Stange, die mit etwas mehr Verpackung für Endanwender großen Mehrwert leisten können. Und natürlich die skalierbaren Kapazitäten, die man selbst wie gewünscht programmieren kann.

Das geht bis zu für ITler trivialen Kleinigkeiten: Nils hat in der Sendung ein kleines Tool angesprochen, das “nur” die Einstellungsdateien der Videoschnittsoftware umsortiert. Das ihm unendlich viele Kopfschmerzen und Zeit einspart und damit auch Geld wert wäre.

Ich kenne ein Einmann-Projekt für professionelle Weiterbildung per Videostream in einem winzigen vertikalen Markt.

Weitere Ideen:

  • Gyroskopie für nachträgliche Bildstabilisierung, wie bei Hyperlapse
  • AI-unterstützte Untertitel und Timing von Transkripten, wie bei YouTube
  • Datenbank-gestützte, kollaborative Verwaltung von Einblendungen
  • Automatisierte Aufzeichnung und Verteilung von Konferenzen/Meetings, wie bei Apples eingestelltem Podcast Producer
  • Irgendwas mit VR™
  • Asset Management, Anbindung an die XML-Formate der NLEs
  • Versionierung von Projektdaten
  • Skype TX ohne Skype, Videokonferenz, WebRTC zu SDI und umgekehrt

Oder etwas allgemeiner formuliert: Videoproduzenten und -verarbeiter brauchen einen Nerd im Schrank. Nicht, dass dort nichts passieren würde, aber ich glaube, es gibt Luft nach oben. Sobald die Anforderungen der Videoproduktion an Grenzen stoßen, lässt sich sehr wahrscheinlich eine Lösung in Software dafür finden.

Ich habe in den letzten Jahren rund 800 Stunden Live-on-Tape Video produziert. Das wäre ohne die entsprechende selbst entwickelte Software zur Automatisierung so nicht möglich gewesen.

Wer als Informatiker seine nächste Aufgabe sucht, oder als Videomensch seine tagtäglichen Probleme gelöst sehen möchte, sollte möglicherweise mal miteinander sprechen.

Wer interessante Projekte in diesem Umfeld für mich hat, darf sich auch gerne bei mir melden.

Dude, Where’s My Phone?

Über die Feiertage wurde mir diese Geschichte erzählt, ich fasse zusammen:

Herr S. verliert Anfang Dezember sein Smartphone. Er ruft die Hotline seines Providers an, die SIM muss gesperrt werden. Er fragt außerdem, ob er ein neues Smartphone in seinen 20 Monate alten Vertrag bekommen kann, den er eigentlich gerade kündigen wollte. Das Angebot, das er dann leider angenommen hat:

  • Vorzeitig neues Smartphone: 15 Euro Gebühr pro Monat = 60 Euro
  • Samsung Galaxy S6, ein zwei Jahre altes Modell, Neupreis aktuell 400 Euro für 150 Euro
  • Und die Vertragsverlängerung für einen 50 Euro-Vertrag mit 1GB Datenvolumen

Macht über die zwei Jahre rund 1400 Euro.

Für 1100 Euro hätte er auch ein brandneues Galaxy S7 und den gleichen teuren Vertrag bekommen können. Oder ein Pixel XL, oder ein iPhone 7.

Wäre er stattdessen in den nächsten Laden des gleichen Anbieters gegangen und hätte eine Prepaid-SIM und das gleiche Galaxy S6 gekauft, wären es 760 Euro geworden.

Hätte er mich gefragt, hätte ich ihm ein brauchbares Smartphone und eine Prepaid-SIM für weniger als 400 Euro über zwei Jahre finden können.

Wie man es dreht und wendet, der eine Anruf in der Alter-wo-ist-mein-Handy-Panik hat ihn rund 300 bis 1000 Euro zu viel gekostet, die er sich nicht leisten kann, im Wesentlichen für etwas WhatsApp und Facebook, auf einem alten Smartphone-Modell. Für einen Widerruf war es schon zu spät.

Macht nicht den gleichen Fehler, und nutzt die Gelegenheit, eure Verwandten zu warnen: Wenn das Handy verloren geht oder gestohlen wird, lasst euch nicht von der Hotline zu einer Verlängerung überreden. Erst recht, wenn das Geld knapp ist. Im Aldi stehen zur Not Smartphone-ähnliche Geräte für unter 100 Euro in der Vitrine.

M94,5 wird abgeschaltet

Meinem ehemaligen Aus-und Fortbildungs-Radiosender M94,5, bei dem ich das Handwerk gelernt habe und viele Jahre verbracht habe, droht die Abschaltung seiner UKW-Frequenz 94,5MHz. Die BLM, die für die Vergabe zuständig ist, will die Frequenz wohl an Rock Antenne vergeben, einen Zweitverwertungssender von Antenne Bayern, einem unhörbaren Formatradioungetüm.

Die Erklärung der BLM ist freilich blanker Hohn – die Abschaltung ist wohl schon beschlossene Sache.

Im Hörfunkausschuss am 9. Februar 2017 wird es darum gehen, die Münchner UKW-Frequenz 94,5 MHz möglichweise einem anderen Programm zuzuweisen. Die Ausstrahlung von afk M94.5 über DAB+ und Internet bliebe selbstverständlich weiterhin erhalten. An der potenziellen technischen Reichweite würde sich nichts ändern. Aus Sicht der Landes­zentrale ist die UKW-Frequenz nicht nötig, um die Ausbildungsziele zu erreichen. Vielmehr sieht die BLM den afk als eine Speerspitze der digitalen Entwicklung.

Der BLM liegen Interessensbekundungen von Rock Antenne und egoFM für die UKW-Frequenz 94,5 MHz vor, die beide als Satellitenhörfunkprogramme grundsätzlich UKW-Stützfrequenzen erhalten können.

Zur Weiterentwicklung der Aus- und Fortbildungskanäle bedarf es strategischer Partnerschaften mit den privaten Hörfunkanbietern, wozu sowohl die Rock Antenne als auch egoFM einen wesentlichen Beitrag leisten können.

Übersetzung: Rock Antenne bekommt die Frequenz, egoFM ist in München ohnehin flächendeckend auf der 100,8MHz zu empfangen. Das kommt einer Abschaltung von M94,5 gleich. DAB+ hat vergleichsweise keine Empfangsgeräte, per Internet hat mobiles Radiostreaming dank restriktiver Mobilfunkverträge in Deutschland praktisch keine Relevanz. Wer glaubt, ein Radiosender ohne UKW-Frequenz hätte zur Zeit eine Chance, gehört zu werden, sei auf die Probleme verwiesen, die BR Puls hat: Nämlich keine Hörer. Und ohne Hörer kann man den Laden auch gleich ganz dichtmachen.

Deutschland hat digitalen Rundfunk verschlafen, eine FM-Abschaltung wird noch Jahrzehnte dauern, und das Aufsichtsorgan will dem einzigen Ausbildungssender seine Hörer nehmen und stattdessen lieber Rock Antenne den TKP um ein paar Cent erhöhen. Das ist unglaublich kurzsichtig und hat einen sehr unangenehmen Beigeschmack von “strategischer Partnerschaft” zwischen Antenne und der BLM.

Ich bitte deswegen meine Hörer um Unterstützung von M94,5, ohne das es weder Bits und so, noch die Sprechkabine, noch Walulis sieht fern, noch viele weitere Kollegen gäbe, die ihren Einstieg ins Mediengeschäft bei M94,5 gefunden haben.

Petition unterzeichnen: “Wir bitten um den Erhalt des Ausbildungsradios m94.5 als UKW”

Mitteilung von M94,5: Die Folgen eines möglichen Frequenzverlusts

“Mythos” Speedport-Hack

Die Telekom hat eine eigene Darstellung des Ausfalls veröffentlicht:

Mythos offene Schnittstelle: Was wirklich geschah

Kein Mythos. Der Port war offen. Wäre er nicht offen gewesen, wäre nichts passiert.

Der ACS hat das Endgerät dazu aufgefordert, sich bei ihm zu melden. Diese „Anklopffunktion“ wird im TR-069 Standard als sogenannter „Connection Request“ beschrieben.
Damit der Connection Request funktionieren kann, muss das Endgerät für den ACS über das Internet erreichbar sein. Laut Standard ist hierfür der Port 7547/tcp vorgesehen, der auch von allen Speedport Routern dazu genutzt wird. Das Auslösen des Connection Requests erfolgt über das HTTP Protokoll. Bei den Speedport Routern ist dieser Mechanismus durch verschiedene Sicherheitsfunktionen gegen Missbrauch geschützt. Beispielsweise muss der ACS sich gegenüber dem Endgerät mittels eines geräteindividuellen Passworts authentifizieren.

Das Endgerät muss nicht aus dem Internet erreichbar sein, es muss für den ACS der Telekom und für sonst niemanden erreichbar sein. Wie diese Einschränkung umgesetzt wird, sei dahingestellt. Sollten sich die Provider wirklich nicht von der “Fernwartung” trennen können, scheint ein Wartungs-VLAN eine denkbare Lösung zu sein, das den Port aus dem Internet nicht erreichbar macht.

Nochmals: Das Auslösen eines Connection Requests bewirkt, dass das Endgerät eine sichere Verbindung zum vorkonfigurierten ACS der Deutschen Telekom aufbaut. Der Connection Request ermöglicht grundsätzlich keinen Zugriff auf das Datenmodell des Endgerätes.

Nochmals: Plastikrouter ohne nennenswerte Sicherheitsupdates mit offenen Ports ins Internet zu stellen, ist eine schlechte Idee.

Die aktuellen Angriffe betreffen jedoch nicht den ACS, sondern den Endpunkt für den Connection Request auf dem Endgerät, der über Port 7547/tcp erreicht werden kann. Die hierbei verwendete Angriffsmethodik ist neu und war bis dato nicht bekannt. Nach aktueller Sachlage basiert diese auf einer Veröffentlichung im Internet von Anfang November 2016.

Das grundsätzliche Problem ist die schlecht abgesicherte Software auf Kundenseite. Ein konkreter Angriff muss nicht bekannt sein, um festzustellen, dass die eigene Hardware betroffen sein könnte.

Heise dazu im Jahr 2014:

Ein weiteres Problem sei die Qualität der ausufernden Spezifikation von TR-069. Sie sieht zwar beispielsweise eine per SSL/TLS gesicherte Verbindung zwischen ACS und Endgeräten vor – aber fahrlässigerweise nur als Empfehlung.

Der Forscher untersuchte auch einige hundert URLs, die ISPs zur Kommunikation zwischen Endgerät und ACS verwenden. Ergebnis: 81 Prozent aller Verbindungen finden ungesichert per HTTP statt. “Damit genügt im Prinzip ein einzelnes, korrekt zusammengesetztes Paket, um einen Update mit manipulierter Firmware auszulösen”, so Tal.

Aber selbst wenn TLS zum Einsatz kommt, gibt es Probleme: Ein von Tal untersuchtes DSL-Modem habe beliebige, selbstsignierte TLS-Zertifikate akzeptiert. Damit sei eine Man-in-the-Middle-Attacke möglich, bei der sich der Angreifer als ACS ausgibt. Problematisch sei auch, dass viele ISPs die TR-069 betreffenden Einstellungen in den Routern verstecken und sachverständigen Kunden somit keine Chance lassen, die Konfiguration selbst zu prüfen oder zu ändern.

Ich halte TR-069 für eine grundsätzlich sehr schlechte Idee, die aus dem CPE-Denken der Provider herrührt, die Box auf Kundenseite sei Teil des Providernetzes.

Wieder die Telekom:

Der aktuelle großflächige Angriff war nicht spezifisch für die Speedport Router der Deutschen Telekom ausgelegt, d.h. er nutzt keine Schwachstelle in den Speedport Routern der Deutschen Telekom aus. Nach aktuellem Kenntnisstand sind keine Speedport Router von der im Internet publizierten Problematik betroffen, d.h. es ist nicht möglich, mit dieser Methodik eine Schadsoftware auf einem Speedport Router zur Ausführung zu bringen.

“From the department of not-my-problem” ist hier eine schlechte Ausrede. Der nächste Angriff funktioniert vielleicht, und dann ist eben nicht eine Million Router abgestürzt, sondern beteiligt sich mit permanent gehackter Firmware an einem DDOS. Was dann? Millionen Geräte tauschen, Anschlüsse sperren, Brennpunkt in der ARD.

Heise:

Versäumnis der Telekom
Fehler kann man der Telekom natürlich trotzdem vorwerfen: Der Fernwartungs-Port TR-069 hätte nicht offen aus dem Internet erreichbar sein dürfen. Auch wenn die Router für die aktuellen Angriffe nicht anfällig waren, kann man gerade bei einem solchen selbstgestrickten Betriebssystem mit proprietärer TR-069-Implentierung getrost davon ausgehen, dass es andere Sicherheitslücken aufweist, die sich missbrauchen lassen. Weinmann deutet auch bereits an, weitere Fehler gefunden und der Telekom gemeldet zu haben.

Kommentar von Nico Ernst bei Heise, dem ich mich anschließen kann:

Die Fernwartung von Routern über die TR-Protokolle darf als gescheitert angesehen werden. Kriminelle haben die millionenfach vorhandenen Plastikkästchen als Angriffsziel entdeckt, die Attacken galten nicht allein manchen Speedport-Modellen der Telekom. Vielmehr handelt es sich um einen Schrotschuss auf alles, was über den Port 7547 per Internet erreichbar ist.

Man darf wohl davon ausgehen, dass diese und die zahlreichen weiteren Lücken in den TR-Protokollen der Telekom bekannt waren. Sonst wäre kaum eine so schnelle Anhilfe durch neue Firmware möglich gewesen. Schon weniger als 24 Stunden nach Bekanntwerden der Angriffe verteilte die Telekom die neuen Versionen

Netzpolitik.org:

Was hat die Telekom falsch gemacht?

Der TR-069-Port hätte über das Internet nicht von arbiträren IP-Adressen erreichbar sein dürfen – dafür gibt es ACLs, Firewalls und getrennte Management-Netze. Darauf wurde die Telekom schon 2014 von ihren eigenen Kunden aufmerksam gemacht.

Ergebnis [ist] der Ausfall von fast einer Million Internet-Anschlüsse ist, der nicht verharmlost werden sollte: Er konnte sogar ohne Absicht des Angreifers ausgelöst werden.

Der nächste Angriff auf die 18 Millionen DSL-Anschlüsse in Deutschland ist vielleicht ernstgemeint. Per Pressemitteilung die eigene Verantwortung abzuwälzen, hinterlässt schlechte Gefühle.

Wenigstens der Telekom-Chef hat wohl das Memo gelesen, bevor es durch die PR-Abteilung ging und sagt:

Speedport-Hack – Telekom kannte die Schwachstelle

Ein Detail zu dem großflächigen Ausfall bei Telekom-DSL-Kunden gestern, das in den Mainstream-Berichten häufig fehlt:

Heise:

Es sieht alles danach aus, als ob es sich um eine Variation der TR-069-Lücke handelt, die bereits 2014 von CheckPoint publik gemacht worden war. Zu diesem Zeitpunkt hatten deutsche Provider (darunter auch die Telekom) ihre Netze für sicher erklärt.

Die grundsätzliche Problematik der TR-069/064 Fernwartungs-Schnittstelle war seit mindestens zwei Jahren öffentlich bekannt und betrifft potentiell nicht nur die gestern betroffenen Speedport-Router, sondern alle Arten von Routern.

Der gestrige Ausfall erscheint mir also durchaus T-hausgemacht, und hätte leicht präventiv verhindert werden können, denn:

Internet-Verkehr wurde auf den dafür genutzten Port 7547 an die Router durchgeleitet. Ein legitimer Anwendungsfall dafür mag sich mir nicht erschließen.

Das grundsätzliche Problem war bekannt, und die Gegenmaßnahmen im eigenen Netz waren unzureichend. Wenn Angriffe auf diesem Port seit Jahren bekannt sind, und ein legitimer Zugriff nur aus dem Support-Netz der Telekom stammen dürfte, hätte der Port schon seit Jahren für Zugriffe aus dem Internet gesperrt sein müssen.

Die Aussagen der Telekom-Sprecher verschleiern die eigene Fahrlässigkeit.

Tagesschau

Die Fernwartung (“Easy Support” bei der Telekom) ließ sich lange auf gemieteten Speedports nicht deaktivieren. Das geht laut Dokumentation inzwischen. Update: Ist allerdings vertraglich bei Mietroutern weiterhin untersagt.

Eine wirkungsvoller Workaround wäre vermutlich schon am Sonntag gewesen: Router ohne DSL-Kabel booten, Fernwartung deaktivieren. Aber das hätte nur zusätzlichen Support-Aufwand in der Zukunft verursacht oder weitere Sicherheitsupdates verhindert, weil das Auto-Update nicht mehr angestoßen werden kann. Die Fernwartungs-Schnittstelle stellt ein großes Risiko dar und offener Zugriff darauf aus dem Internet hätte schon seit mindestens zwei Jahren aufgegeben werden sollen.

Details zum Angriff beim ISC

Tim Cook on iPod Classic and Mac Pro (2014)

From the Q&A at WSJD Live, November 2014. Starts at 28:45 in the video.

Q: [Why did you kill the iPod Classic 160GB?]

Tim Cook: “Because we couldn’t get the parts anymore. Not even anywhere, they’re not made anymore. And so we had the choice of either of doing a total redesign, a totally new project. Or try to get people to go to the iPod touch, if they wanted a sort of dedicated music device. iPod touch is not really a dedicated music device, but I think you know what I’m saying. We’re shipping a lot of flash in it now. You can get almost all the ones that you get on your Classic. Not quite yet. Over time, that might change. And so, it wasn’t a matter of where I was swinging the axe saying, let me see what I can kill today.
The engineering work to design a whole new product was pretty massive. And the number of people who wanted it, very small. Sometimes we decide to do those anyway, like Mac Pro. We’re doing those for our creative customers, but in the case of iPod [Classic] I felt that there are reasonable alternatives there and I’m sorry if you didn’t feel that way, because I want to keep you as a customer. But that was the rationale.”

To put it in other words: The Mac Pro wasn’t making enough money to justify the 2013 redesign in the first place from a pure business perspective. But they did it anyway for their creative customers. Is the MacBook Pro 2016 a reasonable enough alternative?