News Inbox will E-Mail neu erfinden

[Gustavo Fring]

Ja, das ist ein Argument. man bräuchte eine KI die sich einen Schlüssel überlegt und die das keinem sagt.

 

[alxtraxxx]

Ja das wäre ca. so sicher wie sich nie den PIN seiner Girokarte zu merken und dann am Automat zu stehen

 

[DaZpoon]

Der Knackpunkt steht doch im letzten Satz: OAuth. Damit wird man praktisch auch von allen OAuth Anbietern getrackt. Nö danke...
Generell fehlt mir ebenfalls hier irgendwo ein Verweis auf die echte Innovation. Die üblichen Probleme wie End-To-End Verschlüsselung samt Meta-Daten sind nicht geklärt.

 

[bu.llet]

Das Thema Verschlüsselung im Mailverkehr ist nach wie vor eine Katastrophe weil es nahezu unmöglich ist DAU-Kompatibilität - also für die "Generation Facebook" die sich überall mitteilen möchte aber keine Ahnung von der Technik hat - und eine vernünftige Usability in Einklang zu bringen.

Im echten Leben einen Schlüssel zu tauschen um mal ab und an eine E-Mail auszutauschen werden die wenigsten machen. Einen Public Key standardmäßig anzubieten und eine Enschlüsselung auf dem Endgerät durchzuführen scheitert auch wieder dann, wenn man den Mail-Server nicht selbst und auf eigener Hardware betreibt. Zudem müsste der Client in jedem Fall Open Source sein.

 

[Forum-Fraggle]

Verschlüsselung mit PGP ist absolut simple, es müßten nur mehr DAU Lösungen geben wie z.B. http://www.gnupt.de/site/index.php?option=com_content&view=article&id=70&Itemid=514&lang=de

PGP funktioniert ja nur mit Schlüssel austauschen, was in der Praxis ja relativ unmöglich ist. Die meisten Leute würden mich wahrscheinlich auslachen
Ich hab hier Letzte Woche mal was von Asymetrischer Verschlüsselung gelesen. Geht das ohne Schlüsseltausch?

Wo ist das Problem? Dafür gibts Schlüsselserver. Sprich, wenn Du eine eMail-Adresse bekommst, wird geprüft, ob ein Schlüssel vorliegt und falls ja, dieser geladen.

Was geändert werden muß ist das System mit den Metadaten. Nämlich daß diese nicht mehr anfallen. Dazu gab es einen Ansatz. Es war Richtung verschlüsselter Mails in der Cloud (in einem Newsroom o.ä.) und alle im Raum bekamen die Mail, aber nur der Empfänger konnte sie entschlüsseln. Soetwas auszubauen wäre sinnvoll, aber dann bitte nicht von einer US Firma oder erst nach intensiven Audits.

 

[Kcl]

Hm, REST ist ja gut und schön, aber wieso mit HTTP Anfragen noch eine Ebene Overhead drauflegen? Das Gerümpel von SMTP/IMAP gehört schon mal entlüftet, aber wieso nicht das Protokoll selbst verbessern?

Im Moment scheint es ja so, als hätten die "Mail-Revolutionierer" lediglich eine (zugegebenermaßen schöne) API definiert, deren Funktion immer noch von den Providern implementiert werden müsste.
Oder eben (in der momentanen Form, wenn kein Provider die API implementiert hat) ein Wrapper um IMAP/SMTP, um Entwicklern das Erstellen von Email-Clients zu vereinfachen, aber das wurde ja auch schon vorher gemacht (bspw. context.io - was soweit ich weiß kein Mensch benutzt ). Damit sind aber ja die Kernprobleme von den Mail-Protokollen noch lange nicht gelöst.

So wie ich das sehe, kann man dann zumindest auf längere Zeit gesehen IMAP/SMTP im Hintergrund transparent ersetzen, ohne dass sich etwas an den Clients ändern muss.

Außerdem wie sieht's aus mit der Finanzierung? Wird das Unternehmen einen RFC abschicken, um das ganze als Standard definieren zu können?

 

[Blutschlumpf]

Juhu, wenn deren Lösung dann in nem Jahr offiziell gefloppt ist, gebt mir kurz ne Info, dann poste ich hier warum das jeder Vollpfosten hätte vorhersagen können.

IPv6 hat ca. 20 Jahre gebraucht um an den Punkt zu kommen, dass ein Durchbruch über die nächsten 5 Jahre sehr wahrscheinlich ist. Und das weil die v4 Adressen knapp werden.
Ob da wirklich jemand glaubt email damit ersetzen zu können?

 

[bu.llet]

Verschlüsselung mit PGP ist absolut simple, es müßten nur mehr DAU Lösungen.

Wo ist das Problem? Dafür gibts Schlüsselserver. Sprich, wenn Du eine eMail-Adresse bekommst, wird geprüft, ob ein Schlüssel vorliegt und falls ja, dieser geladen.

Und wer betreibt den Server? Sobald das ein dritter macht ist das doch wieder für die Katz.

 

[Piktogramm]

Der Schlüsselserver verteilt nur die sowieso öffentlichen Schlüssel.

Du schreibst also beispielsweise eine Email an mich, dein Email Client schaut nach ob der Schlüsselserver meine Emailadresse kennt, wenn ja bekommst du entsprechend meinen öffentlichen Schlüssel. Mit diesem Schlüssel wird die Email entschlüsselt und lässt sich nur mit meinem privatem Schlüssel entschlüsseln. Den privaten Schlüssel kennt der Schlüsselserver nicht.
Jede Veränderung des öffentlichen Schlüssels würde dazu führen, dass mein privater Schlüssel nicht passt und entsprechend ich die Email nicht lesen könnte. Daher Angriffe auf öffentliche Schlüssel sind sinnlos.

So ein Schlüsselserver hat wenn nur folgende Nachteile:
*Man hat ein Verzeichnis all Jender, die Krypte betreiben
*Man kann die Anfragen auf den Schlüsselserver loggen und bekommt so eine zweite Quelle für Metadaten