Es ist Zeit: Internet Explorer 6 einfach aussperren
Im Rahmen eines aktuellen Projekts (dazu bald mehr hier in diesem Blog) hab ich mir wieder einmal Gedanken zu jedem Webentwicklers Erzfeind gemacht, dem Internet Explorer 6.
Wenn man sich überlegt, wieviele Stunden verbraucht werden, um Websites, die in jedem aktuellen Browser einwandfrei funktionieren auch noch für den IE6 zu optimieren, dann geht das erstens ganz schön ins Geld und zweitens enorm auf die Nerven. Da könnte man sich durchaus überlegen, das Geld mittels Sammelklage von Microsoft wieder zurückzuholen.
Aber item, ein anderer Ansatz ist es, den IE6 einfach bewusst nicht mehr zu unterstützen, wie es Google endlich als erster Grosser vorgemacht hat. Ist dieser Schritt für kommerzielle Websites tragbar?
Ich habe einmal die Verteilung der Browserverwendung über drei Websites mit gemischtem Zielpublikum und unterschiedlicher Besucherzahl analysiert. Das Ergebnis bezüglich Verwendung des Internet Explorers sah überall im Grossen und Ganzen etwa gleich aus (Klick auf Grafik für grössere Darstellung):
Was die Statistik schön zeigt ist, dass der Internet Explorer 6 weiterhin an Marktanteil verliert. Der Rückgang hat sich in den letzten vier Monaten zwar verlangsamt, aber ist immer noch vorhanden. Schuld daran, dass er überhaupt noch in den Statistiken auftaucht sind bestimmt die Browser an den Arbeitsplätze. Eine Umfrage von mir auf Twitter hat ergeben, dass offenbar viele grosse Firmen wie Novartis, die SBB, Credit Suisse, Kuoni, die Bundesverwaltung etc. noch auf IE6 setzen (alle Angaben unbestätigt und übernommen aus euren Antworten auf Twitter).
Was immer die Gründe dafür sind – aus Sicht der Entwicklung des Webs wäre es an der Zeit, diese Firmen zum Umstieg zu zwingen. Dafür hat es schon einige Ansätze gegeben, doch erfolgreich kann nur der Schritt sein, den IE6 komplett und konsequent auszusperren. Und zwar auf allen Sites, nicht nur auf denen, die im IE6 halt einfach nicht funktionieren. In guter Gesellschaft ist man ja, seit auch YouTube und andere Google-Dienste in diese Richtung gehen.
Anstatt nur darüber zu reden habe ich dies bei einer ersten Seite gleich umgesetzt. Und ja, es handelt sich um eine kommerzielle Site mit welcher wir Geld verdienen und welche auch Kunden hat, die vom Arbeitsplatz aus zugreifen. Wer mit dem Internet Explorer 6 auf Ticketpark surft, kriegt ab sofort diesen Screen zu sehen:
(Update: Wer will darf den Wortlaut dieser Seite natürlich übernehmen.)
Wird uns dies Geld kosten? Wahrscheinlich ja. Ist es trotzdem die richtige Entscheidung? Bestimmt auch, denn der IE6 muss jetzt einfach aktiv bekämpft werden. Und schlussendlich ist jede Minute Aufwand, die in Sachen IE6 gespart wird auch wieder ein gewisser Gewinn.
Jetzt bist du dran!
Ticketpark ist der Anfang. Ich werde mit anderen Sites nachziehen. Und du bist gefragt mitzumachen, auch wenns vielleicht ein bisschen weh tut. Jede Site ist zwar nur ein kleiner Tropfen, aber wie sagen die Macher von Flattr so schön: «Aus vielen Bächen wird ein großer Strom!»
Natürlich gibts hier den entsprechenden PHP-Code dazu. Alternativ können auf Varianten Conditional Comments eingesetzt werden.
//IE6 aussperren mit PHP
$browser = get_browser();
if($browser->browser == 'IE' && $browser->majorver <= 6) {
header("location:http://www.meinesite.ch/ie6.php");
exit;
}//if
Der Befehl get_browser() setzt voraus, dass eine entsprechende browscap.ini-Datei vorhanden ist, welche in der php.ini angegeben sein muss. Dies lässt sich auch mit einer Klasse erledigen.
Mach mit, ich zähl auf dich! Und ich freue mich darauf, wenn die erste Agentur mitzieht und bei Kundenprojekten diesen Weg geht.
Reaktionen:
- 13:20 Uhr. Wir stellen Bill Gates eine Rechnung für den Aufwand, den wir mit all den IE-Optimierungen verbraten haben. Hier entlang: billforbill.com, by @dworni.
- 14:05 Uhr. Josef Weibel macht mit und wird seinen Blog für IE6-Benutzer sperren.
- 14:29 Uhr. Die Swisscom gehört zu den Lieben und meldet auf Anfrage: «Wir setzen den IE 7 ein. Der Wechsel fand vor ca. einem halben/dreiviertel Jahr statt. Hauptgründe waren höhere Sicherheit und bessere Funktionalität.»
- 16.3.2010, 16:00 Uhr. Microsoft Chile meldet auf Twitter: «IE6 es un navegador lanzado hace cerca de diez años. Una década es muchísimo tiempo en años de tec. Actualízate a #IE8». Sinngemäss: «IE6 wurde vor 10 Jahren veröffentlicht. Ein Jahrzehnt sind eine lange Zeit in der Technik. Aktualisiere auf IE8».
- 16.3.2010, 17:22 Uhr. Microsoft bringt bereits erste Previews des IE9. Wir sind bei Safari 4, würdest du Safari 1 noch unterstützen? Also, sperrt den IE6!
Passwörter mit Salz würzen
Kleiner Exkurs für Newcomer-Techies :)
Wir alle wissen: Passwörter gehören nicht im Klartext auf den Server. Auch wenn zuerst einer Zugriff bekommen muss, hat ers einmal geschafft hat er so auch gleich alle Passwörter zur Verfügung (der unliebsame Angriff auf typo3.org klingt noch im Ohr).
Darum werden Passwörter verschlüsselt. Ich nutze dazu gerne die MD5-Verschlüsselung. Mit dem PHP-Befehl md5() wird z.B. aus “sprain” der lange String “7ed679c52f421a2e8a38e7916cee1346″. Das ist schon mal ganz gut, denn eine md5_decode()-Funktion existiert nicht.
Aber natürlich ist MD5 doch ganz einfach zu knacken, nämlich dank sogenannten Rainbow-Tabellen. Dies sind einfach riesige Datenbanken, die zu (fast) jedem MD5-Code ein Klartext-Pendant bereithalten. Probiers einfach mal aus mit obigem String.
Also was tun?
Ganz einfach: Mit Salz würzen! Wir fügen dem Passwort sogenanntes Salt hinzu, einen kurzen nur uns bekannten String. Wie das aussieht?//Verschlüsseln
$salt = "i12*7/aK";
$md5StringZumSpeichernInDB = md5($password.$salt);
//Später entschlüssen
$zuEntschluesselnderString = $password.$salt;
if($md5StringAusDatenbank == md5($zuEntschluesselnderString)){
//Passwort korrekt!
}
Was bringt das nun?
Nun, so verschlüsselt entsteht aus “sprain” der String “48c5d5b6586400d40e9c99bb8c035221″. Der lässt sich nicht mehr so rasch entschlüsseln, denn entweder wird in den Rainbow-Tabellen gar kein Resultat gefunden oder aber ein unbrauchbares. Denn MD5-Strings sind nicht eindeutig. Es kann sein, dass zufälligerweise das Wort “Sonnenblume” auf den erstellten MD5-String passt. Dies bringt dem Angreifer aber nichts, denn ein Loginversuch mit dem Passwort “Sonnenblume” würde vor dem Verschlüsselungs-Vergleich wiederum mit dem Salt-String ergänzt werden – und erhält somit bereits wieder einen anderen Wert, der nicht mit dem korrekten “sprain” ergänzt mit dem Salt-String entspricht.
Eigentlich ein sehr simples Vorgehen, das aber deine Website ein ganzes Stück angriffsresistenter macht.
Neues Projekt: Twitter FriendSuggest
Aus Interesse an der Umsetzung und auch weil ich gespannt auf die Ergebnisse für meinen eigenen Account war, hab ich übers Wochenende ein neues Projektklein aufgestellt:
Twitter FriendSuggest!
Worum gehts?
Basierend auf der Freunde deiner Freunde bei Twitter wird ein Vorschlag generiert, wem du vielleicht folgen möchtest.
Warum machts Spass?
Weil du wahrscheinlich Leute entdecken wirst, die etwas zu sagen haben, die du aber noch nicht wirklich kennst.
Und was wird dir nicht passen daran?
Dass ein Klick auf den Follow-Button einen Tweet in deiner Timeline absetzt. Aber hey, es gibt Alternativmöglichkeiten: Du kannst mit Klick auf den Namen des Users dessen Timeline in Twitter öffnen und gleich dort folgen. Einfach die Checkbox oben auf der Seite enthaken.
Auf der anderen Seite: Wenn dir der Service gefällt sind ein, zwei solche Tweets eigentlich fair, oder? Und bieten bestimmt mehr Nutzen als twitternde Waagen.
«Your request for Twitter API whitelisting has been approved»
Na, dann kanns ja losgehen! :)
Eine reine Online-Währung: Was würde geschehen?
Was würde eigentlich geschehen, wenn wir unsere eigene Online-Währung starten würden? Nennen wir sie der Einfachheit halber mal Webbies. Und der Unterschied zu bestehenden virtuellen Währungen: ein Umtausch in Echtgeld ist nicht möglich.
Wie ist das Vorgehen?
- Die Anmeldung erfolgt über einen bestehenden Service, welcher viele Mitglieder hat. Facebook oder Twitter liegen auf der Hand.
- Jede Neuanmeldung erhält einen Grundstock von 1000 Webbies.
- Über die Plattform können Webbies an andere Benutzer übertragen werden.
- Über einfache Schnittstellen können Anwendungen dafür geschrieben werden: Wordpress-Plugins, die Inhalte nur gegen Bezahlung mit Webbies freigeben. Online-Spiele, bei welchen bestimmte Features/Levels mit Webbies dazugekauft werden können. Oder Terminal-Applikationen, die sogar Bezahlungen im Real-Life zulassen.
Wie gesagt, ein Umtausch in Schweizer Franken, US Dollar oder andere Währungen ist nicht möglich – ebenso auch nicht das Dazukaufen neuer Webbies. Diese muss man sich erwirtschaften mit eigenen Leistungen. Wer seine Webbies alle ausgibt muss sich irgendwo neue verdienen oder sich leihen (auf Kreditplattformen, die sich natürlich basierend auf der Schnittstelle bauen lassen).
Ich bin ökonomisch absolut nicht im Bild.
Darum frage ich euch: Wie würde das wohl enden? Wäre so etwas realistisch?
Coden fürs iPhone
Um’s mit dem aktuellen Trendbegriff auszudrücken: Obenstehendes Foto bietet einen Einblick in mein momentanes Geheimprojekt. Veröffentlichungstermin und obs überhaupt dazu kommt ist offen. Aber auf jeden Fall machts Spass.
JQTouch, Safari und Tweetie
Solange es PastryKit noch nicht gibt, scheint JQTouch eine gute Wahl zu sein als Framework für iPhone-Webapps.
Aber da gibt es bei mir ein seltsames Problem: Die Demo-Ansicht funktioniert auf meinem iPhone 3G S mit OS 3.1.2 auf dem Safari nicht. Klicke aber auf den entsprechenden Link in der Twitter-Software Tweetie 2 klappt es wie erwartet. Muss ich das verstehen?
Update: Keine Ahnung, wie es dazu kam, aber bei meinen Safari-Einstellungen war JavaScript ausgeschaltet. Jetzt klappts.
Trotzdem spannend: Wenn ich im Safari JS ausschalte hat dies offenbar keinen Einfluss auf Sites, die ich innerhalb einer App öffne.
Vortrag über HTML5 und Vorstellung Cappuccino/Atlas
Im Rahmen des stets in relaxtem Rahmen stattfindenen Campus Bern werde ich am 24. November 2009 um 18:30 Uhr über folgende Themen ein bisschen etwas erzählen:
- HTML5. Ein Überblick, was sich ändert, was praxistauglich ist und die Antwort auf die Frage, ab wann HTML5 benutzt werden sollte.
- Atlas/Cappuccino. Erstelle umfangreiche Applikationen, die sowohl im Browser als auch plattformübergreifend als Desktop-Applikation laufen.
Der Event ist öffentlich und kostenlos und findet bei Meteotest in Bern statt. Freue mich, wenn du auch dabei bist.
Web Markup-Sprachen… was ist was?
XHTML 1.0, XHTML 2, HTML 4, HTML 5 und XHTML 5. Die Liste der möglichen Markup-Sprachen, die wir verwenden können um Websites zu coden ist verwirrend lang. Darum hier ein Versuch, mit einfachen Worten etwas Ordnung zu schaffen (ohne zu sehr ins Detail zu gehen)…
HTML 4
HTML 4 ist, was viele von uns in alter Zeit gelernt haben, zum Beispiel mittels der SelfHTML-Dokumentation. Ab HTML 4 konnte vernünftig mit CSS gearbeitet werden, da neu die id, class und style-Attribute standen.
XHTML 1.0
XHTML 1.x basiert auf HTML 4, verwendet aber eine XML-Syntax und ist strikter. Einige Merkmale:
- Kleinschreibung von Tags:
<h1>statt<H1> - Tags sind immer geschlossen: <br /> statt <br>
- Attribute immer in Anführungszeichen und stets mit Name:
<input type="radio" checked="checked" />statt<input type=radio checked> - Ab XHTML 1.1 ist Angabe von Mime-Type erforderlich:
<?xml version="1.0" encoding="UTF-8" ?>
XHTML 2.0
XHTML 2.0 ist nicht als Nachfolger von XHTML 1.0 gedacht. Es war viel mehr ein Versuch für einen Neustart, ohne Rücksicht auf Rückwärts-Kompatibilität. Sämtliche Tags, welche zu Darstellungszwecken dienten (wie z.B. <font>) wurden abgeschafft. Neue Tags, wie z.B. <nl> für Navigationslisten wurden eingeführt. Und jedes Element konnte Linkfunktionalität annehmen, ein <a>-Tag war nicht nötig. Aber wie auch immer… XHTML 2.0 ist bereits tot! Das W3C hat die Arbeit daran eingestellt zu Gunsten von HTML 5!
HTML 5
HTML 5 ist somit die Markup-Sprache der Zukunft. Auch HTML 5 verzichtet auf Tags, welche zur Darstellung genutzt werden. Neue Tags wie <audio>, <video>, <canvas>, <time> und andere wurden eingeführt. Javascript-Funktionalitäten zur Lokalisierung, für Drag&Drop etc. wurden eingeführt. HTML 5 ist rückwärtskompatibel und kann von Browsern, welche HTML 4 verstehen interpretiert werden, wobei jedoch nicht alle neuen Features unterstützt werden. Ich werde in einem späteren Post genauer auf die Eigenheiten von HTML 5 eingehen.
XHTML 5
Und was ist denn nun XHTML 5? Nun, eigentlich ist es wie HTML 5, aber wiederum strikter – und es werden nicht ganz alle Tags von HTML 5 unterstützt. Während in HTML 5 die Nutzung von Anführungszeichen bei Attributen freiwillig ist, Tags in Gross- oder Kleinbuchstaben geschrieben werden können, nicht alle Tags geschlossen werden müssen, gibt es bei XHTML 5 konkrete Regeln dafür.
Was nun?
Welche Markup-Sprache soll den nun verwendet werden? Schönerweise kann jedes valide XHTML 1.1-Dokument mit Auswechslung des Doctypes zu <!DOCTYPE html> zu einem validen HTML5-Dokument umformatiert werden.
Daher… Verwendung von XHTML 1.1 oder HTML 5 ist heutzutage absolut in Ordnung. WIchtig ist, dass man sich bewusst ist, in welcher Version man schreibt. Und immer schön validieren, gell… (ne, gar nicht versuchen, dieses Blog validiert überhaupt nicht).
Komplexes Thema. Korrekturen, Inputs und Ergänzungen gerne in den Kommentaren.
Bill for Bill
