Quic

Fragen zur Organisation, spezielle technische Fragen zum Dienst,
Post Reply
andy99
Posts: 49
Joined: Wed Aug 20, 2014 23:14

Quic

Post by andy99 » Wed Jul 22, 2015 17:34

Neue Infos zu Quic:
http://www.heise.de/meldung/Google-Inte ... 50897.html

Auf der einen Seite finde ich es toll wie Google elegant Bewegung in das Thema gebracht hat mit Spdy, d.h. einfach den Overhaed sowie die Latenz zu verringern ohne mit einem ganz neuen Entwurf auf dem üblichen Weg zu scheitern.
Auch bei Quic werden die Browserhersteller wieder folgen, damit sie in Sachen Performance nicht abgehängt werden und dann werden diese gemeinsam Druck auf einen HTTP3 Standard ausüben.

Ich finde Quic, genauso wie damals auch Spdy wirklich genial.

Nur leider weis ich jetzt schon wo das am Ende hinführen wird.

Quic Verbindungen werden anhand von ID's identifiziert, statt der IP-Adresse. Somit kann man die Netze frei wechseln, ohne Probleme.
Nun sind allerdings neben dem Gerät (IPv6 Prefix oder TFO Cookie) auch jede Anwendung auf einem beliebigen Gerät identifizierbar - bis ein Reboot die gemerkten Verbindungs-IDs (hoffentlich) entsorgt.
Womit es nichts mehr helfen wird, dass der End-Mix die Pakete ersetzt.

Ferner braucht es bloß noch eine kleine Verknüpfung zur AdvertisingID (Android/Apple) oder einer Mozilla BrowserID und schon ist das Usertracking perfekt.

Schön wäre natürlich die standardmäßige Verschlüsselung. Jedoch wird diese wie bereits beschlossen wurde auf DSA (welches komplett von Hardwarezufall abhängt und nebenbei auch noch kürzere Schlüssel benutzt), Elliptischen Kurven (Die im Einsatz befindlichen sind alles andere als Optimal) und Diffie Hellmann basieren.

Wobei eigentlich schon klar war, dass hier die performanteste Variante zum Einsatz kommen wird.
Immerhin darf die Verschlüsselung am Ende nicht die angestrebte (sogenannte) Echtzeitkommunikation (WebRTC et.) ausbremsen.

Weil UDP benutzt wird, wird DTLS zum Einsatz kommen, wobei Googles Ansätze erst in DTLS 1.3 einfließen müssen.
Zum Schutz vor Replay-Attacken darf bei Quic allerdings vor dem Einschlagen in den Handshake keine Payload gesendet werden (security.ssl.enable_false_start false).

Und dann will Facebook auch noch den Netzwerkstack optimieren. Na hoffentlich beschränken die sich darauf ein paar alte Protokolle rauszuschmeißen und die notwendigen Cloudfähigkeiten einzubauen.

Interessant wird es erst, man nun bedenkt, dass Google sowie Facebook immer mehr zum ISP werden (Virtuelle Mobilfunkprovider, Drohnen, Ballons, Satelliten) und die meisten Betriebssysteme inkl. Sprachassistenten bald alles in die Cloud schaufeln werden. Außerdem werden Google/Facebook zum Hoster (Youtube etc., Internet.org).

Fehlt bloß noch ein Google/Apple/Facebook-Net, mit eigenem Quantencomputer, einer eigenen virtuellen Währung etc.

Naja wie ach immer.

Es bleibt uns wohl nur übrig, network.http.proxy.version auf 1.1 festzunageln.
Oder gleich auf 1.0, dann kann man sich network.http.keep-alive.timeout 0 sparen.

Und natürlich security.ssl.enable_false_start auf false zu setzen, für die die manchmal "kein Proxy" im Jondofox-Addon auswählen.

Aber wie botschaftet Superheld Snowden und die Medien so schön ablenkend: Verschlüsselung macht uns das Internet sicher.

Aua!

Post Reply