Dienstag, 5. November 2013
[*]

von A bis Z

, 17:58

Das hier geht gerade durch die Blogs (Herr BuddenbohmFrau KaltmamsellAnke Gröner (sogar mit Archiv der früheren Durchgänge), Jens ScholzJohannes) : tipp die Buchstaben von A-Z nacheinander in die Adresszeile Deines Browsers und schreib dann auf, was er vorschlägt.

A — amazon.de

B — barcamp-stuttgart.de

C — centerparcs.de (da waren wir gerade in den Herbstferien)

D — drive.google.com (benutze ich eigentlich nur für die Teilnehmerlisten der Iron-Blogger-Gruppen, das aber etwa wöchentlich)

E — e13.de

F — fitbit.com

G — steinhobelgruen.de/gnudip/cgi-bin/gnudip.cgi (Experimente für einen bald erscheinenden Artikel)

H — hubert-mayer.de

I — ironbuchblogger.de

J — jawbone.com/up (wohl noch eine Nachwirkung dieses Artikels)

K — koeln.ironblogger.de

L — lilstar.de (ich kann mich nicht erinnern, mehr als einmal auf dieser Seite gewesen zu sein, AFAIK eine Ironbuchbloggerin)

M — muenchen.ironblogger.de

N — neuzustellung.de

O — owncloud.wazong.de (selbst ist die Cloud!)

P — practicalparanoid.de

Q — qswe.fotoroulette.de/favicon.ico (hmmm?)

R — runkeeper.com (ohmann, das sieht ja hier aus wie bei einem Fitnessverrückten)

S — spon.de

T — tumblr.com

U — (da habe ich nichts, Chrome schlägt eine Googlesuche nach „u“ vor)

V — versicherung-mathematik.de

W — wazong.de/mailman/admin/buchblogger (Iron-Blogger-Administrativa)

X — x2.fotoroulette.de/favicon.ico (äähm?)

Y — yummiverse.de/author/admin/feed/

Z — zwischendenseiten.wordpress.com

Hmm, wie zu erwarten recht viele Iron Blogger.

Früher, bevor die Browser einen Pornomodus Inkognito-Modus hatten, war das aber spannender.

Samstag, 4. Mai 2013
[*]

Entfernt endlich Java aus dem Browser!

, 00:08

Java ist eine mächtige Sprache mit vielen Vorteilen:

Eine ausgereifte Virtuelle Maschine mit robuster Unterstützung von Nebenläufigkeit, die in der Geschwindigkeit ohne den Einsatz maschinenspezifischen Codes schwer zu schlagen ist, und deren Verbreitung auf unzähligen Systemen das einst gegebene Versprechen „Write once, run anywhere.“ so gut wie möglich einlöst. Dazu gibt es einen bunten Strauß an APIs für alle möglichen Einsatzgebiete.

Alles könnte so schön sein. Seit einiger Zeit aber hört man alle paar Wochen bis Monate (gefühlt ist es alle drei Tage) Meldungen über Sicherheitslücken und Exploits. Die Lücken befinden sich praktisch immer in der Absicherung des Browserplugins, der sogenannten Sandbox, dabei wird das Plugin gar nicht mehr gebraucht.

Vor 10 Jahren ergab es durchaus Sinn, Java-Applets in Webseiten zu integrieren: während JavaScript (nicht zu verwechseln, merke: „Java verhält sich zu JavaScript wie Wal zu Walnuss.“) noch in einem echten Interpreter ausgeführt wurde und entsprechend langsam war, hatte Java bereits einen JIT-Compiler. Auf der damaligen Hardware war das ein echter Vorteil, zumal die verlängerten Startzeiten im Vergleich zur Downloaddauer über die damaligen Internetverbindungen kaum ins Gewicht fielen. Heute wird auch JavaScript vor der Ausführung kompiliert, und so bleiben nur die Nachteile:

Das Sandboxkonzept ist bei der gegebenen Sprachmächtigkeit nicht in den Griff zu bekommen. Die JVM hat volle Unterstützung für Datei- und Netzwerkoperationen sowie Möglichkeiten zur dynamischen Erzeugung von Klassen, die diese Funktionen benutzen.

Die JavaScript-API in Browsern hat dagegen keinen schreibenden Zugriff auf das Dateisystem und kann im Netzwerk nur http-Verbindungen aufbauen. Nur mit einer Sprache, deren Laufzeitumgebung keine Konzepte der verbotenen Operationen hat, lässt sich eine halbwegs sichere Sandbox implementieren.

Das bedeutet nicht, dass es völlig unmöglich ist, auch aus der JavaScript-Sandbox auszubrechen, aber in Java muss der Angreifer nur die virtuelle Maschine austricksen, während er bei einer JavaScript-Lücke den systemspezifischen Maschinencode selbst einschleusen müsste. Während also JavaScript zum Ausbruch aus seinem Sandkasten ein Schäufelchen zur Verfügung hat, handelt es sich bei Java eher um einen Radlader. „Write once, run anywhere“ gilt bei Java eben auch für Exploitcode.

Die Konsequenz muss sein, Java komplett aus dem Browser zu entfernen — und das sage ich als Java-Entwickler. Beliebte und benötigte Java-Anwendungen wie Wordle oder ELSTER können genau so gut lokal als Programme installiert werden. Die JVM an sich ist nämlich nicht unsicherer oder sicherer als andere Laufzeitumgebungen, und es schmerzt, dass nach Jahren des „Java? Das ist doch viel zu langsam.“ sich jetzt „Java? Das ist doch viel zu unsicher.“ im allgemeinen Bewusstsein festsetzt.

Die Überlegungen gelten genau so übrigens auch für Flash.

Dienstag, 27. Januar 2009
[*]

Conditional CSS – Browser Detection with XSLT
By adding an XSLT stylesheet to your XHTML you may select link and style elements to be included or excluded per browser – even with Javascript disabled.
aus Delicious/steinhobelgruen

Tags , , , ,   Kommentare  0
Dienstag, 9. Dezember 2008
[*]

24 ways: The IE6 Equation
There’s a sensation that I’m sure you’re familiar with. It’s a horrible mixture of dread and nervousness. It’s the feeling you get when—after working on a design for a while in a standards-compliant browser like Firefox, Safari or Opera—you decide that you can no longer put off the inevitable moment when you must check the site in IE6. Fingers are crossed, prayers are muttered, but alas, to no avail. The nemesis browser invariably screws something up.
aus Delicious/steinhobelgruen

Tags , , , ,   Kommentare  0