@meego: Auch wenn Du ein Schreiben schickst weisst Du was Du dem Benutzer geschickt hast, und wenn der das was Du geschickt hast braucht um mit dem Server zu kommunizieren kannst Du am Server dann auch wieder sehen wer der Benutzer ist. Das ist jedenfalls das was der Benutzer denkt was Du machen kannst, wenn Du ihm gegenüber also sagst Du könntest das nicht, müsstest Du das irgendwie beweisen können.
Du musst ja von irgendeinem Angreifer ausgehen können gegen Du Dich schützen willst. Du kannst also sagen $GOTT kann alles, also kann man sich gegen den nicht schützen. Das kannst Du akzeptieren, und Dir weiter Gedanken machen, oder Du kannst sagen gegen den soll es auch sicher sein. Dann kannst Du aufhören und das Projekt begraben. Ersetzen wir $GOTT durch die NSA oder vielleicht etwas allgemeiner gegen die Geheimdienste die da alle zusammenarbeiten. Da wäre mir so etwas wie Tor zum Beispiel schon nicht mehr sicher genug, denn das geht davon aus das niemand den Traffic von allen an einer Route beteiligten Nodes gleichzeitig abhört. Wenn es gegen NSA und Co wirklich sicher sein soll, dann wäre ich mal pessimistisch und würde einem anderen Projekt oder Hobby zuwenden. Und so weiter. Du musst eben genau abgrenzen gegen wen mit welchem Mitteln das noch sicher sein muss, und ab wo Du sagst, das ist ein Risiko das akzeptiere ich.
Anscheinend bist Du selbst ja auch ein sehr potenter Angreifer gegen den Du Dich schützen willst. Da Du die Kunden kennen musst um abzurechnen, und Zugriff auf die gespeicherten Daten und die Verkehrsdaten hast von den Zugriffen der Kunden auf ihre Daten, ist das alleine schon mal eine interessante Nuss.
Verschlüsselung / Datenbankzugriff
@meego:
Wenn ich Dich richtig verstehe, gehts Dir hauptsächlich um die Verschleierung des Ursprungs der Daten. Im Prinzip kollidiert das mit der Art und Weise, wie unsere heutige Netzwerkinfrastruktur aufgebaut ist, welche auf schnelle, kurze Routen zwischen Absender und Empfänger optimiert ist.
Du bräuchtest eine Art Subnetz-Struktur/Protokoll, welche die Daten in einem Peer-to-Peer-Netzwerk zirkulieren lässt und ein Datum nur noch über ein Hashtag identifizierbar ist. Wenn jeder Knoten zufällig exit- oder entry-Knoten sein kann, ist nicht mehr ersichtlich, welcher Knoten die Daten generiert hat. Nach diesem Prinzip arbeitet z.B. das vielgescholtene Freenetprojekt, Tor als eine Art Proxy-Kaskade arbeitet ähnlich. Nur wer garantiert Dir, dass das Netz/die Knoten nicht selbst unterwandert sind? Der Ansatz steht und fällt quasi mit der Anzahl vertrauenswürdiger Knoten, die ich als Nutzer vom entry bis exit im Mittel durchlaufen kann.
Wenn die Daten nur noch per Hashtag identifizierbar sind, kennst auch Du als "Betreiber" die Person nicht mehr - vorausgesetzt, der Inhalt der Daten lässt keine weiteren Rückschlüsse zu.
Wenn ich Dich richtig verstehe, gehts Dir hauptsächlich um die Verschleierung des Ursprungs der Daten. Im Prinzip kollidiert das mit der Art und Weise, wie unsere heutige Netzwerkinfrastruktur aufgebaut ist, welche auf schnelle, kurze Routen zwischen Absender und Empfänger optimiert ist.
Du bräuchtest eine Art Subnetz-Struktur/Protokoll, welche die Daten in einem Peer-to-Peer-Netzwerk zirkulieren lässt und ein Datum nur noch über ein Hashtag identifizierbar ist. Wenn jeder Knoten zufällig exit- oder entry-Knoten sein kann, ist nicht mehr ersichtlich, welcher Knoten die Daten generiert hat. Nach diesem Prinzip arbeitet z.B. das vielgescholtene Freenetprojekt, Tor als eine Art Proxy-Kaskade arbeitet ähnlich. Nur wer garantiert Dir, dass das Netz/die Knoten nicht selbst unterwandert sind? Der Ansatz steht und fällt quasi mit der Anzahl vertrauenswürdiger Knoten, die ich als Nutzer vom entry bis exit im Mittel durchlaufen kann.
Wenn die Daten nur noch per Hashtag identifizierbar sind, kennst auch Du als "Betreiber" die Person nicht mehr - vorausgesetzt, der Inhalt der Daten lässt keine weiteren Rückschlüsse zu.
@BlackJack: Stimmt, wenn ich ihm Benutzername und Passwort schicke, wäre das wohl so. Aber was wenn ich ihm nur eine Anleitung der Benutzernamen und Passwortvorgaben schicke?
Gegen den NSA wird man sich nicht schützen können. Ich denke, der existenzbedrohende Albtraum für dieses Gedankenexperiment wäre wohl, wenn jemand die Nutzer ihren Daten zuordnen könnte und dann den Betreiber damit erpresst oder sie an einen Dritten verkauft. Eigentlich wäre schon die reine Tatsache, dass das einer geschafft hat existenzbedrohend. Stell' dir mal vor (um ein extremes Beispiel zu nehmen) jemand würde beim DNA-Service 23andme DNA-Daten den Kunden zuordnen und beispielsweise an eine Krankenkasse verkaufen. Die Firma wäre morgen weg vom Fenster. Hmm.. vielleicht wäre es interessant zu gucken, wie die das machen und sich offenbar nicht viele daran stören.
Ich persönlich nicht, aber wenn man das Gedankenexperiment weiter denkt, könnte der Angreifer ja auch ein interner Mitarbeiter sein. Kommt in den besten Schweizer Banken vor.
Gegen den NSA wird man sich nicht schützen können. Ich denke, der existenzbedrohende Albtraum für dieses Gedankenexperiment wäre wohl, wenn jemand die Nutzer ihren Daten zuordnen könnte und dann den Betreiber damit erpresst oder sie an einen Dritten verkauft. Eigentlich wäre schon die reine Tatsache, dass das einer geschafft hat existenzbedrohend. Stell' dir mal vor (um ein extremes Beispiel zu nehmen) jemand würde beim DNA-Service 23andme DNA-Daten den Kunden zuordnen und beispielsweise an eine Krankenkasse verkaufen. Die Firma wäre morgen weg vom Fenster. Hmm.. vielleicht wäre es interessant zu gucken, wie die das machen und sich offenbar nicht viele daran stören.
Ich persönlich nicht, aber wenn man das Gedankenexperiment weiter denkt, könnte der Angreifer ja auch ein interner Mitarbeiter sein. Kommt in den besten Schweizer Banken vor.
@Jerch
Was ist mit einem vermaschten Netz, wie es in Sachen Hongkongproteste (https://de.wikipedia.org/wiki/Firechat) zu vernehmen war? Gibt es das nur Wireless?
Oder eine zweite öffentlich überprüfbare Instanz der Firma aufbauen, die nur für diese Randomierung aus Datenschutzgründen verantwortlich ist und die Pakete dann an die eigentliche Firma weitersendet? Damit könnte ein potenter Angreifer auch davon abgehalten werden Knoten zu besetzen.
Was versteht man unter einem Hashtag? (Ich kenne den Begriff nur im Sinne von Twitter/Facebook.)
Was ist mit einem vermaschten Netz, wie es in Sachen Hongkongproteste (https://de.wikipedia.org/wiki/Firechat) zu vernehmen war? Gibt es das nur Wireless?
Oder eine zweite öffentlich überprüfbare Instanz der Firma aufbauen, die nur für diese Randomierung aus Datenschutzgründen verantwortlich ist und die Pakete dann an die eigentliche Firma weitersendet? Damit könnte ein potenter Angreifer auch davon abgehalten werden Knoten zu besetzen.
Was versteht man unter einem Hashtag? (Ich kenne den Begriff nur im Sinne von Twitter/Facebook.)
@meego:
Ein Tag ist ein Etikett, ein Hashtag halt ein Etikett mit einem Hash-Wert. Die Bezeichnung Hashtag für die Twitterkürzel finde ich eher verwirrend
Für Deine Ansprüche an ein solches Netz ist es wichtig, dass die Route durch das Netz ( entry - xy-random-Knoten - exit) nicht vorbestimmt ist bzw. nicht rückwirkend nachvollzogen werden kann. Prinzipiell können vermaschte Netze das leisten, wenn das Routingprotokoll von dem Normalanspruch "bringe auf möglichst kurzem schnellen Wege die Info zum Ziel" abweicht und die Daten keine Info über den Ersteller mittragen. Letzteres ist schwierig, da solche Netze auch den Rückkanal möglichst einfach vorhalten sollen. Mit verschlüsselten Nachrichten, welche nur noch über den Hash vom Ersteller identifiziert werden können, wird dann das Routing sehr aufwendig, da im Zweifelsfalle alle Knoten durchlaufen werden müssen, um dem Absender eine Antwort zu präsentieren. Zusätzlich müssten die Knoten in Unkenntnis darübergelassen werden, ob es in der Nachbarschaft einen Treffer gab. Der Traffic durch einen Knoten würde damit exponentiell steigen.
Die Bündelung in eine "öffentliche" Instanz widerspricht Deinem Anspruch, da jedwede zentrale Struktur eine Steilvorlage für Angriffe darstellt.
Ein Tag ist ein Etikett, ein Hashtag halt ein Etikett mit einem Hash-Wert. Die Bezeichnung Hashtag für die Twitterkürzel finde ich eher verwirrend
Für Deine Ansprüche an ein solches Netz ist es wichtig, dass die Route durch das Netz ( entry - xy-random-Knoten - exit) nicht vorbestimmt ist bzw. nicht rückwirkend nachvollzogen werden kann. Prinzipiell können vermaschte Netze das leisten, wenn das Routingprotokoll von dem Normalanspruch "bringe auf möglichst kurzem schnellen Wege die Info zum Ziel" abweicht und die Daten keine Info über den Ersteller mittragen. Letzteres ist schwierig, da solche Netze auch den Rückkanal möglichst einfach vorhalten sollen. Mit verschlüsselten Nachrichten, welche nur noch über den Hash vom Ersteller identifiziert werden können, wird dann das Routing sehr aufwendig, da im Zweifelsfalle alle Knoten durchlaufen werden müssen, um dem Absender eine Antwort zu präsentieren. Zusätzlich müssten die Knoten in Unkenntnis darübergelassen werden, ob es in der Nachbarschaft einen Treffer gab. Der Traffic durch einen Knoten würde damit exponentiell steigen.
Die Bündelung in eine "öffentliche" Instanz widerspricht Deinem Anspruch, da jedwede zentrale Struktur eine Steilvorlage für Angriffe darstellt.
Um deine Verwirrung zu verringern: Das Symbol "#" hieß schon "Hash" vor Hashwerten.. Ein Hashtag ist also kein Etikett mit einem Hashwert, sondern das Hash-Symbol mit einem Tag dran.jerch hat geschrieben:Ein Tag ist ein Etikett, ein Hashtag halt ein Etikett mit einem Hash-Wert. Die Bezeichnung Hashtag für die Twitterkürzel finde ich eher verwirrend
Das Leben ist wie ein Tennisball.
Ob das so stimmt, sei mal dahingestellt -- http://blog.dictionary.com/octothorpe/EyDu hat geschrieben:Das Symbol "#" hieß schon "Hash" vor Hashwerten..
Und was ist ein Hash-Wert einfach erklärt?jerch hat geschrieben:@meego:
Ein Tag ist ein Etikett, ein Hashtag halt ein Etikett mit einem Hash-Wert.
Den zweiten Paragrafen verstehe ich noch nicht. Was meinst du mit vorhalten? Wie ist das ganze eigentlich mit meinem vorgesehenen Abo vereinbar?Für Deine Ansprüche an ein solches Netz ist es wichtig, dass die Route durch das Netz ( entry - xy-random-Knoten - exit) nicht vorbestimmt ist bzw. nicht rückwirkend nachvollzogen werden kann. Prinzipiell können vermaschte Netze das leisten, wenn das Routingprotokoll von dem Normalanspruch "bringe auf möglichst kurzem schnellen Wege die Info zum Ziel" abweicht und die Daten keine Info über den Ersteller mittragen.
Letzteres ist schwierig, da solche Netze auch den Rückkanal möglichst einfach vorhalten sollen. Mit verschlüsselten Nachrichten, welche nur noch über den Hash vom Ersteller identifiziert werden können, wird dann das Routing sehr aufwendig, da im Zweifelsfalle alle Knoten durchlaufen werden müssen, um dem Absender eine Antwort zu präsentieren. Zusätzlich müssten die Knoten in Unkenntnis darübergelassen werden, ob es in der Nachbarschaft einen Treffer gab. Der Traffic durch einen Knoten würde damit exponentiell steigen.
Ich meinte aber zusätzlich, als letzte Instanz, wenn die Nutzerdaten schon lange weg sind.Die Bündelung in eine "öffentliche" Instanz widerspricht Deinem Anspruch, da jedwede zentrale Struktur eine Steilvorlage für Angriffe darstellt.
BlackJack hat geschrieben:
Ein Hashwert ist das Ergebnis einer Hashfunktion. Hashwerte könnten hier z.B. als ID/Auth-Token herhalten.meego hat geschrieben:Und was ist ein Hash-Wert einfach erklärt?
Mit vorhalten meinte ich ermöglichen. Vermaschte Netze sind zunächst nichts besonderes, große Teile des Internets selbst würden der Definition standhalten. Knackpunkt sind die Routingprotokolle - die müssten angepasst werden, um Transparenz und kurze/schnelle Routen loszuwerden und die Verschleierung zu erreichen.meego hat geschrieben:Den zweiten Paragrafen verstehe ich noch nicht. Was meinst du mit vorhalten? Wie ist das ganze eigentlich mit meinem vorgesehenen Abo vereinbar?
Wie die Aboidee da reinspielt, musst Du Dir überlegen. Technisch könnten z.B. die ID-Tokens gegen eine Aboprüfinstanz signiert werden. Oder man lässt die Nutzer nur über Prüfgateways ins Subnetz und einen Knoten erstellen.
Verstehe nicht, was Du damit meinst.meego hat geschrieben: Ich meinte aber zusätzlich, als letzte Instanz, wenn die Nutzerdaten schon lange weg sind.
Ganz ehrlich - ich würde mir ohne gründliche Einarbeitung in Netzwerktechnologien/-topologie und bestehende Technologien wie Tor, Bittorrent, Freenet nicht zutrauen, sowas verlässlich umsetzen zu können. Wenn Dir die Sache so wichtig ist und es einen Businesscase gibt, dann solltest Du Spezialisten zu Rate ziehen, die das Problemfeld abstecken können und nicht mit halbgarem Wissen es selbst lösen wollen.
Die in solchen Fragen leider in Sachen Allgemeinverständlichkeit oft weit hinter dem Mond bleiben. Es stellt sich auch die Frage welches Lemma. Hash in der Kryptografie? (Dann muss ich gar nicht erst mit dem Lesen anfangen, weil ich eh nichts verstehe.)EyDu hat geschrieben:Es gibt dazu einen sehr ausführlichen Wikipedia-Artikelmeego hat geschrieben:Und was ist ein Hash-Wert einfach erklärt?
- noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Ich stimme zwar mir dir überein, dass manche Sache bei der deutschen Wikipedia ziemlich theoretisch sind (Tipp: die englische Version der Artikel ist manchmal verständlicher, brauchbares Englisch vorausgesetzt), aber *versuchen* es zu lesen kann man es doch trotzdem.
Mein Eindruck ist inzwischen, dass du für ein alles andere als einfaches Problem eine triviale Lösung möchtest. Und die gibt es nicht, dass ist hier ja schon erläutert werden.
Und wenn deine Bereitschaft, da in unbekannte Materie einzusteigen - auch wenn schwierig ist! - nicht vorhanden ist, brauchst du da IMHO gar nicht weiter machen. Die Problem lässt sich nun mal nicht Quick'n'Dirty lösen.
Gruß, noisefloor
Sorry, aber total falsch Einstellung! Bei deinem Problem spielt Kryptografie ein Rolle, und die Hashfunktion ist ein möglicher Weg. Mit der Aussagen terminierst du doch auch die Hilfsbereitschaft der Personen, die dir bisher Tipps gegeben und Lösungswege aufgezeigt haben.meego hat geschrieben: Hash in der Kryptografie? (Dann muss ich gar nicht erst mit dem Lesen anfangen, weil ich eh nichts verstehe.)
Ich stimme zwar mir dir überein, dass manche Sache bei der deutschen Wikipedia ziemlich theoretisch sind (Tipp: die englische Version der Artikel ist manchmal verständlicher, brauchbares Englisch vorausgesetzt), aber *versuchen* es zu lesen kann man es doch trotzdem.
Mein Eindruck ist inzwischen, dass du für ein alles andere als einfaches Problem eine triviale Lösung möchtest. Und die gibt es nicht, dass ist hier ja schon erläutert werden.
Und wenn deine Bereitschaft, da in unbekannte Materie einzusteigen - auch wenn schwierig ist! - nicht vorhanden ist, brauchst du da IMHO gar nicht weiter machen. Die Problem lässt sich nun mal nicht Quick'n'Dirty lösen.
Gruß, noisefloor
Und warum ist das keine Info mehr über den Ersteller?jerch hat geschrieben:Ein Hashwert ist das Ergebnis einer Hashfunktion. Hashwerte könnten hier z.B. als ID/Auth-Token herhalten.
Wie bleibt der Datenschutz des Benutzers so erhalten?Technisch könnten z.B. die ID-Tokens gegen eine Aboprüfinstanz signiert werden.
Angenommen diese Pakete zirkulieren erst zwischen den Benutzern und landen dann auf einem Rechner, der sie noch einmal randomisiert, ehe sie in der Datenbank des Webservers landen.Verstehe nicht, was Du damit meinst.meego hat geschrieben: Ich meinte aber zusätzlich, als letzte Instanz, wenn die Nutzerdaten schon lange weg sind.
Das Pferd ist sowieso am Schwanz aufgezäumt. Vielleicht sollte ich dieses Verschlüsselungsexperiment erst einmal gänzlich ausklammern. Lässt sich ja dann nachträglich immer noch hinzufügen. Mir ging es eher darum zu eruieren, ob es überhaupt möglich ist.Wenn Dir die Sache so wichtig ist und es einen Businesscase gibt, dann solltest Du Spezialisten zu Rate ziehen, die das Problemfeld abstecken können und nicht mit halbgarem Wissen es selbst lösen wollen.
Ich habe eben gestern versucht, den PKI-Artikel zu verstehen, aber der war teilweise arg unverständlich.noisefloor hat geschrieben:Ich stimme zwar mir dir überein, dass manche Sache bei der deutschen Wikipedia ziemlich theoretisch sind (Tipp: die englische Version der Artikel ist manchmal verständlicher, brauchbares Englisch vorausgesetzt), aber *versuchen* es zu lesen kann man es doch trotzdem.
Aber ich kann mir einfach schwer vorstellen (wahrscheinlich ist es einfach Déformation Professionnelle), dass es nach Bittorrent und Tor immer noch Neuland ist. Es gab/gibt einige Filesharingdienste und mit GNU Privacy Guard auch ein gewichtiges Open Source Paket.Mein Eindruck ist inzwischen, dass du für ein alles andere als einfaches Problem eine triviale Lösung möchtest. Und die gibt es nicht, dass ist hier ja schon erläutert werden.
@meego: Wie spielt Bittorrent da rein? Dabei geht es nicht um verschlüsseln oder verschleiern sondern darum Dateien so zu verteilen das die Last nicht alleine bei einem festen Server liegt indem die Clients selbst auch alle als Server von den Teilstücken operieren die sie schon bekommen haben.
Tor braucht voneinander unabhängige Knoten, also welche die nicht von einem Betreiber sind und wo man darauf vertrauen kann, das die Betreiber nicht zusammenarbeiten. Oder dass es niemanden gibt der das Netz so umfangreich abschnorcheln kann dass er alle Knoten erfasst. NSA+GCHQ+… wären das dann in dem Fall. Wobei das zwar Dein Problem mit der Zuordnung Benutzer/Daten lösen könnte, aber Du möchtest ja gleichzeitig das mit dem Abo machen, also musst Du dann ja doch irgendwie wieder feststellen können wer Daten ablegt oder darauf zugreift. Und ja vielleicht auch alle Daten eines Benutzers löschen dessen Abo ausläuft‽ Wozu man wissen müsste welche Daten welchem Benutzer gehören…
Tor braucht voneinander unabhängige Knoten, also welche die nicht von einem Betreiber sind und wo man darauf vertrauen kann, das die Betreiber nicht zusammenarbeiten. Oder dass es niemanden gibt der das Netz so umfangreich abschnorcheln kann dass er alle Knoten erfasst. NSA+GCHQ+… wären das dann in dem Fall. Wobei das zwar Dein Problem mit der Zuordnung Benutzer/Daten lösen könnte, aber Du möchtest ja gleichzeitig das mit dem Abo machen, also musst Du dann ja doch irgendwie wieder feststellen können wer Daten ablegt oder darauf zugreift. Und ja vielleicht auch alle Daten eines Benutzers löschen dessen Abo ausläuft‽ Wozu man wissen müsste welche Daten welchem Benutzer gehören…
Hi BlackjackBlackJack hat geschrieben:Wobei das zwar Dein Problem mit der Zuordnung Benutzer/Daten lösen könnte, aber Du möchtest ja gleichzeitig das mit dem Abo machen, also musst Du dann ja doch irgendwie wieder feststellen können wer Daten ablegt oder darauf zugreift. Und ja vielleicht auch alle Daten eines Benutzers löschen dessen Abo ausläuft‽ Wozu man wissen müsste welche Daten welchem Benutzer gehören…
Bittorent hat Jerch oben erwähnt. Betreffend Abo meinte er, ich zitiere: "Technisch könnten z.B. die ID-Tokens gegen eine Aboprüfinstanz signiert werden. Oder man lässt die Nutzer nur über Prüfgateways ins Subnetz und einen Knoten erstellen." Ich habe es auch noch nicht ganz verstanden.
@meego: sobald Du regelmäßig Geld von Deinen Nutzern abgreifen willst, mußt Du sie auch identifizieren können. Du brauchst also wieder eine Zwischeninstanz, der die Leute vertrauen müssen.
Du hast das Beispiel DNA gebracht. Da ist es z.B. ganz einfach. Man schickt anonym einen Brief mit Speichelprobe, viel Geld und einem Schlüssel. Du legst die Daten unter diesem Schlüssel ab und jeder kann die gesamte Datenbank herunterladen, aber nur derjenige, der den Schlüssel hat, weiß, welche Daten ihm gehören.
Du hast das Beispiel DNA gebracht. Da ist es z.B. ganz einfach. Man schickt anonym einen Brief mit Speichelprobe, viel Geld und einem Schlüssel. Du legst die Daten unter diesem Schlüssel ab und jeder kann die gesamte Datenbank herunterladen, aber nur derjenige, der den Schlüssel hat, weiß, welche Daten ihm gehören.
Was ist mit Instanz gemeint? Eine Firma, deren Code jeder überprüfen kann?Sirius3 hat geschrieben:@meego: sobald Du regelmäßig Geld von Deinen Nutzern abgreifen willst, mußt Du sie auch identifizieren können. Du brauchst also wieder eine Zwischeninstanz, der die Leute vertrauen müssen.
Ich bin da zufällig Kunde. Nach der Bezahlung der ca. 120 Euro erhielt ich ein Paket mit dem Plastikdingens an meine persönliche Adresse, habe es mit der Speichelprobe retourniert. Man musste einen Benutzernamen mit Passwort erstellen. Von einem Schlüssel habe ich zumindest nichts erfahren. Wenn die das über ein PKI-Modell machen: Wie verhindert der Service nun Hackerangriffe oder den Datendiebstahl eines übereifrigen Mitarbeiters?Du hast das Beispiel DNA gebracht. Da ist es z.B. ganz einfach. Man schickt anonym einen Brief mit Speichelprobe, viel Geld und einem Schlüssel. Du legst die Daten unter diesem Schlüssel ab und jeder kann die gesamte Datenbank herunterladen, aber nur derjenige, der den Schlüssel hat, weiß, welche Daten ihm gehören.
@meego: Mit Instanz ist jemand gemeint dem die Nutzer *vertrauen* müssen. Wenn man da etwas nachprüfen kann, bräuchte man kein Vertrauen. Wie stellst Du Dir das vor das jeder den Code prüft? Klar kann die Instanz Code öffentlich machen den jeder anschauen und prüfen kann. Damit ist aber nicht sichergestellt das der Code auch tatsächlich der ist, den die Instanz dann auf dem Server laufen hat.
Bezüglich DNA: Wie der Service Hackerangriffe verhindert oder Datendiebstahl durch Mitarbeiter das musst Du den Betreiber fragen. So wie Du das beschreibst, vertraust Du dem gerade ganz einfach das er Dir sagt er passt schon auf und macht nichts böses. Oder anders ausgedrückt: Du solltest davon ausgehen das die NSA den Datensatz bereits hat, und auch weiss, dass das Deine DNA ist.
Bezüglich DNA: Wie der Service Hackerangriffe verhindert oder Datendiebstahl durch Mitarbeiter das musst Du den Betreiber fragen. So wie Du das beschreibst, vertraust Du dem gerade ganz einfach das er Dir sagt er passt schon auf und macht nichts böses. Oder anders ausgedrückt: Du solltest davon ausgehen das die NSA den Datensatz bereits hat, und auch weiss, dass das Deine DNA ist.
@meego:
Datenklau durch übereifrige Mitarbeiter zu vereiteln, geht nur mit Verschlüsselung in Unkenntnis des Schlüssels, womit Du als Betreiber wieder nicht in die Daten schauen kannst. Da Du das aber können willst, musst Du die Betreiberseite (und Mitarbeiter mit entsprechendem Zugang zum Server) als vertrauenwürdig einstufen, ansonsten geht es schlicht und ergreifend nicht. Das ist aber nochmal ein anderes Problem als die Verschleierung des Ursprungs der Daten.
Datenklau durch übereifrige Mitarbeiter zu vereiteln, geht nur mit Verschlüsselung in Unkenntnis des Schlüssels, womit Du als Betreiber wieder nicht in die Daten schauen kannst. Da Du das aber können willst, musst Du die Betreiberseite (und Mitarbeiter mit entsprechendem Zugang zum Server) als vertrauenwürdig einstufen, ansonsten geht es schlicht und ergreifend nicht. Das ist aber nochmal ein anderes Problem als die Verschleierung des Ursprungs der Daten.