Das sehe ich anders: Es gibt kaum Anwendungen, die heute den Einsatz dieser unsicheren Technologie rechtfertigen (siehe BrowserSicherheit und ServLets). Da es erfahrungsgemäss einige Jahre dauert, bis sich Neuerungen in der Technologie genügend in der Bevölkerung verbreitet haben, kann ich dem sicherheitsbewussten Internet-Benutzer heute nur raten Schaltet Java in Eurem WebBrowser ab und lasst es so. Entsprechend gilt für WebDesigner die Regel Finger weg von der Applet-Technologie. Für viele Funktionen ist sie nicht erforderlich. Besonders bedenklich ist, dass einige Banken ihr Home-Banking Angebot auf der Basis von JavaApplets realisiert haben. Das ist sozusagen eine Einladung an die bösen Hacker dieser Welt, sich zu bereichern. -- PeterFunk

Weshalb ist es denn bedenklich dass die Banken das Home-Banking auf Java-Basis realisiert haben? Wo liegt denn der sicherheitstechnische Unterschied ob ich mein Home-Banking Programm direkt über das Internet beziehe oder als Java-Applet beziehe? --ThomasHolenstein

Das ist natürlich beides gleich unsicher und anfällig für sogenannte ManInTheMiddle? Angriffe. Es ist überhaupt nicht einzusehen, wieso für Home-Banking überhaupt spezielle Software auf dem Client erforderlich ist. Alles, was in Funkionalität nötig ist, lässt sich auch mit konventionellen Mitteln komfortabel realisieren, so dass im Prinzip auf Benutzerseite nur HTTPS (verschlüsseltes HTTP) erforderlich ist. -- PeterFunk

Genau. HTTPs ist sowieso nötig. Falls wir noch java hinzufügen wird es weder unsicherer noch sicherer. Besser wäre allerdings ein Programm dem Kunden per Post zukommen zu lassen, denn dann wird eine ManInTheMiddle? (oder MannInDerMitte??) schwieriger, sofern das Programm vernünftig geschrieben ist.

Die JavaApplets welche jetzt von der Bank vertrieben werden sollen häufig 128 bit SSL nachbauen, da einige Kunden nur einen verstümmelten 40 bit Browser haben, insofern wird also Telebanking durch Java sicherer.

Nur können die Transaktionen damit nicht signiert werden. Der Benutzer authentifiziert sich zwar mit einem Paßwort, aber wenn eine Transaktion in der Datenbank der Bank steht, kann man nicht mehr beweisen, dass ein Kunde die wirklich so authorisieren wollte. Man geht einfach davon aus -- wie soll die auch anders in die Datenbank gekommen sein? Damit ist dem Mißbrauch durch Mitarbeiter der Bank (oder auch BadGuys?, die in das Computersystem der Bank eingedrungen sind (nicht ganz unwahrscheinlich, wo jetzt sogar Geldautomaten unter Windows laufen und ans Internet angeschlossen sind)) die Tür geöffnet.

Der richtige Ausweg ist das Signieren jeder Transaktion, und dafür braucht man Software auf dem Client, ganz gleichgültig, ob man sie installiert oder als Applet lädt. Kann der Kunde außerdem seinem eigenen Rechner nicht trauen (weil der sich laufend ansteckende Krankheiten einfängt), braucht er außerdem eine Chipkarte mit Kryptoprozessor und Software zum Zugriff darauf.

Eine ganze Reihe von WebBrowsern (z.B. Lynx, KDE Konqueror) unterstützen Java nicht.

Infame Lüge! Konqi beherrscht Java, seit er unter diesem Namen existiert! Andererseits, kein normaler Mensch schaltet das ein. Wozu auch?

Heute surft man doch normalerweise mit Firefox, MS Internetexplorer oder Opera weshalb werden hier Lynx und KDE Konqueror erwähnt, die doch eher ein Nieschendasein fristen? Entsprechen diese Browser den Vorgaben des W3C? Konsortiums? Das heißt werden von diesen Browsern die heutigen HTML-Standards voll unterstützt?