News SPDY: Auch Opera unterstützt designierten HTTP-Nachfolger

MrEisbaer schrieb:
Süß, ein Sandkastengangster nennt mich troll und der glaubt auch noch, das Google nicht mehr Daten mit SPDY sammelt als jetzt schon, weil ja Google so sozial ist und alle bestehenden Gesetze einhält und total Transparent ist.


Dann erklär doch mal, wie das überhaupt möglich sein soll?

Für das Protokoll gibt es eine Spezifikation von Google, die kann jeder Mensch der Welt einsehen. Und genau die wird von den Browserherstellern genutzt, um die Protokollunterstützung in ihre Browser zu implementieren. Wird da wohl was böses in der Spezifikation zu finden sein?

Da das Leuten wie dir nicht reicht und als nächstes womöglich noch behauptet wird, Google würde die Browserhersteller heimlich zur Implementierung böser Dinge anregen, die in der Spezifikation nicht zu finden sind:
Es ist quasi ein Kinderspiel herauszufinden, mit welchen Servern dein Computer über SPDY kommuniziert. Wie sollte Google sowas geheim halten, also ein nach-Hause-Telefonieren?
 
Vivster schrieb:
für mich ist das internet schön wenn es auf guten und modernen protokollen läuft ;)
Naja, Ansichtssache, ich als Fachinformatiker stehe eher auf Protokolle, die jeder Hersteller und jede Software unterstützt.

Und der SSL-Zwang ist imo ein dicker Blocker.
Damit meiner ich nicht nur, dass die Rechenlast damit je nach Website ins unermessliche steigen kann.
Man kann schlichtweg nicht alle Seiten auf SSL umstellen, SSL benötigt zwingend eine eigene IP pro Seite.
Das ist mit IPv4 nicht drin, hier werden auf den meisten Webservern Hunderte Websites auf einer IP geparkt.
SPDY ist somit quasi zwingend mit dem Erfolg von IPv6 verknüpft.
 
Daaron schrieb:
Trotz allem: Wen kratzt Opera? Ich teste meine Webseiten nicht einmal gegen Opera, da wäre es sogar wichtiger gegen IE6 zu testen...
4 Namen haben Relevanz: Firefox, Safari, Chrome und IE... wobei der IE immer hinten anstehen wird, weil die Release Zyklen viel zu hoch sind, um irgendwo irgendwie mitspielen zu können

Mich kratzt Opera. Für ich immer noch der beste und innovativste Browser - und wie schon erwähnt sollte man den mobilen Markt nicht unterschätzen ;)
Eines der größten Rätsel des Internets ist es für mich trotzdem noch, wieso Opera im Desktop-Bereich so wenig Marktanteil hat. Er kann locker mit den "großen" 3 (FF, IE, Chrome) mithalten und hat immernoch einige innovative Dinge, die bisher nicht von den anderen "geklaut" wurden ;)
 
Blutschlumpf schrieb:

Zu mal auch "gute" Zertifikate nicht gerade günstig sind.

Selbst erstellte Zertifikate werden ja als "Unsicher" markiert bis jetzt, was verständlich ist, wäre SSL aber Standard und jede Seite müsste ein Zertifikat mit bringen, will man unschöne Meldungen umgehen, muss man sich eines ausstellen lassen und günstige Anbieter werden bei den Browsern auch gerne als massiv unsicher eingestuft, also bleibt einem nur der Weg zu einem der teuren Anbieter und das kostet und ich bin ehrlich, nur für ein Blog oder so, würde ich mir kein Zertifikat besorgen.

Zum Thema Geschwindigkeit => Der Download mag zwar schneller gehen, so weit ich es verstanden habe, kann es auf dem SmartPhone usw. durch aus zu einer Verlangsamung kommen, da die Daten entschlüsselt werden müssen und auch die Datenrate könnte steigen, da ja Daten die per SSL-Verschlüsselt sind, eigentlich mehr Bandbreite fressen.
 
MrEisbaer schrieb:

Auch von mir nochmal:
BEWEISE, wie Google hier irgend etwas sammeln soll, so SPDY doch ein verschlüsseltes Protokoll ist. Zeige deine technische Kompetenz und erklär uns, wie ein offener Standard für verschlüsselte Kommunikation für Datensammelei genutzt werden soll.

palace4d schrieb:
palace4d schrieb:
Ebenso in den Ostblockländern hat Opera bedeutend mehr Marktanteil.
Ein Closed Source - Browser ist einfach meiner Meinung nach immer eine Fehlentscheidung.... Closed Source Software im Allgemeinen ist eine Fehlentscheidung!
Oh, und das wichtigste Argument vs. Opera: Es wird evtl. von Facebook aufgekauft.

Blutschlumpf schrieb:
Und der SSL-Zwang ist imo ein dicker Blocker.
...
Man kann schlichtweg nicht alle Seiten auf SSL umstellen, SSL benötigt zwingend eine eigene IP pro Seite.
Falsch. Ich verwalte 4-5 SSL-Domains als Apache VHosts mit identischer IP. Das Zauberwort heißt SNI.
Die Frage ist eigentlich nur: Wer kann kein SNI?
- der IE unter WinXP (egal welcher IE) <- irrelevant im Hinblick auf SPDY, da selbst der IE10 (der unter XP nicht laufen würde) kein SPDY kann. FF/Chrome/Opera unter WinXP können SNI. Ab Vista kann auch der IE SNI.
- Android 2.x <- schon eher relevant und verdammt erbärmlich von Google, von denen erwarte ich echt mehr.
 
Teralios schrieb:
Zu mal auch "gute" Zertifikate nicht gerade günstig sind.
Heute zum Glück nicht mehr: PSW, StartSSL
Bei StartSSL gibts sogar EV-SSL zu einem Preis, bei dem man direkt bei den großen wie z.B. Thawte (wenn man nicht über PSW bestellt) gerade mal ein normales Zertifikat bekommt.


Daaron schrieb:
Die Frage ist eigentlich nur: Wer kann kein SNI?
- der IE unter WinXP (egal welcher IE) <- irrelevant im Hinblick auf SPDY, da selbst der IE10 (der unter XP nicht laufen würde) kein SPDY kann. FF/Chrome/Opera unter WinXP können SNI. Ab Vista kann auch der IE SNI.

Aber SPDY aktiviert sich über SSL, somit müsste eine Webseite sowieso erstmal SSL nutzen. Und hier scheitert es bei der SNI-Nutzung dann am IE auf XP. Man könnte natürlich auch eine Non-SSL-Variante anbieten, aber in dem Moment, wo ein ein XP-Nutzer einem SSL-Link auf die Seite folgt, hat er schon verloren.
Also hat man aktuell nur die Wahl eine eigene IP für jedes SSL-Zertifikat zu nutzen, oder IE auf Win XP kategorisch auszuschließen. Und damit meine ich nicht wie sonst mit CSS einfach nur kleine Darstellungsfehler sondern die Meldung des Browsers, dass die Seite unsicher ist und die Nutzer verschwinden wieder.
 

Anhänge

  • sni-xp-ie.png
    sni-xp-ie.png
    20,1 KB · Aufrufe: 532
Zuletzt bearbeitet:
Eben. User Agent - Erkennung ins Script: If Useragent = "WinXP IE" then showUpgradeWarning();

Irgendwo kennt mein Mitleid echt Grenzen, und in Sachen Internet liegt diese Grenze bei Vista IE9.
 
Nur dass der Nutzer die Seite bereits über den SSL-Link besucht und daher die angehängte Fehlerseite kommt, bevor er jemals deine Update-Warnung sieht. Und bei der Meldung des Browsers wird er bestimmt nicht den Fehler ignorieren. Für einen Onlineshop z.B. tödlich, auch wenn der Anteil klein ist und der IE kacke ist, es bringt Geld. Da muss man die alten unsinnigen Wege mit einer IP pro Zertifikat gehen.
Und für SPDY wird das niemand machen, das wird sich genauso erfolgreich verbreiten wie IPv6 :lol:
 
Daaron schrieb:
Pft, da kannst drauf wetten, dass Safari eher mit SPDY umgehen kann als der IE.... VIEL VIEL eher. Immerhin kommen neue Safari-Versionen nicht erst, wenn mal wieder ein komplett neues Betriebssystem fällig ist.


Ne, die profitieren einfach auch davon, wenn das Netz als Gesamtes schneller wird. Die würden ja auch davon profitieren, wenn WebM und WebP zum Standard würden.

Ich sehe da keinen großen Vorteil drin, wenn Versionen schneller kommen. Wo sind die großen Verbesserungen z.B. bei den dauernd wechselnden Firefox Versionen? Früher nannte man sowas Bugfix und wurde in Unterversionsnummern vertrieben...meinetwegen 3.06 oder sowas halt. Und bei jeder neuen Version funktioniert Plugin abc nicht mehr...Daumen hoch.

Opera sollte auch mal lieber bischen mehr an der Kompatibilität zu bestehenden Plugins arbeiten.
 
ice-breaker schrieb:
SPDY hat bisher und wird auch später so gut wie absolut keine Relevanz haben! Denn SPDY muss zwingend über SSL laufen und das nutzt aktuell auch kaum jemand, vor allem weil die benötigte Rechenleistung auf Servern steigt (SSL Handshake) also man als Betreiber eventuell noch mehr Server benötigt.

Ich habe vor 10 Jahren eine Anwendung auf externes SSL umgestellt, davon hat man auf den Servern fast nichts bemerkt.

ice-breaker schrieb:
Und spaßigerweise hat man mit SSL mehr Möglichkeiten dich zu tracken, und du kannst dich nicht davor schützen. Du kannst Cookies ausstellen und und und.
Aber eine SSL-Verbindung hat eine eindeutige ID, die auch nach dem Abbau noch bestehen bleibt, damit ein Client später versuchen kann mit der gleichen ID die Verbindung nochmal aufzubauen, damit der teure SSL Handshake gespart werden kann.

In der Praxis sind SSL-Sessions-IDs schneller expired als du denkst, und die ID ist nur für einen Server gültig.
 
Zuletzt bearbeitet:
@Ltcrusher: Dies bezog sich nicht auf die Versionsnummergeschichte über die du rumheulst ;) Es ging darum Web-Standards schneller umzusetzen oder schneller zum Standard zu erklären. Als Web-Entwickler muss heute eine Webseite entwickelt werden die möglichst mit den neuesten Technologien arbeitet (HTML5, dauert noch einige Jahre zum finalen Standard) gleichzeitig aber auf 4-5 Jahre alten Browsern läuft. Weil Nutzer nicht updaten oder einfach weil die Entwickler neue Dinge in einem Schneckentempo einbauen.

Es ging Daaron einzig darum, dass die Browserhersteller neue Standards und Fast-Standards (HTML5) schneller in die Browser einbauen und sich da keine Jahre Zeit lassen. Denn selbst wenn heute jeder aktuelle Browser die Funktion x hat, so sind doch noch genug ältere Browser unterwegs, die x nicht haben. Hätten die Hersteller aber x früher implementiert und nicht so lange gewartet, könnte man x nun nutzen, da auch die alten Browser es haben, und nur für die ganz neuen Features y und z müsste man wieder warten bis alte Browser das auch können.

foofoobar schrieb:
Ich habe vor 10 Jahren eine Anwendung auf externes SSL umgestellt, davon hat man auf den Servern fast nichts bemerkt.
Dann mach das heute nochmal, wo im Gegensatz zu 10 Jahren der Traffic viel höher ist ;) Bei einigen Millionen Zugriffen kommt da einiges an Mehrlast zusammen. Dieser ist zwar prozentual der Gleiche, aber gerade erst die Masse macht bei SSL den Ausschlag. Bei 10 Zugriffen pro Sekunde passiert da noch nicht viel.

foofoobar schrieb:
In der Praxis sind SSL-Sessions-IDs schneller expired als du denkst, und die ID ist nur für einen Server gültig.
Richtig, aber diese überdauern die Aktion in der ein Standard-User denkt er anonymisiert sich: er löscht alle Cookies und fertig.
 
Zuletzt bearbeitet:
Merk schon, hier sind einige Intelligenz-Allergiker die das denken ihrem Computer überlassen, anstatt ihr Hirn zu benutzen.

Hier lesen einige nur "Verschlüsselung", das Hirn geht auf Stand-by und es wird als sicher gefeiert, ohne auch nur mal einen Gedanken darüber zu verschwenden das es Hintertüren und/oder Schwachstellen gibt.

Stattdessen werden Leute als Troll etc. hingestellt, die es auch nur ansatzweise wagen Kritik zu üben, ist ja genauso wie wenn man was gegen Amerika sagt, ist man sofort ein Amerika Basher.

Huldigt ihr mal weiter eurem Glauben das SPDY sicher ist und werdet Glücklich.
Ihr glaubt dann auch das HTTPS sicher ist.
 
Und du hast noch immer keinen Beweis für deine haltlose Aussage gebracht, dass Goole mit SPDY mehr Daten sammeln kann...


Auch lustig, dass du scheinbar intelligenter als viele Kryptologen sind, die TLS entworfen haben.
 
Ich frage mich, ob mich das überhaupt noch interessiert, was Opera künftig macht.
Seit dieser gewissen Meldung habe ich mich an IronPortable gewöhnt und Opera ist Geschichte. (obwohl von Anfang an überzeugter Nutzer)

PS, wie ist eigentlich der Stand der Dinge bezüglich Opera-Einverleibung durch Zuckerberg?
 
Blutschlumpf schrieb:
Man kann schlichtweg nicht alle Seiten auf SSL umstellen, SSL benötigt zwingend eine eigene IP pro Seite.
Beim IIS ist das ein Problem, beim Apache dank Virtual Hosts ist das kein Problem, mehrere unterschiedliche Webseiten mit unterschiedlichen Hostheadern und SSL-Zertfikaten auf ein und derselben IP zu hosten. ;)

Dennoch gebe ich dir in diesem Punkt recht. Allein zu Debug-Zwecken müssen Header und Payload zumindest temporär mal unverschlüsselt übertragen werden können.

<fun mode="On">
@Steffen

Worauf wartest du noch. Beta-Patch für SPDY in den nginx rein und CB wird über SPDY angesurft. (auch wenn es keine nennenswerte Vorteile bei den ohnehin schon sehr guten Ladenzeiten bringen dürfte). :-P
<fun mode="Off">
 
Zuletzt bearbeitet:
Ltcrusher schrieb:
Ich sehe da keinen großen Vorteil drin, wenn Versionen schneller kommen. Wo sind die großen Verbesserungen z.B. bei den dauernd wechselnden Firefox Versionen?
Wenn die Entwickler der Browser in regelmäßigen KURZEN!!!! Abständen neue Versionen herausbringen und diese Versionen die bisherigen auch noch durch Auto-Updates ersetzen, dann setzen sich neue, nützliche Funktionen schneller durch.
Ich als Entwickler nutze z.B. sehr gern CSS3-basierte abgerundete Ecken, Schatten und natürlich Animationen. Eine einfache kleine Animation, bei der sich ein Link sanft verfärbt, sobald man darüber hovert, kostet in CSS3 nur 2 kurze Codezeilen. In JavaScript ist das ein Wald von Befehlen.

Je schneller Browser in neuen Versionen den Markt erobern, desto schneller kann man als Entwickler auch für neue Features entwickeln. Der IE9 war, als er raus kam, technisch schon ein ganzes Stück hinterm FF hinterher. Der IE10 wird zum Release einen neuen Maßstab setzen, den Chrome, FF und Opera aber innerhalb von wenigen Wochen problemlos einholen werden, nur damit danach für die nächsten 3-4 Jahre bis IE11 die Entwicklung des Netzes wieder stagniert, weil der IE die primäre Bremse ist.

MrEisbaer schrieb:
Hier lesen einige nur "Verschlüsselung", das Hirn geht auf Stand-by und es wird als sicher gefeiert, ohne auch nur mal einen Gedanken darüber zu verschwenden das es Hintertüren und/oder Schwachstellen gibt.
OK, du bist scheinbar Krypto-Experte bei der NSA. Du darfst uns an deinem Wissen nicht öffentlich teil haben lassen. Wir habens begriffen. Du bist so viel klüger als wir.

So... und jetzt: LIES DIE SPEZIFIKATIONEN VON SPDY UND SUCH DIE LÜCKE!


Simon schrieb:
Beim IIS ist das ein Problem, beim Apache dank Virtual Hosts ist das kein Problem, mehrere unterschiedliche Webseiten mit unterschiedlichen Hostheadern und SSL-Zertfikaten auf ein und derselben IP zu hosten. ;)
Darauf hab ich schon hingewiesen. Multiple SSL-Sites auf einer IP geht nur mit SNI. Wenn es dir egal sein kann, dass weder Android 2.x - Devices noch der IE unter XP auf deine sites kommen, dann kannstes nutzen.
 
Zuletzt bearbeitet:
MrEisbaer schrieb:
Hier lesen einige nur "Verschlüsselung", das Hirn geht auf Stand-by und es wird als sicher gefeiert, ohne auch nur mal einen Gedanken darüber zu verschwenden das es Hintertüren und/oder Schwachstellen gibt.


Hier lesen einige nur "Google", das Hirn geht auf Stand-by... merkst du selbst, ne?

Du hast überhaupt nicht begriffen, was solch ein Protokoll überhaupt tut. Das ist "tote Materie", die nur sagt wie etwas auszusehen hat, ein Bauplan quasi. Das ist kein aktives Programm o.ä. das auf deinem PC läuft.

Wenn Google an die Daten möchte, dann muss Google die Daten irgendwo abgreifen. Das liegt aber gar nicht im Kompetenzbereich eines solchen Protokolls, das ist nur Verpackungsmaterial für deine Daten, das kann sonst nichts.

Da braucht man nicht mit Verschlüsselung herum argumentieren, SPDY könnte auch gar keine Verschlüsselung haben und deine Ängste bzgl. Google wären nicht einen Millimeter begründeter.
 
MrEisbaer schrieb:
Merk schon, hier sind einige Intelligenz-Allergiker die das denken ihrem Computer überlassen, anstatt ihr Hirn zu benutzen.

Hier lesen einige nur "Verschlüsselung", das Hirn geht auf Stand-by und es wird als sicher gefeiert, ohne auch nur mal einen Gedanken darüber zu verschwenden das es Hintertüren und/oder Schwachstellen gibt.

Stattdessen werden Leute als Troll etc. hingestellt, die es auch nur ansatzweise wagen Kritik zu üben, ist ja genauso wie wenn man was gegen Amerika sagt, ist man sofort ein Amerika Basher.

Huldigt ihr mal weiter eurem Glauben das SPDY sicher ist und werdet Glücklich.
Ihr glaubt dann auch das HTTPS sicher ist.

In meinen Augen bist du ein typischer Vertreter der "Web 2.0, aber 0.0 Ahnung - Generation": man liest ein Reizwort (in dem Fall "Google") und lässt ohne Hintergrundinformationen erstmal den 0815-Bash los. Das machen Millionen von Leuten Tag für Tag – anscheinend ist es inzwischen störend oder gar merkwürdig, wenn man sich vorher informiert bevor man seinen Senf dazu gibt.

Für jemanden wie mich, der im Studium ein halbes Dutzend male Netzwerkprotokoll und IT-Sicherheit Vorlesungen über sich ergehen lassen musste, hören sich deine Kommentare einfach nur schmerzhaft an, weil soviel technischer Un-Sachverstand aus ihnen spricht.

Ungefähr so schmerzhaft, als ob jemand behaupten würde, die Regierung forciert den Internet-Ausbau nur um uns besser überwachen zu können. Oder wenn Oma Luise meint, morgen übernehmen die Roboter die Weltherrschaft.

Eine kurze Zusammenfassung, wieso deine Argumente fail sind und du etwas kürzer treten solltest:
* Zu einem Protokoll gehört eine Spezifikation bzw Beschreibung von Features die implementiert sein müssen, um kompatibel zu dem entsprechenden Protkoll-Standard zu werden
* Eine Spezifikation enthält keinen Code, die konkrete Implementierung muss der Browser / Betriebssystem selbst übernehmen
* Die verwendete Verschlüsselung ist TSL, also der SSL-Nachfolger, mit dem Google garnichts am Hut hat
* Wenn Google mit dem Protokoll sammeln wollen würde, müsste in der Spezifikation stehen: "Als weiterer Schritt soll nach jeder Anfrage an einen Webserver die IP, das verwendete Browser / Betriebssystem und alle weiteren Informationen an google.com:4711 übermittelt werden." Falls das so in der Spezifikation steht, wird das früher oder später jemanden auffallen. Anders könnte man auch keinen Zugriff auf irgendwelche Datenströme bekommen, da SPDY mMn immer noch ein Point-to-Point Protokoll ist.

Grüße TheShaft
 
ice-breaker schrieb:
Dann mach das heute nochmal, wo im Gegensatz zu 10 Jahren der Traffic viel höher ist ;) Bei einigen Millionen Zugriffen kommt da einiges an Mehrlast zusammen. Dieser ist zwar prozentual der Gleiche, aber gerade erst die Masse macht bei SSL den Ausschlag. Bei 10 Zugriffen pro Sekunde passiert da noch nicht viel.

Es war eine Anwendung mit viel Traffic, ca. tausend TCP-Connects pro Sekunde in der Spitze. Und das SSL-offloading ging im Grundrauschen unter.

ice-breaker schrieb:
Richtig, aber diese überdauern die Aktion in der ein Standard-User denkt er anonymisiert sich: er löscht alle Cookies und fertig.

Ich habe damals das Verhältnis von vollen Handshakes und und gültiger Session-ID analysiert, Zwei Drittel aller TCP-Connects hatten einen vollen SSL-Handshake.
 
Zurück
Oben