In der Zwischenzeit habe ich einige Webbrowser miteinander verglichen und bin zu folgendem Ergebnis gekommen, welches in der nächsten Zeit sicherlich noch etwas weiter ausgebaut wird.
So kann z.B. der beliebte Webbrowser Firefox auf die Ports 20, 21, 22, 23, 25, 110, 111, 113, und viele weitere nicht mittels HTTP zugreifen.
Die vollständige Liste der gesperrten Ports befindet sich hier: http://www.mozilla.org/projects/netlib/PortBanning.html
Heute wollte ich sehen, ob Microsofts Internet Explorer 7 (genauer: 7.0.5730.11) auch über gesperrte Ports verfügt und habe das kurzer Hand schnell getestet: ja, er verfügt über einige wenige Port-Blockaden. Diese lauten wie folgt (ohne Anspruch auf Vollständigkeit):
Doch wie gestalten sich solche Blockaden in anderen Webbrowsern ? Falls jemand Lust und Zeit hat, kann er oder sie gerne hergehen und dies einmal überprüfen. Über eine Rückmeldung würde ich mich freuen, da ich dann selber weniger Arbeit habe und die Ergebnisse gerne in einer Tabelle festhalten würde.
Leider funktioniert die Extension mit Firefox 3 nicht mehr.
Eine kurze Analyse hat gezeigt, dass der neue Zwang zur Angabe eines Charsets im Header für einen XMLHttpRequest (XHR) für Probleme seitens der Fritz!Box sorgt. Diese kann mit dem charset=... nichts anfangen und verweigert ihren Dienst.
Selbst wenn man explizit keine charset-Angabe in der Methode requestHeader() macht, so wie es die Extension auch tut, setzt Firefox 3 nun standardmässig das Charset rein (auf UTF-8).
Hat irgendjemand eine Idee, wie man Firefox 3 von diesem Zwang befreien kann ?
Da ich heute früh endlich Windows Vista auf dem Acer Aspire 7520G entfernt habe und nun Windows XP (für knapp 67 EUR) auf dem Laptop seine Arbeit anstandslos verrichtet, habe ich mich gleich an die Installation von Firefox 3 gemacht. Gut, dass auf dem schnelleren Laptop der langsame Firefox nicht so sehr auffällt. Evtl. ist das vor ein paar Tagen beschriebene Problem gar nicht existent ...
Daher habe ich zweimal beim Download Day mitgemacht und spaßeshalber habe ich mir auch ein "Zertifikat" dafür ausgestellt. 
Wer beim Download Day und dem damit verbundenen Eintrag ins Guinness Buch der Rekorde mitmachen will, der hat nach MESZ noch bis heute 19:00 Uhr Zeit dazu.
Nachdem bei mir aber vieles nicht mehr anständig funktioniert, seitdem ich den Firefox 3 mit einer der verfügbaren Beta-Versionen installiert habe, muss ich wohl oder übel ein neues Profil erstellen und sämtliche Werte, die ich von Hand angepasst habe, erneut anpassen. Das wird wieder viel Arbeit ...
Update: Oder auch kaum Arbeit, wenn man die Datei prefs.js zur Hilfe nimmt. 
Da ich bislang noch keinen freien Feed-Reader finden konnte und der Feed-Reader im Opera Mini mir etwas suspekt und langsam erscheint, habe ich jetzt meinen eigenen erstellt. Er ist allerdings auch noch nicht ganz fertig, läuft aber schon recht problemlos.
Jetzt suche ich nur noch einen Webbrowser oder ein passendes Add-On für den IE, Opera Mini, Opera Mobile oder auch MiniMo, welches den Quelltext einer Webseite anzeigen kann.
Außerdem wäre ein besseres und freies E-Mail Programm nicht schlecht, da man mit dem integrierten keine E-Mails von seinem T-Online-Account verschicken kann, wenn dies verschlüsselt geschehen soll.
Einen freien Jabber-Client suche ich ebenfalls, da MGTalk nicht funktioniert.
Ein Programm für einen Countdown und für eine Stoppuhr suche ich ebenfalls noch. Das solche Standard-Anwendungen fehlen, ist schon etwas seltsam. Sind sie doch fast bei jedem Handy dabei.
Wahrscheinlich muss ich für einiges wieder selber in die Trickkiste greifen. Für Vorschläge, Empfehlungen oder Anregungen bin ich allerdings jederzeit offen.
Dafür hat mir die neue Version gleich ein neues Problem beschert: wenn man ein Bookmark zu einer Webseite anlegt, die vor dem eigentlichen Abruf erst mittels HTTP Auth Logindaten bearbeitet werden muss, und diese in der Form:
https://benutzername:passwort@example.com/pfad
eingibt, so funktioniert dies in der neusten Beta leider nicht mehr automatisch. Jetzt muss man sie wieder händisch eingeben. (Vielleicht betrifft dies neuerdings auch nur SSL-verschlüsselte Verbindungen. Unverschlüsselte habe ich nicht getestet.)
Hoffentlich bleibt diese Einschränkung nur bis zur Final. Es war doch recht bequem.
(Ja, auch unsicher, solange man keine anderen Vorkehrungen trifft.)
Leider ist dies bei HTTP/HTTPS auch nicht über ein RFC standardisiert, sondern nur bei FTP. Trotzdem machen es alle Webbrowser, die mir so einfallen, dennoch richtig.
Das gibt, wie ich hier schon einmal erwähnt hatte, auf jeden Fall Probleme für Betreiber von Webseiten mittels CAcert-Zertifikat (oder einem self-signed Zertifikat).
Da der Nutzer nicht mehr zur Interaktion gezwungen wird, wie eins mit dem Dialogfeld, dessen Voreinstellung das temporäre Erlauben der Webseite gewesen wäre, werden sicherlich viele Nutzer die Webseite verlassen, bevor sie sie richtig aufgesucht haben.
Da CAcert als CA auch im Firefox 3.0 noch nicht dabei sein wird (abgesehen von einigen Linux-Distributionen, die CAcert als CA gleich dazupacken), werden meiner Ansicht nach viele Nutzer aus Sicht des Betreibers einer Webseite ausgesperrt werden. Andererseits ist es eine ausführliche Warnung natürlich besser für die Sicherheit.
Wenn ein Nutzer nun das Zertifikat akzeptieren will (egal ob temporär oder permanent), so durchläuft er folgende Screenshot-Abfolge:
auto beta biometrie bluetooth buffer-overflow bug charts coding d-box 2 dos dsl e-mail exploit festnetz firefox firewall hacking handy hardware iptv it security javascript konsole kryptographie linux mac os malware mp3 musik navigation penetration testing phishing plugins root router spam sql-injection ssl t-com truecrypt urlaub vista vm web webbrowser Windows wlan wohnen xp xss
