Save .ORG: Widerstand gegen den Verkauf der Top-Level-Domain .org

Die Domainendung .org gilt seit jeher als Zuhause für die Internetauftritte von (nicht-gewinnorientierten) Organisationen. Und das ist kein Zufall, denn die Endung gehört zusammen mit .mil, .gov und .edu zu den ersten überhaupt eingeführten Domainendungen im Netz. Doch seit Mitte 2019 sorgt «dot org» für erhitzte Gemüter.

Save .ORG: Widerstand gegen Domain-Verkauf.

Alles begann damit, dass die ICANN als oberste Domainverwalterin am 30.06.2019 einen neuen Vertrag mit dem nicht-gewinnorientierten Unternehmen Public Interest Registry PIR abgeschlossen hatte. PIR betreibt die Top-Level-Domain .org und gehörte bisher zur Internet Society (ISOC), die unter anderem als Dachorganisation von Organisationen wie IAB oder IETF bekannt ist. Dass im neuen Vertrag die bisherige Bestimmung fehlte, wonach Preiserhöhungen bei der Erneuerung eines Domainnamens maximal 10 Prozent betragen dürfen, führte schon damals zu ersten Protesten in der Community, die befürchtet, dass die Preise überdurchschnittlich steigen könnten.

Verstrickte Sache: Neue Eigentümerin für .org

Im November wurde nun bekannt, dass die ISOC ihre Domainregistry PIR verkauft. 1,13 Milliarden US-Dollar soll die Investmentgesellschaft Ethos Capital für das Unternehmen bezahlt haben, das rund 10 Millionen .org-Domains verwaltet.

Für Stirnrunzeln sorgen dabei insbesondere persönliche Verflechtungen. So soll Fadi Chehade, bis 2016 CEO von ICANN, den Domainnamen von Ethos Capital am 14. Mai 2019 persönlich registriert haben – und das exakt einen Tag nach der erstmaligen Ankündigung der ICANN, die Preisbestimmungen für .org-Domains aus dem Vertrag zu streichen. Und Chehade hat auch beste Beziehungen zum Chef von Ethos, Erik Brooks. Brooks leitete bis vor kurzem nämlich ABRY Partners, bei der Fadi Chehade nach seinem Engagement bei ICANN tätig wär.

Während ihrer Tätigkeit bei ABRY kauften die beiden auch die Domainregistry Donuts Inc., die unter vielen anderen Domain-Endungen wie .cool, .rocks oder .email betreibt. Und hier scheint sich der Kreis wieder zu schliessen: Jon Nevett, einer der Gründer von Donuts, ist heute CEO von PIR, die nun an Ethos Capital verkauft werden soll.

«Save .ORG»

Eines der erklärten Ziele von cyon ist es, das Internet zu einem besseren Ort zu machen. Und wir glauben, dass der Verkauf der .org-Registry an eine Investmentgesellschaft das Gegenteil bewirkt – auch wenn die neuen Eigentümer zumindest im derzeitigen Trubel versichern, keine grossen Preiserhöhungen zu planen. Im Worst-Case-Szenario kosten .org-Domains plötzlich doppelt oder drei Mal so viel wie heute. Für eine Investmentgesellschaft sicher eine reizvolle Überlegung, für die betroffenen Organisationen, die in grosser Zahl auf .org-Domains setzen, wäre das hingegen ein Desaster.

Wir bei cyon unterstützen deshalb die Bewegung hinter «Save .ORG», die den Verkauf an Ethos Capital verhindern und gleichzeitig mehr Mitsprache der NGO-Organisationen bei Entscheidungen rund um das Handling von .org-Domains will.

Bereit für die Zukunft: Websites bei cyon jetzt per IPv6 erreichbar

«Wir haben jetzt keine IPv4-Adressen mehr». Die für Europa zuständige RIPE NCC hat diese Woche die Vergabe des letzten freien Adressblocks bekanntgegeben. Dass dem Internet mit IPv4 die Adressen ausgehen würden, ist natürlich nicht erst seit dieser Woche bekannt. Mit IPv4, dem Internet-Protokoll in der Version 4, stehen nämlich «nur» 4,3 Milliarden eindeutige Adressen zur Verfügung. Das genügte zwar für lange Zeit – und zu den Anfangszeiten des Netzes dachte wohl nie jemand daran, dass dieser Adressvorrat jemals erschöpft sein würde. Doch die immer weitere Ausbreitung des Netzes und die rasant steigende Zahl an internetfähigen Geräten machten IPv4-Adressen zum inzwischen raren Gut.

Websites bei cyon jetzt per IPv6 erreichbar.

Die gute Nachricht: Das Nachfolgeprotokoll IPv6 ist fest bei uns angekommen. Websites auf Webhostings (Speed- und Agencyserver folgen in Kürze) sind unterdessen genauso per IPv6 erreichbar wie unsere DNS-Server. Bleiben noch die Mailserver, die im kommenden Jahr folgen werden.

340 Sextillionen IP-Adressen

Mit IPv6 wird Adressknappheit zum Glück wieder zum Fremdwort, denn damit stehen nämlich rund 340 Sextillionen eindeutige Adressen, also ungefähr 340’282’366’900’000’000’000’000’000’000’000’000’000 IPv6-Adressen zur Verfügung. Das reicht für die nächsten paar Jahre. Und zwar locker.

Aber natürlich bringt IPv6 nicht nur einen fast schon unbegrenzten IP-Adressvorrat, sondern stellt auf längere Sicht vor allem die Konnektivität sicher. Unser Netz bleibt damit von überall her erreichbar, auch – oder erst recht – über Provider, die nicht über IPv4-, sondern lediglich über IPv6-Adressen verfügen. Dann sollen auch die Verbindungen nochmals um ein paar Millisekunden schneller sein, behauptet zumindest ein Teil der Experten.

Und dauerte es wirklich so lange?

Zugegeben: Für Tech-Enthusiasten mag es etwas länger gedauert haben, bis IPv6 auch bei uns Einzug gehalten hat. Der Blick über den Tellerrand zeigt dann aber schnell, dass es bei der Adaptierung von IPv6 hierzulande noch Luft nach oben gibt. Gemäss aktuellen Zahlen von RIPE sind nämlich erst etwas mehr als 40 Prozent des Schweizer Internets bereit für IPv6.

Anteil per IPv6 erreichbare autonome Systeme (AS), Stand Ende November 2019.

Anteil per IPv6 erreichbare autonome Systeme (AS), Stand Ende November 2019. Quelle: RIPE NCC

Es wird übrigens auch weiterhin möglich sein, an IPv4-Adressen zu kommen. RIPE wird Adressen von aufgelösten Unternehmen oder solche, die von Netzbetreibern zurückgegeben werden, per Warteliste neu verteilen. Ausserdem gehen Experten davon aus, dass der Handel mit IPv4-Adressen stärker wird. Mit der Verteilung der letzten freien IPv4-Adressen hat der Wert einer Adresse noch einmal zugelegt.

HTTP/3: Die nächste Stufe des Web-Protokolls ist gezündet

Vor noch nicht allzu langer Zeit hat HTTP/2 das Licht der Welt erblickt. Und jetzt steht bereits HTTP/3 auf der Matte. Wir erklären, was HTTP/3 ist, warum es noch schneller als HTTP/2 ist und wer HTTP/3 bereits nutzen kann. Spoiler-Warnung: cyon-Kundinnen und -Kunden 😉

HTTP/3: Die nächste Stufe des Web-Protokolls ist gezündet.

HTTP/3: Die nächste HTTP-Version steht in den Startlöchern

Das HyperText Transfer Protocol (HTTP) ist ein Protokoll zum Übertragen von Daten von einem Server an die Applikation des Anwenders. Es wird hauptsächlich verwendet um Websites im Browser anzuzeigen.

Supportcenter-Artikel zu HTTP/HTTPS

Bis 2015 war die Version HTTP/1.1 jahrelang das Mass aller Dinge. Dann kam HTTP/2 und brachte viele Verbesserungen. Nun steht bereits HTTP/3 in den Startlöchern. HTTP/3 ist vereinfacht gesagt die Verschmelzung der beiden Übertragungstechnologien HTTP/2 und QUIC, die bislang unabhängig voneinander auf unterschiedlichen Ebenen für schnellere Datenübertragung sorgen.

HTTP/3 erbt und vereint also die Vorteile von HTTP/2 und QUIC, die hier nochmals kurz zusammengefasst sind:

HTTP/2

  • Kommunikation auf einem Kanal
    Bis anhin musste der Browser für jede einzelne Datei eine eigene TCP-Verbindung öffnen. Das erzeugte unnötigen Datenverkehr und drückte auf die Geschwindigkeit. Mit HTTP/2 wird die Kommunikation zwischen Browser und Server über eine einzige Verbindung abgewickelt.
  • Stream Dependency
    Die Kommunikation auf einem einzelnen Kanal benötigt eine gewisse Intelligenz im Hintergrund, damit sich die Datenpakete nicht in die Quere kommen. Der Browser kann dem Server signalisieren, welche Dateien für ihn wichtiger sind und diese damit vor anderen Daten priorisiert erhalten.
  • Kompression der Kopfzeilen
    Die sogenannten HTTP-Header beinhalten die wichtigen Zusatzinformationen zu der angeforderten Datei. HTTP/1.1 erzeugt hier viele redundante Daten, was unnötigen Datenverkehr produziert. Mit HTTP/2 lassen sich diese Header drastisch in der Grösse reduzieren. Damit müssen weniger Daten ausgetauscht werden.
  • Server Push
    Der Server kann dem Browser bereits Dateien schicken, bevor der Browser die entsprechende Dateien überhaupt angefordert hat. Das verhindert zeitintensive Roundtrips der Datenpakete zwischen dem Browser und dem Server.

QUIC

  • Weniger Datenpakete, schneller verbunden
    Für den Verbindungsaufbau müssen weniger Datenpakete hin und her gesendet werden. Das spart Zeit.
  • Konstante Verbindung
    Die Verbindung zwischen den Geräten wird aufrecht erhalten, auch wenn sich das Netzwerk eines Geräts ändert (wie zum Beispiel beim Wechsel von Mobilfunk auf eine WIFI-Verbindung). Ein erneuter Verbindungsaufbau ist damit nicht nötig.
  • Keine Warteschlange
    Die Datenpakete müssen, im Gegensatz zu TCP, nicht in einer fest definierten Reihenfolge eintreffen. Verlorene Datenpakete führen damit nicht dazu, dass die Kommunikation verlangsamt wird.
  • Verschlüsselung inklusive
    Die Kommunikation via QUIC ist automatisch mit TLS 1.3 verschlüsselt und geniesst damit alle Vorteile von verschlüsselten Verbindungen.

Wie kann ich HTTP/3 nutzen?

HTTP/3 wird zurzeit von Arbeitsgruppen der Internet Engineering Task Force (IETF) standardisiert, befindet sich also immer noch in der Entstehungsphase. In den Entwicklungsversionen von Google Chrome, Mozilla Firefox und Microsoft Edge, den sogenannten Nightly-Builds, lässt sich HTTP/3 bereits aktivieren. Alles was es dann noch braucht, ist ein Server, der ebenfalls HTTP/3 versteht. Und der von uns verwendete Webserver LiteSpeed ist da ganz vorne mit dabei.

So aktivieren Sie HTTP/3 in den Browsern:

  • Chrome Canary und Edge Canary: Starten Sie die den Browser via Kommandozeile und den zusätzlichen Flags --enable-quic --quic-version=h3-23. Der vollständige Befehl sieht auf macOS dann folgendermassen aus (Chrome Canary):

    /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-quic --quic-version=h3-23

    Wie sie Chromium-basierte Browser wie Google Chrome oder Microsoft Edge auf der Kommandozeile mit zusätzlichen Flags starten, ist auf der Chromium-Website für die verschiedenen Betriebssystem erklärt.

  • Firefox Nightly: Öffnen Sie in Firefox Nightly die URL about:config und suchen Sie nach dem Flag network.http.http3.enabled. Stellen Sie das Flag auf true und starten Sie den Browser neu.

In den Entwickler-Tools der Browser können Sie sehen, über welches Protokoll eine Datei übertragen wurde:

Screenshot Microsoft Edge HTTP/3

HTTP/3 wird in Chromium-Browsern, wie hier abgebildet Microsoft Edge, zurzeit als «http/2+quic/99» angezeigt.

Mit dem HTTP/3-Check von LiteSpeed können Sie auch ohne passenden Browser testen, ob die gesuchte Website bereits HTTP/3 unterstützt.

Noch jung, aber vielversprechend

Eines zeigte sich in unseren Tests ganz klar: Man merkt, dass sich HTTP/3 noch in der Entwicklungsphase befindet. Die Tests funktionieren nicht in allen Fällen und Dokumentation zu allfälligen Bugs ist noch rar gesät. Weil aber Web-Schwergewichte wie Google, Facebook und Cloudflare an der Entwicklung beteiligt sind, ist davon auszugehen, dass HTTP/3 ein Erfolg wird. Und dank unserem LiteSpeed-Webserver sind cyon-Kundinnen und -Kunden im Technologierennen ganz vorne mit dabei.

Google Chrome sperrt künftig «Mixed Content»

Das Problem ist so alt, wie es sichere Verbindungen im Internet gibt: Beim Aufruf von Websites via sicherem HTTPS-Protokoll werden Teile der Website, zum Beispiel Bilder, Videos, Scripts oder Schriften, über eine unsichere Verbindung geladen. Für den Browser Grund genug, die Seite trotz gültigem SSL-Zertifikat als «Nicht sicher» zu markieren.

Die Ursache für solche gemischten Inhalte liegt im Quellcode der entsprechenden Seite und lässt sich meist relativ einfach beheben, wie wir auch in einem Artikel in unserem Supportcenter aufzeigen. Trotzdem hält sich «Mixed Content» erstaunlich hartnäckig im Netz.

Google chrome sperrt «Mixed Content».

«Mixed Content hält sich hartnäckig»

Nachdem Google mit seinem Chrome-Browser bereits vor rund einem Jahr damit begonnen hat, unverschlüsselte Websites als “Nicht sicher” zu markieren, will der Konzern nun auch dem Mix zwischen sicheren und unsicheren Verbindungen den Garaus machen. Zwar würden Chrome-Nutzer schon jetzt rund 90 Prozent ihrer Surf-Zeit auf HTTPS-Websites verbringen, wie Google in einem Blogbeitrag schreibt. Doch darin sind auch die Verbindungen mit «Mixed Content» mitgezählt.

Google beginnt deshalb mit der im Dezember erscheinenden Chrome-Version 79 den Browser umzubauen. Version 79 erhält, quasi als Vorbereitung auf die nächsten Schritte, eine neue Einstellung, die es erlaubt, vom Browser blockierten «Mixed Content» manuell und spezifisch pro Website zu entsperren.

Zuerst gehts Audio- und Videodateien an den Kragen…

Mit Version 80, die voraussichtlich im Februar 2020 erscheint, will Chrome dann Audio- und Videodateien, die per unsicherem HTTP eingebunden sind, automatisch via sicherer SSL/TLS-Verbindung laden. Ist das nicht möglich, sperrt Chrome den Zugriff auf die betroffenen Audio- und Videodaten, so dass diese nicht auf der Website angezeigt werden. Zur Not kann der Nutzer die Inhalte aber mittels der in Chrome 79 eingeführten Einstellung entsperren.

Für Websites mit «unsicheren» Bildern hält Chrome 80 eine weitere Überraschung bereit: Werden diese nicht über eine sichere Verbindung geladen, wird die Website im Browser nicht wie bisher nur mit dem ⓘ-Symbol gekennzeichnet, sondern neu gut sichtbar als «Nicht sicher» markiert.

Chrome 80 markiert Mixed Content als unsicher

Chrome 80 markiert Mixed Content, wie unverschlüsselte HTTP-Verbindungen, als unsicher.

…später auch Bildern

Im Frühling 2020 dürfte für Chrome-Nutzer dann plötzlich die eine oder andere Website etwas karg aussehen. Ab Chrome 81 sollen nämlich Bilder, die nicht über eine SSL-/TLS-Verbindung geladen werden, komplett blockiert werden.

Im Bestreben, nur noch sichere Verbindungen zwischen Browser und Server durchzusetzen, erhöht Google den Druck mit diesen Neuerungen also noch einmal. Als Website-Entwickler tut man deshalb gut daran, schon jetzt nochmal ein Auge auf bereits bestehende Website-Projekte zu werfen und sicherzustellen, dass dort «Mixed Content» – auch in Plugins und ähnlichem – kein Thema ist. In unserem Supportcenter erfahren Sie, wie Sie «Mixed Content» erkennen und bereinigen können.

PHP 7.4 steht vor der Tür: Das sind die Neuerungen

Der Winter steht vor der Tür. Das heisst für die PHP-Gemeinde auch immer: Eine neue PHP-Version ist im Anmarsch. Voraussichtlich am 28. November 2019 soll die neueste PHP-Version 7.4 als erste stabile Variante erscheinen. PHP 7.4 markiert zugleich auch die letzte Version aus dem PHP-7-Strang. Die nächste Version nach PHP 7.4 wird damit PHP 8.0 sein und naturgemäss etwas grössere Neuerungen und Änderungen mit sich bringen. Aber konzentrieren wir uns doch auf die Gegenwart und damit PHP 7.4.

PHP 7.4: Bessere Performance und weniger Fehleranfälligkeit

Die neueste Version bietet wieder eine Menge neue Funktionen, die PHP als Programmiersprache weiter bringen werden. Uns haben es drei der Neuerungen ganz besonders angetan: Arrow Functions, Typed Properties und Preloading. Wir schauen uns diese neuen Features deshalb genauer an.

PHP 7.4: Das sind die Neuerungen.

Arrow Functions: Weniger Code für anonyme Funktionen

Anonyme Funktionen, also Funktionen ohne referenzierbaren Namen, waren in PHP bisher nur mit viel Code zu bewerkstelligen. Dank Arrow Functions reduziert sich der Zeichenaufwand bei solchen One-Liner-Funktionen drastisch. Hier ein Beispiel aus dem offiziellen RFC bzw. dem Projekt Pimple.

$extended = function ($c) use ($callable, $factory) {
    return $callable($factory($c), $c);
};

// with arrow function:
$extended = fn($c) => $callable($factory($c), $c);

Arrow Functions, auch Short Closures genannt, folgen dabei den folgenden Regeln:

  • Sie starten mit dem Keyword fn.
  • Sie können nur einen Ausdruck beinhalten, nämlich die Anweisung return .
  • Die Funktion darf kein return-Keyword beinhalten.
  • Parameter und Rückgabetypen können mit Typ-Hinweisen versehen werden.

Dank Arrow Functions reduziert sich also der Programmieraufwand für die viel genutzten anonymen Funktionen, da weniger sogenannter Boilerplate-Code benötigt wird.

Typed Properties: Weniger Fehleranfälligkeit

Als weitere tolle Neuerung haben unsere Software-Engineers die sogenannten Typed Properties auserkoren. Typed Properties machen PHP zu einer typensichereren Sprache.

Typed Properties ist mein Lieblingsfeature. Erhöht die Vorhersehbarkeit von Code und reduziert die Fehleranfälligkeit. Viel einfacher zu Debuggen 💪


Lukas Mäglin
Software Engineer

Der folgende Code:

class User {
    /** @var int $id */
    private $id;
    /** @var string $name */
    private $name;

    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }

    public function getId(): int {
        return $this->id;
    }
    public function setId(int $id): void {
        $this->id = $id;
    }

    public function getName(): string {
        return $this->name;
    }
    public function setName(string $name): void {
        $this->name = $name;
    }
}

kann neu folgendermassen geschrieben werden und bleibt weiterhin typsicher:

class User {
    public int $id;
    public string $name;

    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }
}

Getter- und Setter-Methoden sind damit zur reinen Sicherstellung von Typsicherheit nicht mehr nötig.

Preloading: Mehr Performance für Frameworks

Frameworks wie Symfony oder Laravel (das zum Teil auf Symfony basiert) sind für Entwicklerinnen und Entwickler nicht wegzudenken, wenn es darum geht, die eigene Applikation auf ein gutes Fundament zu stellen. Deshalb setzen auch immer mehr bekannte Content-Management-Systeme wie Drupal oder Contao auf bekannte Frameworks als Fundament.

Solche Frameworks bestehen in der Regel aus vielen verschiedenen Klassen, die dank OPcache nicht bei jedem Aufruf in Maschinencode übersetzt werden müssen. Was bislang in PHP allerdings fehlte, war die Möglichkeit, OPcache bereits vor dem ersten Aufruf «aufzuwärmen». Das konnte dazu führen, dass nach einem Event, der den OPcache leert, die Zugriffszeit auf die Applikation höher war. Dank Preloading erhalten Entwicklerinnen und Entwickler nun ein Instrument, um OPcache bereits vor dem ersten Aufruf mit den wichtigsten Klassen zu füllen. So wird der benötigte Code bereits beim ersten Aufruf aus OPcache geladen und muss nicht zuerst interpretiert werden.

Während Preloading auf OPcache basiert, verhalten sich per Preloading gecachte Dateien nicht komplett gleich, wie wenn sie über den «normalen» Weg in OPcache abgelegt werden. Denn OPcache bietet die Möglichkeit, gecachte Daten auf ihre Aktualität zu prüfen. Hat sich zum Beispiel der Zeitstempel der gecachten Datei geändert, wird die Datei nicht aus OPcache geladen, um den neuesten Stand auszuliefern.

Ausserdem speichert OPcache einzelne Dateien unabhängig voneinander. Abhängigkeiten in Klassen, die in unterschiedlichen Dateien gespeichert sind, müssen damit trotzdem bei jedem Aufruf neu aufgelöst werden. Dieser Vorgang benötigt wiederum Rechenzeit, die mit Preloading zusätzlich eingespart werden kann.

Denn per Preloading gecachte Dateien und deren Abhängigkeiten werden bereits beim Preloading-Vorgang im Arbeitsspeicher abgelegt bzw. aufgelöst. Die gecachten Dateien verhalten sich somit wie eine Applikation, die vor der Ausführung kompiliert werden muss, wie das zum Beispiel von Java bekannt ist. Die Vorteile liegen damit auf der Hand: Habe ich eine Applikation, deren Dateien sich nicht ständig verändern, erhalte ich dank Preloading noch mehr Performance. Leistungssteigerungen von bis zu 16% sind laut ersten Tests möglich.

PHP 7.4: Letzte Version im 7er-Strang

Nebst den bereits genannten Neuerungen, bringt PHP 7.4 eine ganze Liste mit weiteren Verbesserungen. Wie bei jeder neuen PHP-Version üblich, enthält der neueste Ableger auch Änderungen, die mit älteren Versionen nicht kompatibel sind. Ein Leitfaden für die Umstellung der eigenen Applikation auf die letzte Version im 7er-Strang findet sich auf php.net.

Die Arbeiten an der nächsten PHP-Version haben übrigens bereits begonnen. Während zu diesem Zeitpunkt noch keine genaueren Informationen zu Funktionsumfang und Veröffentlichung bekannt sind, wird PHP 8.0 wohl einen sogenannten Just-in-Time-Compiler (JIT) mitbringen. Wir sind gespannt 🙂