find ich ziemlich blöde ....

[microsoftanhänger]

warum?
ganz einfach, eine halbherzige implementierung von sicherheitsfunktionen ist genau so schlimm - wenn nicht sogar schlimmer - als gar keine verschlüsselung. wenn nun die ganzen script kiddies anfangen, ihre scripte mit verschlüsselung laufen zu lassen, dann gibt das nur eine trügerische sicherheit. irgendwelche fehler werden dann mit einprogrammiert, einzelne module werden verwendet und systematische fehler werden gemacht - und somit hat der anwender überhaupt keine möglichkeit mehr zu sehen ob etwas sicher ist oder nicht.

wenn die verschlüsselung rein zwischen webbrowser und webserver läuft, dann können zumindest unbedarfte anwender an dem schloss in der adressleiste einigermaßen sicher gehen dass die kommunikation verschlüsselt abläuft.

wer in offenen WLANs in russland surft, der wird merken dass das das eingeben eines passwortes in eine unverschlüsselte webseite schon mal zu nem anderen sicherheitsgefühl führt ...

[tingelchen]

Ich finde es gar nicht blöde ;)

Anwendungsbeispiele wurden ja bereits genannt. Diese API soll SSL Verbindungen nicht ersetzen, sondern ergänzen. Was bringt es einem, wenn die Kommunikation zwischen 2 Punkten zwar Verschlüsselt ist, die Daten selber aber unverschlüsselt auf dem Server landen? Genau... rein gar nichts.
Um dieses Problem zu umgehen gibt es derzeit nicht viele Möglichkeiten. Eine besteht darin die Anwendung als Native Anwendung zu entwickeln. Aber das ist nicht immer wünschenswert.

Darüber hinaus gibt es schon jetzt JavaScript API's mit denen man derartige Aufgaben abwickeln kann. Da wäre eine Standardisierte API schon wünschenswert. Für ein eigenes Projekt würde ich es schon nutzen. Vor allem, damit man die Daten z.B. per Private Public Key verfahren auf dem Server verschlüsselt ablegt (z.B. Zugangsdaten für eMail Account) und diese erst beim Browser entschlüsselt werden.

Und was die Modularisierung angeht. Das wird eh schon gemacht. Die meisten nutzen für Kryptografie fertige Bibliotheken. Zum Glück. Denn die meisten Entwickler würden eine eigene Implementierung zu 100% versauen. Viele scheitern ja schon bei der Anwendung. Und da spreche ich nicht nur von Hobby Entwicklern ;)

[qwertü]

jo, mir erschließt sich der sinn auch nicht ganz. wenn man https mit Zertifikat nutzt, hat man ja alles sicher und authentifiziert. wenn man hingegen eine http-seite aufruft, bei der die crypto im JS steckt muss man erst den source komplett lesen, um sicherzugehen, dass die Anwendung überhaut Crypto hat und dann auch noch die richtige, und kein plagiat des russischen WLAN-Betreibers ist.

[__destruct()]

Du wirfst gerade alles durcheinander.

[1e3ste4]

Lest euch doch mal den Text bis zu Ende durch anstatt drauf los zu kommentieren.

Es geht hier nicht als Alternative zu HTTPS. Es geht hier um direkte Verschlüsselung und Signierung von Daten über JavaScript. Schlampige Implementationen können sich die Browserentwickler viel weniger leisten als irgendwelche proprietären Lösungen, deren Fehler aufgrund weniger Nutzer nicht so sehr auffallen.

Mit der API könnte ich z.B. diesen Text mit meinem privaten Schlüssel direkt am PC signieren, so wie es zur Zeit nur in Mailclients geht, wobei der Schlüssel eine Datei oder eine Smartcard sein kann.

Ich kann auch Daten direkt vom Browser verschlüsseln lassen und sie so in einen Datenspeicher hochladen, ohne das der Anbieter sie lesen könnte.

HTTPS hilft nicht gegen das Lesen von Daten seitens des Serverbetreibers.