HTTP-Download

[Florian]

Updates finde ich da schon etwas anderes. Besteht doch de Gefahr, dass Malware nachgeladen wird, wenn der Kanal nicht geschützt ist.

Insofern finde ich den Zug von Apple gut, nur die Kommunikation war wohl wieder mal nicht das Gelbe vom Ei. Man könnte auch eine Übergangsfrist einräumen usw. Wie auch immer, wir oder die Entwickler werden sowieso nicht gefragt.

[MacFlieger]

Aber in das System einzubauen, dass HTTP-Verbindungen für Updates nicht überdacht (geändert) werden müssen, aber sämtliche anderen HTTP-Verbindungen schon, dürfte ziemlich schwierig und auch fehleranfällig sein.

Da finde ich die Methodik, die Entwickler hier zum Nachdenken anzuregen, es aber nicht komplett zu unterbinden, schon für eine gute Lösung.

Inwieweit das deutlich genug kommuniziert wurde, weiß ich nicht. Aus dem text von mbs lese ich aber schon heraus, dass das bekannt gemacht wurde, aber solche Sachen eben in Vergessenheit geraten, wenn man sie nicht sofort umsetzen muss.

[radneuerfinder]

Ob die konkrete Massnahme sinnvoll ist, kann ich nicht beurteilen. Eine Anregung zum Nachdenken bringts meiner Meinung nach oft nicht.

[Florian]

Sehe ich auch so. Verschlüsselung hat es eh schwer, auch manche Entwickler schlampen da gerne.
Man könnte es auch andersherum sehen: Ist Apple mit diesem Schritt nicht eh viel zu spät dran?

Ich meine, es geht hier ja nicht um die Entwickler und ihre Programmierfreiheit, sondern um die Sicherheit der Benutzer. Die auch immer mehr in fremden Netzen surfen/updaten.
Ein besserer Vergleich wären da vielleicht die Feuermelder und -Löscher in Hotels. Man kann eben als Gast darüber nicht bestimmen, also gibt es gesetzliche Vorschriften (die natürlich allzu oft auch nicht befolgt werden, analog geht das eben).

Ich weiß auch nicht genau, wie Apple gewarnt hat, aber so etwas muss man mit nervenden Alarmmeldungen einhämmern. Weil es eben genau ist, wie Du schreibst: So etwas wird oft verschoben und vergessen.

[MacFlieger]

Äh, meinst Du das Ernst oder verstehe ich Dich falsch?
Als Apple bei iOS kein Flash zuliess, gab es einen Riesenaufstand, weil viele (fast alle) Videos damals nicht funktionierten. Aber betroffen waren immerhin "nur" Videos. Dann stellten die Betreiber langsam um und heute sind fast alle Videos sichtbar.
Wenn Apple jetzt komplett HTTP-Verbindungen verbietet, dann läuft doch fast keine WWW-Verbindung mehr, bis der Großteil aller Sitebetreiber auf SSL umgestellt hat. Ja, es wäre von Vorteil, dadurch einen ähnlichen Anreiz bekämen wie bei den Videos, aber Hand aufs Herz: Möchtest Du so lange verzichten und glaubst Du wirklich, die stellen wegen Apple flächendeckend in kürzester Zeit alle(!) auf SSL um?

[warlord]

Ich meine, es geht hier ja nicht um die Entwickler und ihre Programmierfreiheit,

Doch, beim aktuellen Trend, wie Apple Sicherheit herzustellen versucht (angefangen beim Sandboxing, weitergeführt mit Dingen wie ATS) , geht es eben schon sehr stark darum, Entwickler in ihrer Programmierfreiheit einzuschränken. Sicher kann man mit sturen und automatisiert durchgesetzten Regeln einiges an Sicherheitslecks und Malware verhindern. Man verhindert mit dem Vorgehen aber eben auch eine Reihe (bereits vorhandener und zukünftiger) sinnvoller Möglichkeiten. Und die Frage sei erlaubt, ob man damit nicht mehr Schaden anrichtet, als Gutes tut.

Vollständig verhindern kann man Sicherheitslecks mit solchen Massnahmen sowieso nicht. Und selbst wenn man zum Schluss kommt, dass der daraus resultierende Nutzen grösser ist, als der damit angerichtete Schaden, halte ich stur durchgesetzte Leitlinien nur dann für sinnvoll, wenn sie auf Konsens von wirklichen Experten beruhen. Apple hat sich bis jetzt in meinen Augen nach wie vor nicht als extrem hoch einzuschätzender Experte hervorgetan, was Sicherheit angeht. Die Regeln eines Mittelschullehrers dürften für einen Grundschüler zwar sinnvoll sein. Ein Hochschulprofessor wird sich aber nicht ganz zu Unrecht etwas angepisst fühlen, wenn ihm ein Mittelschullehrer Regeln diktiert.

Ein weiterer Aspekt der (bei ATS schätzungsweise zwar (noch) nicht zutrifft, aber doch) bedacht werden sollte ist, dass Entwickler mit solchen Massnahmen häufig in die offiziellen Bibliotheken gezwungen werden und alternative (womöglich bessere) Lösungen unterbunden werden können. Damit wird einerseits die Entwicklung besserer (auch sicherer) Alternativen erschwert oder verhindert und es werden Möglichkeiten geschaffen, (z.B. durch Regierungen verordnet) Hintertüren einzubauen bzw. die Umgehung solcher Hintertüren zu unterbinden.

Nachtrag:
Und zu guter letzt: ist es nicht etwas schizophren, durch Gängelung von Entwicklern (vermeintliche) Sicherheit herstellen zu wollen, während man gleichzeitig selbst die Benutzer immer mehr in unsichere Cloud-Dienste zwingt?

[Florian]

Äh, meinst Du das Ernst oder verstehe ich Dich falsch?

Es geht hier um Programm-Updates. Man kann natürlich in mein „surfen/updaten“ etwas hineinlesen, aber im Gesamtzusammenhang ist das doch klar. Die Leute nutzen oft und vermehrt offene bzw. fremde Netze und aktualisieren auch ihre Software dort. Vielleicht sogar gar nicht willentlich in dem Moment, sondern per Automatik.

warlord: Verständliche Kritik. Diesen Fall um die Updates empfinde ich aber als nicht in diese Kategorie gehörend.
Was die Experten angeht: Apple stellt ja seit geraumer Zeit ein. Sogar bekannte Leute sind dabei. Der Wille ist wohl vorhanden, stellt sich nur die Frage ob dann weniger Bevormundung als Resultat herauskommt oder eher mehr.

[MacFlieger]

Es geht hier um Programm-Updates.

Schon. Aber wenn Apple nur HTTP-Verbindungen für Updates unterbinden soll, aber nicht HTTP-Verbindungen für andere Zwecke, dann müsste Apple eine Methodik implementieren, dass das OS erkennt, ob die jeweilige Verbindung für Updates oder für was anderes genutzt wird. Solch eine Erkennung halte ich für sehr schwierig und sicherlich problembehaftet, d.h. Apple müsste hier eine Menge Gehirnschmalz investieren und trotzdem noch der nicht unerheblichen Gefahr von Fehlerkennungen ins Messer laufen. Das halte ich nicht für praktikabel. Oder übersehe ich da eine einfache Methode?

HTTP komplett verbieten ist einfacher (meiner Meinung nach aber auch nicht 100%ig sicher, denn woran wird eine Http-Verbindung erkannt? ), hat aber aktuell zu viele Nebeneffekte.
HTTP auf Wunsch des Entwicklers (durch Setzen der jeweiligen Option) zu erlauben, ist ebenfalls einfach, zwingt den Entwickler nur zum Nachdenken/Reagieren, aber nicht zum Wechsel.

Klar wünschenswert wäre es, wenn man Entwickler stärker zu verschlüsselten Verbindungen motivieren könnte, keine Frage. Aber ich sehe da keine praktikable Möglichkeit seitens des OS.

[Florian]

So langsam komme ich dahinter, über was wir aneinander vorbei reden.

Schon. Aber wenn Apple nur HTTP-Verbindungen für Updates unterbinden soll, aber nicht HTTP-Verbindungen für andere Zwecke, dann müsste Apple eine Methodik implementieren, dass das OS erkennt, ob die jeweilige Verbindung für Updates oder für was anderes genutzt wird.

Nö, die unterscheiden nicht, sondern es geht um alle Verbindungen, die das Programm initiiert. Update ist halt hier im Thema das *ähem* Thema. Darum habe ich mich darauf verengt.

Das geschieht nicht über eine Filterung, sondern wie mbs das schrieb:

Programme, die auf und für OS X El Capitan entwickelt wurden und die üblichen Schnittstellen für Web-Kommunikation verwenden, dürfen kein unverschlüsseltes HTTP mehr verwenden, es sei denn, der Programmierer fügt intern dem Programm eine "Weiße Liste" von Domains bei, die auch unverschlüsselt noch kontaktiert werden dürfen oder er deklariert das ganze Programm als "HTTP-unsicher".

Wo ist jetzt das Problem?
Wer nicht verschlüsseln kann oder will, der umgeht das eben. Immerhin wurde er mal auf den richtigen Weg hingewiesen und muss aktiv davon abkommen.
Und aus welchen Grund er verschlüsselt nach Hause telefoniert, ist doch egal. Einmal die Verbindung/en absichern und fertig.
Einem Browser o.ä. ist so etwas natürlich unmöglich, daher muss es natürlich Ausnahmen geben. Trotzdem sollten Browser verschlüsselt aktualisiert werden.

[MacFlieger]

OK, ich denke, ich habe Dein "Sehe ich auch so." aus Antwort 18 falsch verstanden. Ich hatte das in der Richtung verstanden, dass Du es auch so siehst, dass man die Entwickler zu Verschlüsselung zwingen muss/sollte und daher HTTP komplett unterbinden sollte. Mein Fehler.