Dimm- & Control-Kit kontaktiert regelmäßig die Alibaba-Cloud

[openWB]

Erstmal unbedenklich.

Das mag (aktuell vielleicht) sein. Was aber

wenn auf der anderen Seite der Verbindung jemand "bei Anruf ran geht".

Wenn ein System von sich aus eine Verbindung nach außen aufbaut bestehen leider entsprechende Risiken.

Wie bei (nahezu) allen Systemen die updatefähig sind.

Das trifft sogar auf alle förderfähigen Komponenten in dem Kontext zu. Es wird ja explizit gefordert das diese updatefähig sein müssen. In der Regel fragt der Client einen Server ab.

[hominidae]

Über den DHCP Lease / die FW kann man das von extern leicht steuern.

Also, Bitte...der normale Fritzbox-User kann das nicht, selbst wenn er um diese "Lücke" wüsste.
Ohne Hinweis und Anleitung sind "User" dazu nicht in der Lage.

Man muss ja unterstellen, dass openWB nicht weiss, was in der Firmware steckt

Warum?
Wir haben die FW entsprechend den benötigten Features erweitert.

...aber diese Funktion leider dabei nicht abgestellt.

Für ein Stück Hardware, dass über das Thema SteuVE demnächst Teil der kritischen Infrastruktur in DE ist finde ich das jetzt schon eher befremdlich.

Dann schau dich bitte nicht weiter um was IOT Hardware und auch WRs und co so treiben.

...die haben als zentrales System auch keine OpenSource Software am Start.
Alle meine IoT Geräte aus China haben keine Original-FW mehr...aus gutem Grund.
Ein WR aus China kam/käme aus gleichem Grund auch nicht in Frage.

Wir hatten uns beim Dimm Kit bewusst gegen ein eigenes Netz entschieden, schlicht weil unterschiedliche Netze immer gängiger werden, Routen die meisten aber überfordern.

Gleichzeitig die hier genannte Verbindung aber unkritisch ist, da bei uns nicht relevant. Das ist so mit dem Hersteller auch abgeklärt.
Darüberhinaus eigene Tests gefahren die nichts kritisches gezeigt haben. Wenn jemand etwas findet dann bitte unbedingt Bescheid geben!
Ich wundere mich eher warum hier Unwissenheit unterstellt wird.

Weil es keine Transparenz in dieser Sache gab und gibt...
Nichtmal der Hinweis auf diesen "Call-Home" und wie man den unterbinden könnte... oder steht in der Anleitung etwas dazu?
Was nicht existiert kann von Aussen nicht unter Vermutung der Nicht-Relevanz als OK bewertet werden.
Leider sind die Zeiten wieder so, dass man sich entscheiden muss...gibt gute Gründe warum einige China-Hersteller für kritische Infrastruktur nicht mehr zugelassen sind.
Das Kit, wie die Add-On-Platine und die FW der EVSE in der Pro sind ja nicht OSS...warum soll da jetzt der User erst etwas finden müssen?
Die openWB ist im Hochpreis-Segment und vom "heimischen" Hersteller hätte ich da mehr Fingerspitzengefühl erwartet.
Die Reaktion darauf schreckt mich jetzt eher ab.

[openWB]

Weil es keine Transparenz in dieser Sache gab und gibt...

ich bin doch sofort darauf eingegangen!?

warum soll da jetzt der User erst etwas finden müssen?

Sollte etwas sicherheitsrelevantes gefunden werden bitte Bescheid geben!

Die Reaktion darauf schreckt mich jetzt eher ab.

Das wir das evaluiert und bewertet haben mit dem Ergebnis das dies kein Problem darstellt!?
Hier sofort geantwortet was Sache ist und was man machen kann wenn einem das dennoch nicht passt?
Ist das nicht richtig?

[ID4U]

Das trifft sogar auf alle förderfähigen Komponenten in dem Kontext zu. Es wird ja explizit gefordert das diese updatefähig sein müssen. In der Regel fragt der Client einen Server ab.

Ich gehe jetzt mal davon aus dies kein Versuch sein soll das undokumentierte "nach-Alibaba-telefonieren" zu rechtfertigen. Ist zumindest unglücklich ausgedrückt.

[hominidae]

Weil es keine Transparenz in dieser Sache gab und gibt...

ich bin doch sofort darauf eingegangen!?

....sorry, aber - wie schon erwähnt - wäre da etwas mehr Fingerspitzengefühl gefragt gewesen.
Zumindest meine Meinung.
Nachdem ein User diese undokumentierte Funktion "aufgedeckt" hatte, kam nicht gleich die Info, dass ihr das (ausgiebig) geprüft hattet.

Die Reaktion darauf schreckt mich jetzt eher ab.

Das wir das evaluiert und bewertet haben mit dem Ergebnis das dies kein Problem darstellt!?
Hier sofort geantwortet was Sache ist und was man machen kann wenn einem das dennoch nicht passt?
Ist das nicht richtig?

Die Frage ist, was notwendig und was hinreichend ist.
Hier wieder - meine Meinung - der Hinweis auf Transparenz und nun, da "das Kind in den Brunnen gefallen ist" evtl. etwas mehr "Einsicht" in der Sache...Pro-Aktive Voraussicht in der Transparenz ist ja nun nicht mehr möglich.

Der Kommentar von @ID4U sagt schon alles

Ich gehe jetzt mal davon aus dies kein Versuch sein soll das undokumentierte "nach-Alibaba-telefonieren" zu rechtfertigen. Ist zumindest unglücklich ausgedrückt.

Also, meine Empfehlung: Bitte die Dokumentation im Dimm-Kit anpassen...Hinweis geben, wenn man es nicht ausbauen will/kann und auch Anleitung für "Normalo-Fritzbox-User", der sich durchaus Sorgen machen könnte, WIE man es unterbinden kann.

Vielen Dank!

[ChristophR]

Über den DHCP Lease / die FW kann man das von extern leicht steuern.

Also, Bitte...der normale Fritzbox-User kann das nicht, selbst wenn er um diese "Lücke" wüsste.
Ohne Hinweis und Anleitung sind "User" dazu nicht in der Lage.

Mit der FritzBox Kindersicherung kann man eigentlich recht einfach Geräte davon abzuhalten eine ausgehende Verbindung aufzubauen.
Da das D&C ja gar keine Verbindung ins Internet benötigt, ist es bei mir auch gesperrt.

Ich hätte es aus diesem Grunde aber auch schöner gefunden, wenn das berüchtigte 192.168.193.x Netz ohne Verbindung in die Außenwelt genommen worden wäre.
Das ist bei openWB ja generell vorhanden, daher fallen mir wenige Gründe ein, das hierfür nicht auch zu nutzen.

[openWB]

Das trifft sogar auf alle förderfähigen Komponenten in dem Kontext zu. Es wird ja explizit gefordert das diese updatefähig sein müssen. In der Regel fragt der Client einen Server ab.

Ich gehe jetzt mal davon aus dies kein Versuch sein soll das undokumentierte "nach-Alibaba-telefonieren" zu rechtfertigen. Ist zumindest unglücklich ausgedrückt.

Nein, es zeigt nur auf wie eine Updatefunktionalitat meistens implementiert ist.

In der openWB ist ja auch nicht explizit dokumentiert das eine Verbindung zu GitHub für Updates aufgebaut wird.
Wenngleich das natürlich für wissende sehr nahe liegt.

[openWB]

Über den DHCP Lease / die FW kann man das von extern leicht steuern.

Also, Bitte...der normale Fritzbox-User kann das nicht, selbst wenn er um diese "Lücke" wüsste.
Ohne Hinweis und Anleitung sind "User" dazu nicht in der Lage.

Mit der FritzBox Kindersicherung kann man eigentlich recht einfach Geräte davon abzuhalten eine ausgehende Verbindung aufzubauen.
Da das D&C ja gar keine Verbindung ins Internet benötigt, ist es bei mir auch gesperrt.

Ich hätte es aus diesem Grunde aber auch schöner gefunden, wenn das berüchtigte 192.168.193.x Netz ohne Verbindung in die Außenwelt genommen worden wäre.
Das ist bei openWB ja generell vorhanden, daher fallen mir wenige Gründe ein, das hierfür nicht auch zu nutzen.

Leider nutzen immer mehr Nutzer die zu wenig IT Kenntnisse haben mehrere Netze. Das verursacht entsprechend erheblich Probleme und Supportaufwand. Hatte ich weiter oben ja schonmal geschrieben.

[openWB]

Also, meine Empfehlung: Bitte die Dokumentation im Dimm-Kit anpassen...Hinweis geben, wenn man es nicht ausbauen will/kann und auch Anleitung für "Normalo-Fritzbox-User", der sich durchaus Sorgen machen könnte, WIE man es unterbinden kann.

Könntest du die Anleitung für die „Normalo“ User beisteuern?
Dann machen wir da einen Wiki Artikel zu.

[ID4U]

In der openWB ist ja auch nicht explizit dokumentiert das eine Verbindung zu GitHub für Updates aufgebaut wird.

Diese Verbindung wird aber vom Nutzer durch aktives Anklicken des entsprechenden Buttons selbst initiiert.