Firefox 5???

[Das Brot]

liebes Prekariat,

gerade kürzlich erst habe ich meine FF auf 4.0 erhöht. Jetzt kriege ich ein Popup, daß ich dringend ein "Sicherheitsupdate" auf 5.0 ausführen soll. Geht das mit rechten Dingen zu, oder geht da der Virus um? Seit wann ist ein Sicherheitsupdate mit einem Upgrade verbunden?

[peterpan]

liebes Prekariat,

gerade kürzlich erst habe ich meine FF auf 4.0 erhöht. Jetzt kriege ich ein Popup, daß ich dringend ein "Sicherheitsupdate" auf 5.0 ausführen soll. Geht das mit rechten Dingen zu, oder geht da der Virus um? Seit wann ist ein Sicherheitsupdate mit einem Upgrade verbunden?

Ich bin mit 5.0 unterwegs, also alles in Ordnung. (Obs ne Sicherheitslücke in 4.0 gab oder nicht, ist mir nicht bekannt)

Gruss

[Gunnar Bittersmann]

@@peterpan:

nuqneH

(Obs ne Sicherheitslücke in 4.0 gab oder nicht, ist mir nicht bekannt)

Es gab schon ein Sicherheitsupdate auf 4.0.1, aber das ist schon nicht mehr aktuell.

Qapla'

[Gunnar Bittersmann]

@@Das Brot:

nuqneH

gerade kürzlich erst habe ich meine FF auf 4.0 erhöht. Jetzt kriege ich ein Popup, daß ich dringend ein "Sicherheitsupdate" auf 5.0 ausführen soll. Geht das mit rechten Dingen zu, oder geht da der Virus um? Seit wann ist ein Sicherheitsupdate mit einem Upgrade verbunden?

Seitdem Firefox am Rad dreht. S.a. aktuellten Thread Firefox 5 released.

Qapla'

[Kai345]

[latex]Mae  govannen![/latex]

Seitdem Firefox am Rad dreht.

Ach was, alles ganz normal (s. auch die (fast nicht zu erkennnenden) Link(s) im Artikel und Kommentare).

Stur lächeln und winken, Männer!
Kai

[Das Brot]

Stur lächeln und winken, Männer!

Woher kommt eigentlich dieser geile Spruch? Aus einem Film?

[Matthias Apsel]

Om nah hoo pez nyeetz, Das Brot!

Stur lächeln und winken, Männer!

Woher kommt eigentlich dieser geile Spruch? Aus einem Film?

GidF.

Matthias

[molily]

Ach was, alles ganz normal

»Laut Kaply würden mit den kommenden Firefox-Versionen 5, 6, 7 und 8 ständig neue grundlegende Änderungen seitens Mozilla vorgenommen. Somit sei beispielsweise eine ständige Anpassung aller Webanwendungen eines Unternehmens erforderlich.«

Das ist, wie jeder mit den Webtechniken vertraute Mensch weiß, natürlich Humbug: Eine Webanwendung, die unter Firefox 4 funktioniert, wird unter Firefox 5 genauso gut, wenn nicht besser funktionieren, solange sie mit Webstandards arbeitet, zu denen Firefox konform ist.

Es passiert hingegen äußerst selten, dass sich technische Änderungen ergeben, welche das Verhalten gegenüber bestehenden Websites ändern. Die häufigsten Fälle sind:

• Die vorher fehlerhafte Implementierung wird korrigiert, sodass Firefox standardkonformer wird,
• eine experimentelle API ändert sich oder es werden neue Sicherheitsmechanismen eingebaut.

Davon abgesehen ist Firefox 5 natürlich abwärtskompatibel mit Websites, die mit Firefox 4 getestet wurden.

Allgemein halte ich die Kritik dennoch für angebracht: Mozilla kümmert sich nicht um Firmenkunden. Das mag seine Gründe haben, aber angesichts dessen sollte man sich nicht wundern, warum Firmen sich Microsoft zuwenden und in ihren Intranets gewisse Internet-Explorer-Versionen »verbacken« und diese über lange Zeit nicht aktualisieren. Daher kommt das Problem alter Browser wie IE 6 und 7. Gerade in diesem Bereich wäre Konkurrenz wünschenswert.

Mathias

[Don P]

Hallo,

Es passiert hingegen äußerst selten, dass sich technische Änderungen ergeben, welche das Verhalten gegenüber bestehenden Websites ändern. Die häufigsten Fälle sind:

[...]

• eine experimentelle API ändert sich oder es werden neue Sicherheitsmechanismen eingebaut.

Tja, es ist gerade passiert. Mit Version 5 haben sie den FireFox kaputtgesichert.

Davon abgesehen ist Firefox 5 natürlich abwärtskompatibel mit Websites, die mit Firefox 4 getestet wurden.

Davon abgesehen vielleicht schon.

Gruß, Don P

[molily]

• eine experimentelle API ändert sich oder es werden neue Sicherheitsmechanismen eingebaut.

Tja, es ist gerade passiert. Mit Version 5 haben sie den FireFox kaputtgesichert.

Du verwendest eine nicht standardisierte, nicht wirklich dokumentierte (?) interne API, um die Same-Origin-Policy zu umgehen, um im file-Kontext einen Webservice zu kontaktieren – es verwundert mich nicht, dass das nicht mehr geht.

Der Webservice sollte sinnvollerweise ein JSONP-Webservice sein sollte oder zumindest CORS unterstützen, dessen Unterstützung Firefox 5 erst verbessert hat.

Mathias

[Don P]

Hallo,

Du verwendest eine nicht standardisierte, nicht wirklich dokumentierte (?) interne API

Dokumentiert ist sie durchaus. Gerade diese recht unkomplizierte Cross-Domain-AJAX-Fähigkeit war u.a. der Grund, warum mein Programm auf Firefox zugeschnitten ist, so dass andere Browser es jetzt eh nicht korrekt ausführen können. Mein Programm kann die benötigten echten Zufallszahlen nunmal nicht aus dem Ärmel schütteln, aber eine simple AJAX-Abfrage hat sie dann geliefert, und gut.

Der Benutzer wird vor dem Request zwangsläufig vom Browser mit einem Hinweis auf Sicherheitsrisiko konfrontiert, wobei er bestätigen oder ablehnen kann. Das finde ich vernünftig und sicher genug. Wer das Progrmm benutzt, der weiß auch, was er tut, und sonst soll er halt ablehnen.

Was soll am bewussten Runterladen von Daten via AJAX überhaupt riskant sein?
Den Script-Tag-Hack dagegen hat man sicher nicht abgestellt, mit dessen Hilfe man jedes JavaScript aus aller Welt laden und ausführen kann, und zwar ohne dass der Benutzer etwas davon merkt.

Der Webservice sollte sinnvollerweise ein JSONP-Webservice sein sollte oder zumindest CORS unterstützen, dessen Unterstützung Firefox 5 erst verbessert hat.

Sollte er? Nur weil der tolle Browser nicht mehr anders will? Klar, man könnte auf den Service verzichten oder den Betreiber drängen, doch bitte diese und jene Technologie zu unterstützen, damit die Browser wieder für eine Weile zufrieden sind...

Bis jetzt war ich überzeugter Fan von FireFox, gerade weil der nicht so ein Heckmeck um jeden Sch... machte, sondern einfach nur funktionierte.

Naja, mich wundert's auch nicht wirklich, trotzdem bin ich ziemlich verärgert.

Gruß, Don P

[ChrisB]

Hi,

Was soll am bewussten Runterladen von Daten via AJAX überhaupt riskant sein?

Was sollte am Anzeigen einer fremden Seite in einem Frame irgendwem nicht passen ...?

Cross-Domain AJAX ohne Einschränkungen brächte das Thema, das bei Frame lange aktuell war - unerwünschtes (clientseitiges) Aneignen fremder Inhalte - wieder auf den Tisch.
Und deshalb muss bei Cross-Domain AJAX auch die Gegenseite mitspielen, in dem sie entsprechende Header sendet und damit ihr „Einverständnis“ gibt - so simpel ist das.

MfG ChrisB

[Don P]

Hallo,

Cross-Domain AJAX ohne Einschränkungen brächte das Thema, das bei Frame lange aktuell war - unerwünschtes (clientseitiges) Aneignen fremder Inhalte - wieder auf den Tisch.
Und deshalb muss bei Cross-Domain AJAX auch die Gegenseite mitspielen, in dem sie entsprechende Header sendet und damit ihr „Einverständnis“ gibt - so simpel ist das.

Kann man so sehen, ist aber irgendwie das Pferd von hinten aufgezäumt. Wenn der Client CORS unterstützt, ist das ja ok. Wenn der Server es nicht tut – selber schuld. Dann darf der Server-Admin sich auch nicht wundern, wenn seine Inhalte unerwünscht angezeigt werden.

Soll heißen: Statt die Server zu zwingen, CORS zu unterstützen, sollte man es ihnen freistellen. Ein Server, der auf Same Origin wert legt, kann ja den Header vom Client auswerten und einfach mit "503 Access denied" antworten, wenn der ihm nicht passt. Wenn er aber "200 ok" liefert, gilt das natürlich als Einverständnis, und gut. Wieso soll der Server überhaupt extra CORS-Info schicken? Es reicht doch, dass er die angefragten Daten sendet oder eben nicht.

So wie es jetzt mit FireFox 5 gemacht wurde, laufen einige Programme einfach nicht mehr, weil man kurzerhand die Clients brutal beschnitten hat. Das gibt Mecker seitens der Benutzer in Richtung clientseitige Programmierer, die dann wiederum bei den Serverbetreibern auf der Matte stehen müssen...

Gruß, Don P

[ChrisB]

Hi,

Kann man so sehen, ist aber irgendwie das Pferd von hinten aufgezäumt.

Das machst *du* doch am liebsten ...

Soll heißen: Statt die Server zu zwingen, CORS zu unterstützen, sollte man es ihnen freistellen.

Es ist jedem Serverbetreiber freigestellt zu sagen: Ja, von der Domain ausgehend dürfen meine Daten per clientseitigem AJAX eingebunden werden.

Ein Server, der auf Same Origin wert legt, kann ja den Header vom Client auswerten und einfach mit "503 Access denied" antworten, wenn der ihm nicht passt.

Welchen Header?

Wenn er aber "200 ok" liefert, gilt das natürlich als Einverständnis, und gut.

Hat er bei Frames auch gemacht - ein Einverständnis stelle das aber noch lange nicht dar.
U.a. deshalb gibt's jetzt den X-Frame-Options-Header.

So wie es jetzt mit FireFox 5 gemacht wurde, laufen einige Programme einfach nicht mehr, weil man kurzerhand die Clients brutal beschnitten hat. Das gibt Mecker seitens der Benutzer in Richtung clientseitige Programmierer, die dann wiederum bei den Serverbetreibern auf der Matte stehen müssen...

Dann muss dieser Programmierer jetzt halt mal das nachholen, was er bisher versäumt hat.

MfG ChrisB

[Don P]

Hallo,

Soll heißen: Statt die Server zu zwingen, CORS zu unterstützen, sollte man es ihnen freistellen.

Es ist jedem Serverbetreiber freigestellt zu sagen: Ja, von der Domain ausgehend dürfen meine Daten per clientseitigem AJAX eingebunden werden.

Eben. Er darf auch sagen: Ja, von *jeder* Domain aus dürfen meine Daten eingebunden werden. Das Dumme ist nur, dass er jetzt anscheinend zwingend so eine Äußerung machen *muss*. Vorher hat es gereicht, die Daten einfach zu liefern oder nicht, je nachdem, wer danach fragt.

Ein Server, der auf Same Origin wert legt, kann ja den Header vom Client auswerten und einfach mit "503 Access denied" antworten, wenn der ihm nicht passt.

Welchen Header?

Den Request-Header, den der Client mitsendet. Wenn ein Script, das von einer file://-Ressource geladen wurde, einen AJAX-Request absetzt, dann sendet der Client u.a. origin=null im Request-Header. Daran kann der Server sehen, wenn er es denn beachten will, dass die Anfrage nicht von seiner eigenen Domain mit origin=example.org stammt sondern eben von irgend einer file://ressource, und kann den Zugriff verweigern.

Es ist wie bei der Diskussion um Organspende: Man überlegt zur Zeit, ob nicht einfach jeder als potenzieller Spender gelten soll, der das nicht ausdrücklich verweigert hat. Für AJAX wäre dieses Vorgehen vernünftig. Statt dessen werden jetzt *aus heiterm Himmel* alle Server gezwungen, mit einem Header-Eintrag explizit zuzustimmen, sonst ist das bisher funktionierende AJAX kaputt.

Das gibt Mecker seitens der Benutzer in Richtung clientseitige Programmierer, die dann wiederum bei den Serverbetreibern auf der Matte stehen müssen...

Dann muss dieser Programmierer jetzt halt mal das nachholen, was er bisher versäumt hat.

Dieser Programmierer bin u.a. ich, und ich habe doch nichts versäumt, sondern nur den FireFox so benutzt, wie das von Mozilla beschrieben ist, dass man es tun kann. Klammheimlich und urplötzlich unterstützt er das nicht mehr?

Es gibt ja nichts, was *ich* als Programmierer dagegen tun könnte, außer eben die Serverbetreiber bitten ihre Technologie umzustellen. Nicht, weil ich es will, sondern weil mein Werkzeug, der Browser, es eigenmächtig so entschieden hat.

Das wäre schon eine Anmaßung, und ich kann noch nicht ganz glauben, dass es wirklich so ist. Vielleicht ist ja doch nur ein Bug... Immerhin erscheint ja nach wie vor die Sicherheitsmeldung, und nachdem der Benutzer einem Cross-Domain-Request zugestimmt hat, wird der auch abgesetzt und keine Exception geworfen. Leider kommen aber die Antwort-Daten vom Server nicht mehr bis zum Benutzer durch...

Gruß, Don P

[molily]

Welchen Header?

Den Request-Header, den der Client mitsendet.

Was ist der »Request-Header«? Meinst du den Referrer? Dieser ist optional und kann bekanntlich beliebig gefälscht werden.
CORS definiert keine Request-Header, in welchen die Herkunft drinsteht. Nur bei Preflight-Requests werden einige Daten des darauffolgenden tatsächlichen Requests vorab in neuen Headern mitgesendet.

Es ist wie bei der Diskussion um Organspende: Man überlegt zur Zeit, ob nicht einfach jeder als potenzieller Spender gelten soll, der das nicht ausdrücklich verweigert hat. Für AJAX wäre dieses Vorgehen vernünftig. Statt dessen werden jetzt *aus heiterm Himmel* alle Server gezwungen, mit einem Header-Eintrag explizit zuzustimmen, sonst ist das bisher funktionierende AJAX kaputt.

Offenbar bist du über die Sachlage nicht informiert. Bis auf die von dir genutzte proprietäre Mozilla-Methode, welche m.W. für interne XUL-Scripte und konventionelle Firefox-Addons existiert, gibt es keine Möglichkeit, die Same-Origin-Policy einfach so umgehen. CORS macht *nicht* funktionierendes Ajax kaputt, das ist Quatsch. Dieses Verhalten ist seit dem Anfang des Webs Standard. Es werden nicht plötzlich alle Server zu irgendetwas gezwungen. Es gibt jetzt nur die Möglichkeit eines Opt-Ins für Cross-Domain-Requests. Was du da machst, ist ein Ausnahmefall, der im normalen Webkontext keine Verwendung findet. Es hat sich nichts groß geändert, außer dass Firefox meiner Vermutung nach einen Regression-Bug eingebaut hat.

Dieser Programmierer bin u.a. ich, und ich habe doch nichts versäumt, sondern nur den FireFox so benutzt, wie das von Mozilla beschrieben ist, dass man es tun kann. Klammheimlich und urplötzlich unterstützt er das nicht mehr?

Das sind Mutmaßungen. Wenn du an einer Klärung interessiert bist, so frage wie gesagt die Firefox-Entwickler. Da wirst du sicher schnell eine Antwort bekommen. Dass in Firefox 5 am Cross-Domain-Zugriff gearbeitet wurde, habe ich bereits ausgeführt; genaueres kannst du im Übrigen dem Changelog entnehmen.

Mathias

[Don P]

Hallo,

Welchen Header?

Den Request-Header, den der Client mitsendet.

Was ist der »Request-Header«? Meinst du den Referrer?

Anscheinend habe ich den Begriff »Header« nicht richtig verwendet. Ich meine eigentlich das ganze Header-Zeug, das der Client beim Request vor eventuell zu postenden Daten sendet. Der Referrer ist nur einer davon. Vor allem meine ich den »Origin-Header«

Ich zitiere mal von Mozilla:

For example, suppose web content on domain http://foo.example wishes to invoke content on domain http://bar.other.  Code of this sort might be used within JavaScript deployed on foo.example:

var invocation = new XMLHttpRequest();  
var url = 'http://bar.other/resources/public-data/';  
  
function callOtherDomain(){  
  if(invocation)  
  {  
    invocation.open('GET', url, true);  
    invocation.onreadystatechange = handler;  
    invocation.send();  
  }  
}  

• Zitat Ende -

Das ist genau die Anleitung zu dem, was ich mache. Es wird dann weiter ausgeführt, Zitat:

Let us look at what the browser will send the server in this case, and let's see how the server responds:

[Firefox fragt an:]
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

[Server antwortet:]
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

Lines 1 - 11 are headers sent by Firefox 3.5.

• Zitat Ende -

Und dann heißt es noch: "Note that the main HTTP request header of note here is the Origin: header"

Anhand von diesem "Origin-Header" kann doch der Server entscheiden, ob er den Request akzeptiert oder nicht. Es leuchtet mir nicht ein, warum der Browser nun partout verlangt, dass der Server vor den angeforderten Daten noch einen entsprechenden »Access-Control-Allow-Origin:« sendet.

Was soll das? Wenn es der Server nicht erlauben will, soll er halt gar keine Daten senden und dem Browser das mitteilen mit "503 - Ätsch!". Die trotzdem gesendeten Daten brauchen doch nur unnötig Bandbreite und Energie während sie um den Planeten reisen, um schließlich vom Browser verworfen zu werden, weil der keinen passenden »Access-Control-Allow-Origin:« findet, *kopfpatsch*.

Offenbar bist du über die Sachlage nicht informiert. [...] Was du da machst, ist ein Ausnahmefall, der im normalen Webkontext keine Verwendung findet.

Wenn du es sagst, ok dann halt. Der normale Webkontext kann mir hier aber gestohlen bleiben ;)

Es hat sich nichts groß geändert, außer dass Firefox meiner Vermutung nach einen Regression-Bug eingebaut hat.

Das ist schlimm genug, wenn man direkt davon betroffen ist.

Wenn du an einer Klärung interessiert bist, so frage wie gesagt die Firefox-Entwickler.

Das werde ich wohl machen... und wahrscheinlich erzählen sie mir was Ähnliches wie du ;)

Gruß, Don P

[molily]

Vor allem meine ich den »Origin-Header«

Stimmt, den hatte ich übersehen. Ich bitte um Entschuldigung.

Für den Aushandlungsprozess ist der Header (dem Server) allerdings nicht wichtig, sofern ich das richtig sehe.

Anhand von diesem "Origin-Header" kann doch der Server entscheiden, ob er den Request akzeptiert oder nicht.

Das könnte er, ja.

Es leuchtet mir nicht ein, warum der Browser nun partout verlangt, dass der Server vor den angeforderten Daten noch einen entsprechenden »Access-Control-Allow-Origin:« sendet.

Es wurde entschieden, diese Aushandlung komplett auf dem Level von HTTP umzusetzen, nicht erst auf der darüber liegenden Anwendungslogik. Es soll für die Anwendungen darüber transparent sein. Nicht der Server soll entscheiden, ob ein Cross-Domain-Request erlaubt ist, sondern der Browser soll anhand der Whitelist entscheiden, ob die Response (im konkreten Fall) an das JavaScript in der Sandbox weitergegeben wird.

Wenn es der Server nicht erlauben will, soll er halt gar keine Daten senden und dem Browser das mitteilen mit "503 - Ätsch!". Die trotzdem gesendeten Daten brauchen doch nur unnötig Bandbreite und Energie während sie um den Planeten reisen, um schließlich vom Browser verworfen zu werden

Dafür gibt es Preflight-Requests.

Die genauen Hintergründe der Architektur-Umsetzung von CORS sind mir nicht bekannt, daher kann ich diese Entscheidung weder begründet angreifen noch verteidigen.

Mathias

[molily]

Soll heißen: Statt die Server zu zwingen, CORS zu unterstützen, sollte man es ihnen freistellen.

Macht man doch: Default ist sicher, per Opt-In bekommt man Cross-Domain-Zugriff. Anders herum hätte man es theoretisch machen können, aber nur bei der Erfindung vom WWW. Dass man es nicht getan hat und die restriktive Einstellung default ist, hat allerdings seinen Grund.

So wie es jetzt mit FireFox 5 gemacht wurde, laufen einige Programme einfach nicht mehr, weil man kurzerhand die Clients brutal beschnitten hat.

Frage doch einfach mal auf einer Mozilla-Developer-Mailingliste nach, bevor du hier rhetorisch Geschütze auffährst.

Das gibt Mecker seitens der Benutzer in Richtung clientseitige Programmierer, die dann wiederum bei den Serverbetreibern auf der Matte stehen müssen...

Vielleicht merken die clientseitigen Programmierer dann, dass proprietäre Hacks unzuverlässig sind und Serverbetreiber, dass sie vernünftige Webservice-APIs anbieten sollen. :)

Mathias

[molily]

Du verwendest eine nicht standardisierte, nicht wirklich dokumentierte (?) interne API

Dokumentiert ist sie durchaus.

Dem kann ich nicht entnehmen, dass XHR domainübergreifend möglich ist.

Was soll am bewussten Runterladen von Daten via AJAX überhaupt riskant sein?

Meinst du das ernst? Ich soll ich dir erklären, warum die Same-Origin-Policy generell sinnvoll ist?

Den Script-Tag-Hack dagegen hat man sicher nicht abgestellt, mit dessen Hilfe man jedes JavaScript aus aller Welt laden und ausführen kann, und zwar ohne dass der Benutzer etwas davon merkt.

Das ist kein Hack, sondern hat System. Es ist i.d.R. keine Sicherheitslücke, Scripts von anderen Servern zu laden. JSON-Diebstahl mit überschriebenen Kernobjekt-Konstruktoren war da die Ausnahme. Mit <img> und <iframe> ist es möglich, GET-Requests abzufeuern, mit <form> lassen sich POST-Request absenden, ohne auf die Rückgabe zugreifen zu können. Das CSRF-Potenzial ist weitaus geringer als zu vollem XHR-Zugriff.

Der Webservice sollte sinnvollerweise ein JSONP-Webservice sein sollte oder zumindest CORS unterstützen, dessen Unterstützung Firefox 5 erst verbessert hat.

Sollte er? Nur weil der tolle Browser nicht mehr anders will?

Nein, weil das die vernünftige und richtige Lösung wäre.

Klar, man könnte auf den Service verzichten oder den Betreiber drängen, doch bitte diese und jene Technologie zu unterstützen, damit die Browser wieder für eine Weile zufrieden sind...

Ein in JavaScript nutzbarer Webservice sollte JSONP oder CORS bieten, ja, so einfach ist das. Weil das die bleibenden Techniken Cross-Domain-Zugriffe sind. Es dürfte für den Betreiber sehr einfach sein, etwa JSONP zu implementieren.

Mathias

[molily]

Das sind noch interessante Ergänzungen:
http://www.glazman.org/weblog/dotclear/index.php?post/2011/06/25/I-just-don-t-understand
http://mike.kaply.com/2011/06/24/why-do-companies-need-time-to-deploy-browsers/
Diese Argumente halte ich für Stichhaltiger als die Annahme, dass eine Web-App in einer neuen Browserversion plötzlich kaputt ist.

Mathias