@francisco.jent schrieb:
Was wir aber nicht tun wollen, ist in’s Dokument selber hineinschauen. Das ist geheim.
Ich verstehe die Perspektive, möchte aber im Kontext der Features von DocSafe eines anbringen:
Auf dem Transportweg via Email sind die Daten bereits (unverschlüsselt) durch reichlich Infrastruktur (SMTP Server *intern*) geflossen. Insofern ist strikt positive strukturbasierte content type detection am Ende des Transportswegs - in einem transienten Status - aus meiner Sicht problemlos.
In dem Moment, in dem nachhaltig und identifzifierbar persistiert *ist* kann man auch im Kontext von DocSafe eine nachhaltige Verschlüsselung erwarten, im Falle von DocSafe wohl eine Art PKI.
Mit der obigen Argumentation ist es im übrigen auch unmöglich eine Indexierung zu erreichen - per definition muss man für ein derartiges (aus meiner Sicht im Kontext DocSafe absolut notwendiges) Feature in das Dokument hineinschauen um den Index für ein einzelnes Dokument zu bauen. Die Kunst, eine indexbasierende, DocSafe-weite Suche zu implementieren besteht dann nur noch darin, die Index-Fragmente (on demand, nach Anmeldung durch einen berechtigten Anwender) effizient zusammenzufügen. Für ein paar 10 Dokumente geht das, für ein paar 100 Dokumente über Nutzergrenzen hinweg… eehh. 🙂 Und das concurrent über ein paar mehr Sitzungen… eeehhh 🙂
Würde DocSafe eine client-seitige Verschlüsselung erzwingen (und für den Email-Kanal ist das einfach nicht möglich), könnte man anders argumentieren. Das wäre dann der Wuala-Fall in Reinform.