sharefest.me / webRTC > anonym ? ;)

Grad hab ich in nem Blog gelesen das es mit Sharefest.me ( verwendet webRTC ) ein sicheres/anonymes Peer to Peer - Teil gibt.

Naja, Internet und Anonym? Habt ihr euch schon mal damit befasst? Soweit ich weiss wird zwar beim Datentransfer die IP nicht benötigt aber ansonsten kann man die IP wohl doch sehen?!

Was haltet ihr davon?
 
Ich will hier jetzt keine Noobdiskussion losbrechen ala wie kann ich vollständig anonym/ungestraft illegales downloaden. Mich intressieren die technischen Sachen, sprich warum ist das neue jetzt sicherer, anonymer, anders ( gegenüber z.B. Tor ).
 
Der Punkt, worauf ich hinaus möchte, ich der, dass es keinen Sinn macht, über Anonymität zu diskutieren, wenn nichtmal bekannt ist, gegenüber wem du deine Identität verbergen willst. Es macht beispielweise einen großen Unterschied, ob du nun gegenüber der NSA, oder deinem computerfremden Nachbarn anonym bleiben willst.

Wie dem auch sei: WebRTC baut normalerweise auch direkte Verbindungen zwischen den Kommunikationspartnern auf, um so eine effizientere Übertragung von Daten zu ermöglichen. D.h. anstatt bei einer Video-Konferenz einen zentralen Server einzusetzen, der die Daten an die Teilnehmer weiterreicht, werden die Verbindungen direkt zwischen den Teilnehmern hergestellt. Hierdurch kann die Last auf einen zentralen, nun lediglich zur Vermittlung benötigten Server deutlich reduziert werden.

Sharefest nutzt WebRTC, um eine Bittorrent-ähnliche Architektur (ohne DHT!) aufzubauen: Ein zentraler Server (Coordinator) verwaltet alle Peers, Chunks und deren Verbindungen untereinander. Die Verbindungen zwischen den Peers werden dann, wie bei Bittorrent auch, direkt hergestellt. Anstatt der .torrent-Dateien gibts eben nun Links, die vermutlich genau diese Informationen zum Download für die Teilnehmer bereitstellen.

Wie du oder der Blogautor hier Anonymität auch nur in Betracht ziehen können, ist mir aktuell noch ein Rätsel, denn es bestehen weder zwischen den Teilnehmern selbst - es werden direkte Verbindungen zwischen den Teilnehmern hergestellt -, noch zum zentralen Coordinator - der Coordinator kennt alle Peers und zumindest die "Adressen" der Chunks -, noch zu einem alles sehenden Dritten - die Verbindungsdaten verraten dir einiges über Verhalten, Verbindungspartner, ... - irgendwelche Verschleierungsmechanismen. Es wird zwar TLS eingesetzt, aber ein self signed Certificate inkl. private Key wird über github schon mitgeliefert, was meiner Ansicht nach dazu führen wird, dass viele den Key am Anfang nicht ersetzten und es später schlicht vergessen werden.
 
Zuletzt bearbeitet:
Wie du oder der Blogautor hier Anonymität auch nur in Betracht ziehen können, ist mir aktuell noch ein Rätsel, denn es bestehen weder zwischen den Teilnehmern selbst - es werden direkte Verbindungen zwischen den Teilnehmern hergestellt -, noch zum zentralen Coordinator - der Coordinator kennt alle Peers und zumindest die "Adressen" der Chunks -, noch zu einem alles sehenden Dritten - die Verbindungsdaten verraten dir einiges über Verhalten, Verbindungspartner, ... - irgendwelche Verschleierungsmechanismen. Es wird zwar TLS eingesetzt, aber ein self signed Certificate inkl. private Key wird über github schon mitgeliefert, was meiner Ansicht nach dazu führen wird, dass viele den Key am Anfang nicht ersetzten und es später schlicht vergessen werden.

Genau darum gings mir als ich den Blogbeitrag gelesen hab und warum/wie das jetzt sooooo sicher/anonym sein soll. Es gibt jetzt aber nen weiteren Eintrag indem er ( der Blogschreiber ) das etwas korrigiert doch naja ( Zitat: Fazit: Ein Abmahnanwalt kann eure IP wissen, er kann aber nicht wissen, was ihr downloadet! ) ...

Ist eigentlich ganz lustig der Blog XD

Wens intressiert, hier sind die beiden Blogeinträge:
http://ebookspender.blogspot.de/2014/03/farewell-to-abuse.html
Der Spiegelbest-Blog: Ist Sharefest abmahnsicher?
 
Zuletzt bearbeitet:
Das Konzept dahinter - WebRTC - solltet ihr euch merken. Es findet eine Übergabe der Datei statt, ohne dass eine IP benötigt wird. Irgendein neues Protokoll, keine Ahnung. Stellt euch ein dezentrales p2p als ein a2a - anonym-to-anonym - vor, dann habt ihr den Durchbruch beim Filesharing!
[...]
Stellt euch die Abmahnanwälte vor und den Schrecken, der ihnen die Gesichtmuskeln lähmt (geradezu botoxmäßig), angesichts von Torrents ohne IP!
[...]
Da Sharefest dezentral aufgestellt ist, gibt es keinen Adressaten für eine Abusezustellung gibt. Insofern wandelt der Uploader in trockenen Tüchern.
[...]
Fazit: Ein Abmahnanwalt kann eure IP wissen, er kann aber nicht wissen, was ihr downloadet!

Mein Tip: Nicht so viel Schund glauben, sondern einfach mal selbst recherchieren, was WebRTC ist und warum es nicht anonym sein kann. Da lernt man auch mal was dabei ;)
 
Mein Tip: Nicht so viel Schund glauben, sondern einfach mal selbst recherchieren, was WebRTC ist und warum es nicht anonym sein kann. Da lernt man auch mal was dabei

Deshalb meine Frage hier an die allwissende liebliche Schwarze Beere ;)

Danke :thumb_up:
 
Aus den Kommentaren hier: https://www.blogger.com/comment.g?blogID=8712179580917871690&postID=8503833288105406954

der Lesser hat gesagt...

hier wird genau darüber diskutiert
http://www.hackerboard.de/security-allgemein/48590-sharefest-me-webrtc-anonym.html
und die kommen auch zu der Meinung es ist nicht anonym also lasse ich meine Finger weg
30. März 2014 10:15
Spiegelbest hat gesagt...

@der Lesser

Auch deine GraueBeere schreibt reichlich am Thema vorbei. Es geht nicht um Anonymität der Teilnehmer, sondern um verschlüsselte Pakete, deren Inhalt unbekannt ist.

XD da hab ich ja was losgetreten aber "GraueBeere" tststs Frechheit, unsere Beere ist und bleibt Schwarz! ;)
 
Zuletzt bearbeitet:
Kurz zur Klarstellung, da es scheinbar doch Leute gibt, es das Prinzip eines Forums nicht verstanden haben: Hier wird behauptet, dass sharefest anonym sei. Das ist, wie ich oben dargelegt habe, schlichtweg falsch.

Und nun zu etwas sachlichem Bashing: Der Author definiert kein fundiertes Angreifermodell, sondern trifft nur implizit (falsche) Annahmen. So besitzen seine Angreifer die Möglichkeit, den Traffic zu mitzuschneiden und zu untersuchen, mehr allerdings nicht. Da die Angreifer (Behörden) nicht wissen, was überhaupt übertragen wird, können sie auch nicht feststellen, ob die Inhalte illegal sind und ob es sich um einen Up- oder Download handelt. Daraus wird dann geschlossen, dass sharefest sicher sei.
Beide Annahmen sind gröbster Unfug:

  1. In Anbetracht der Realität ist dieses Angreifermodell auch schlicht völliger Unsinn. Alle Peers zu überwachen wäre allein schon aus organisatorischer und rechtlicher Sicht völliger Wahnsinn. Stattdessen wird ein Angreifer systematisch an die Sache heran gehen und versuchen, diejenigen zu finden, von denen er die Datei bekommen könnte.
    Man wählt also den Ansatz, einfach selbst mal eine Datei herunterzuladen und alle Peers, von denen man die Datei bezieht, zu protokollieren. Macht man das mit genügend Dateien, so bekommt man schnell eine Sicht auf das Netzwerk und kann mittels Korrelation schnell und einfach die Seeder bestimmen und damit auch zwischen Up- und Download unterscheiden. Das funktioniert auch dann, wenn die Chunks von anderen Dateien stammen (was ab einer gewissen Chunkgröße recht unwahrscheinlich ist...).
    Ein zweiter Ansatz wäre, das Netzwerk mit einem modifizierten Peer zu betreten und Peers dazu zu bringen, bestimmte Informationen über sich preiszugeben. Dies kann z.B. im einfachen Falle sein, dass einfach die Anweisung des Coordinators übergangen wird und stattdessen die komplette Datei von einem Peer angefragt wird.
    Ein dritter Ansatz wäre die Beschlagnahmung des Coordinators (analog zum Tracker von Pirate Bay), der alle Peers und deren Chunks kennt. Kennen die Behörden die Chunks, dann können sie auch die Peers bestimmen, die die Dateien verteilen.
  2. Für ihn TLS nur "rein akademisch" unsicher. Dass dies fundamental falsch ist, zeigt die Geschichte (hier,hier, ...).

Auch in den Kommentaren verbreitet er wieder seinen Schwachsinn:
Du lädtst nichts direkt von mir runter!
Das ist falsch. Solange er der einzige Peer ist, der ein bestimmtes Chunk besitzt, lade ich von ihm runter. Je mehr Peers dieses Chunk (d.h. je größer der sog. Schwarm, siehe z.B. hier) besitzen, desto unwahrscheinlicher wird es - das ist richtig. Auf der anderen Seite erhöht sich aber die Wahrscheinlichkeit wieder, wenn immer mehr Peers dieses Chunk anfordern, da der Coordinator die Anfragen wahrscheinlich gleichmäßig verteilt.

Was für eine Comedy-Show... Du solltest den Schund echt nicht lesen, wenn du nicht daran verblöden willst..

edit:
Da fleissig dagegen kommentiert wird:
Die beiden anderen sind aus der 'Erzähl-mal-eine-Geschichte'-Ecke.

Ansatz zwei wird aktuell z.B. im Tor-Netzwerk angewendet, wie man an den roten Einträgen auf dieser Seite leicht sehen kann. Für bittorrent gibt es z.B. bitthief, oder Papers wie http://dl.acm.org/citation.cfm?id=1901332, die genau dieses Thema behandelt und vorhandene Software modifizieren, um ihre Ziele zu erreichen. Ansätze sind auch unter dem Namen Torrent Poisioning bekannt. Warum sollten die Strafverfolgungsbehörden das nicht auch machen?
Eine andere Möglichkeit wäre es, das Netzwerk mit Clients so zu "überfluten", dass man als Up- und Downloader einer beliebigen Datei identifiziert werden kann - weil man praktisch immer von einem "Angreifer"-Peer herunterläd oder zu einem Angreifer-Peer hochläd. Das ist einfachste Statistik. Dem setzt sharefest ebenfalls nichts entgegen.

Ansatz drei ist direkt aus der Praxis und am Beispiel Bittorrent auch leicht nachvollziehbar. Es gibt genügend Beispiele, bei denen der Tracker hochgenommen wurde, weil die Behörden IPs der Kunden in den Logfiles vermutet haben. Gleichzeitig ist der Coordinator ein weiterer Player: Wenn er vom Netz genommen wird, dann fällt das Netzwerk zusammen (Stichwort Robustheit von P2P-Netzwerken). Aus diesem Grund wurde DHT in Bittorrent integriert. Das fehlt allerdings bei sharefest. Damit kann man nur den Schluss ziehen, dass der Coordinator ein Ziel werden wird, wie eben bei bittorrent auch.

Aber auch bei Ansatz 1 bleibt es dabei, dass die Chunks verschlüsselt sind.
Die Chunks sind nicht verschlüsselt, sondern nur deren Übertragung. Die spielt aber hier überhaupt keine Rolle, da der Angreifer aus Seedersicht nur ein weiterer Peer im Netzwerk ist, der sich die Datei runterläd. Und wie jeder Peer wird er am Ende aus den Chunks seine Datei erhalten, die den illegalen Content enthält. Ergo: Er hat sich illegalen Content von den Peers, die er in dieser Zeit protokolliert hat, heruntergeladen. Den Vorgang wiederholt er solange, bis er von einigen der Peers mehr als nur 1 Chunk bekommen hat. Damit hat er dann faktisch den Beweis erbracht, dass dieser Peer die Datei haben muss und sie verbotener Weise hochgeladen hat. q.e.d.
 
Zuletzt bearbeitet:
*holt sich Popkorn*
Dann wollen wir mal bissle mittrollen bei der "April-April!!1" - Serie mitmachen:
Spiegelbest hat gesagt.:
Das Konzept dahinter - WebRTC - solltet ihr euch merken. Es findet eine Übergabe der Datei statt, ohne dass eine IP benötigt wird.
so so
https://github.com/Peer5/ShareFest/...ea31fb90/core/transport/PeerConnectionImpl.js
Code:
this.RTCPeerConnection = webkitRTCPeerConnection;
https://github.com/WebKit/webkit/bl...ore/Modules/mediastream/RTCPeerConnection.cpp
=>
https://github.com/WebKit/webkit/bl.../platform/mediastream/RTCDataChannelHandler.h
Code:
virtual bool sendRawData(const char*, size_t) = 0;
=> https://github.com/WebKit/webkit/bl...InspectorServer/WebSocketServerConnection.cpp
Code:
void WebSocketServerConnection::sendRawData(const char* data, size_t length)
{
    m_socket->send(data, length);
}
Hm, man könnte natürlich auch einfach mal schauen, was die API für Parameter entgegen nimmt (Stichwort: STUN/TURN), aber das wäre ja langweilig =)
Und nein, ich komme mir hierdurch nicht nur cool vor - ich bin es auch - f34r m5 s|<i11z 8)

spiegelbest hat gesagt.:
Es ist Open Source - anders als BitTorrent (noch so ein Zauberding!).
http://www.bittorrent.org/beps/bep_0003.html
http://en.wikipedia.org/wiki/BitTorrent_(protocol)
Comparison of BitTorrent clients - Wikipedia, the free encyclopedia
:confused:
Kurzgefasst: Sharefest ist besser als Bittorent, da im Gegensatz zu diesem OpenSource und anonym dank WebRTC + Ratz-Fatz-Test-es-geht-voll-cool.
beides ("as is") erstmal aus => (Zitat: 'Erzähl-mal-eine-Geschichte')-Ecke =)
der lustige blogger hat gesagt.:
Ich denk mal, der obige Artikel hat es auch den Punkt gebracht: Wenn ihr Sharefest nutzt, gebt ihr in dem DataChannel nicht unterscheidbare Pakete weiter. Durchaus möglich, dass ihr fremde Urlaubsfotos weitergebt. Erst anhand des verschlüsselt übertragenen Access Key (= der Sharefest-Link) wird das richtige Datenpaket zusammengesetzt.
Fazit: Ein Abmahnanwalt kann eure IP wissen, er kann aber nicht wissen, was ihr downloadet!
ja, vor allem wenn man sich das lang genug einredet und einfach mal ignoriert, dass der "obige Artikel" sich eigentlich auf "Is it actually truly anonymous for those with agressive ISPs?" bezieht :)
Die Aussage: "wenn ein dritter das Zeuch mitschneidet, weiß er nicht, was ihr ihr gerade herunterladen tut". Heißer Tipp: passwortgeschützte Ziparchive oder TLS Verbindungen haben i.d.R die gleiche "Eigenschaft" =)
Ja, btw: wer ist denn dieser "Abuser", der mal eben MEINEN Traffik über seine Knoten umleiten kann?

Nochmal zum Mitschreiben: Es ist völlig egal, ob jemand feststellen kann, wer ihr seid, wenn er nicht feststellen kann, was ihr treibt.
echt?
Wenn hier jemand darstellt, wie die Verschlüsselung von Sharefest zu knacken ist, dann hat er einen Punkt gemacht, andernfalls könnt ihr getrost vergessen, was er geschrieben hat.
na, ich würde mir auch gern die Welt schönreden =)
Fazit: Ich bin der Meinung, dass sharefest voll cool ist, weil ... hm, hier habt ihr ein aus dem Kontext gerissenes Zitat und hier noch meine Erfahrungsbreichte!!!1elf

TL;DR - ändert man 1 Zeile Code, bekommt man alle Blöcke einer Datei von einem einzigen Teilnehmer.
Fügt man 2-4 Zeilen dazu, wird man auch gezielt Blöcke einer Datei von einem bestimmten Teilnehmer anfordern können.
Ändert man 0 Zeilen (also per Default) bekommt man TeilnehmerIPs von dem "Coordinator" (ja, so funktioniert die Kommunikation nun mal)
=> man kann sowohl nach aktuellen "Downloadanbietern" suchen wie auch gezielt komplette Downloads von einem einzigen Teilnehmer durchführen. Ganz ohne "theoretischen Laberkrams" (sofern man das Hinzufügen einiger Zeilen Code nicht gerade für ein Hexenwerk hält).
====================================
# So, jetzt kommt 0v3rl337n3z pur ..--OO::(oo) <obligatorische ASCII-Art-hier>
====================================
Dann mal los:
Da ich kein "Sportfilesharing" betreibe, kenne ich nur die "klassische" Vorgehnsweise,
bei der der böse Abmahner nur an Uploadern interessiert ist und folgende Möglichkeiten hat:
Eine Suche mit einem (modifizierten) Client + Screenshot/Logerstellung
oder:
Erzwingen der Datenherausgabe bei einem zentralen Server
nur btw: bei keinem dieser Ansätze wird der komplette FS-Traffik überwacht.

Angriffspunkte hier:
1) Sharefest selbst - ist eine Blackbox:
- bekommt alle Infos geliefert
- wer steckt dahinter?
- was wird mit den Userdaten gemacht?

ok, bla, laber, zu theoretisch und so - gibt ja verschlüsselte Packete und so und überhaupt - es geht ja "ohne IP" *scnr*

2) der Client(Browser) selbst
https://github.com/Peer5/Sharefest
Ein Peer lädt Chunks von anderen Peers herunter, setzt sie zusammen und erhält eine Datei.
hier ist nur die Frage, ob es für "Probleme" a) schon eine angebotene "Downloadmöglichkeit" ausreicht oder b) erst verifiziert werden muss, ob dies auch wirklich die Datei ist (also einen kompletten Download abschließen).
Prinzipiell könnte ein Chunk samt einem Hash ausreichen - aber das ist eher eine juristische Frage, die kaum etwas mit tech. Details zu tun hat.

So oder so - "Null Problemo":
https://github.com/Peer5/ShareFest/blob/master/sharefest/server/lib/router.js
Code:
 app.post('/new', function (req, res) {
        peer5.info('request for a new swarm');
        var fileInfo = req.body;
        peer5.info(fileInfo);
        var swarmId = tracker.instance.createSwarm(fileInfo);
        res.send(200, swarmId);
    });
Code:
join:function (peerId, swarmId, browser, sender) {
        var swarm = swarms.getSwarm(swarmId);
        if (swarm) {
            sender.send(peerId, swarm.metadata);
            //match only when swarm has peers in it already
            if (swarm.count > 0) {
                var peers = swarm.getRandomK(this.MAX_PEERS_MATCH);
                //create Match message
                //TODO: loop thru peers and send one by one
                if (peers && peers.length > 0) {
                    sender.send(peerId, new protocol.Match(swarm.id, peers));
                }
            }
Wir bekommen also Random-Peers - sofern welche da sind.
Was ist eine PeerID?
Code:
createSwarm:function(peerId, fileInfo, sender)
join:function(peerId, swarmId, originBrowser, sender)
Code:
switch (entry.tag) {
                            case protocol.JOIN:
                                tracker.join(socket.id, entry.swarmId, browserName, thi$, socket.ip, socket.token);
                                break;
                            case protocol.FILE_INFO:
                                entry.originBrowser = browserName;
                                tracker.createSwarm(socket.id, entry, thi$);
(ja, wer hätte es denn gedacht, dass 'ne ID einem Socket entspricht :rolleyes: )

Na, und wie läuft das mit dem Download ab?
Code:
radio('P2PAvailableEvent').subscribe([function(swarmId){
                if (this.prefetchFlag[swarmId])
                    this.prefetch(swarmId);
            },this])
...
/**
         * download more chunks
         * @param startBlock optional start block index (default 0)
         * @param endBlock optional end block index (default last block index)
         */
        download:function (swarmId, startBlock, endBlock) {
            if(!this.isAvailable(swarmId)) return;
            //store the needed blocks for the specific swarm
            peer5.log("startBlock = " + startBlock + " endBlock = " + endBlock);
            var chunkIds = this.allocateChunks(swarmId, startBlock, endBlock);
            //console.log(chunkIds[0] + ' ' + chunkIds[chunkIds.length - 1]);
            this.distributeChunksAmongSources(swarmId, chunkIds);
        },
allocateChunks => was haben wir noch nicht?
distributeChuncks => herunterladen.
d.h eigentlich sollte distribute sehr sehr interessant sein.
Auszugsweise:
Code:
 var sortedPeers = Object.keys(this.peerConnections).sort(function (a, b) {
                return thi$.peerConnections[a].numOfPendingChunks > thi$.peerConnections[b].numOfPendingChunks
            });
die Peers werden nach der Menge der laufenden Chunkdownloads sortiert.
Code:
for (var k = 0; k < sortedPeers.length; ++k) {
                if (chunkDist[sortedPeers[k]]) {
                    var remotePeerId = sortedPeers[k];
                    var chunkIds = chunkDist[remotePeerId];
                    this.addToPendingChunks(swarmId, chunkIds, remotePeerId);

                    this.peerConnections[sortedPeers[k]].numOfRequestedChunks += chunkIds.length;
                    var requestMessage = new peer5.core.protocol.Request(swarmId, chunkIds);
                  ...
                    this.peerConnections[sortedPeers[k]].send(encodedMsg);
und ein Request an diese Kandidaten gesendet.

Nochmal zum mitschreiben:
https://github.com/Peer5/ShareFest/...c995dd8d801/core/protocol/ProtocolMessages.js

Code:
function Request(swarmId, chunkIds) {
        this.tag = exports.P2P_REQUEST
        this.swarmId = swarmId;
        if (!chunkIds) chunkIds = [];
        this.chunkIds = chunkIds;
    }
und der Handler:
https://github.com/Peer5/ShareFest/...143ea31fb90/core/controllers/P2PController.js
siehe PeerConnectionEvents-dispatching
Code:
receiveRequestMessage:function (requestMessage, originId) {
  
            this.sendData(requestMessage.swarmId, originId, requestMessage.chunkIds, 0);
            radio('requestChunks').broadcast(requestMessage.swarmId, originId, requestMessage.chunkIds);
        },

...

sendData:function (swarmId, peerID, chunkIds , iter) {
            if(!this.canUpload(swarmId)) return;
            if(peer5.config.EMULATE_LOSS && Math.random() < peer5.config.EMULATE_LOSS_PERCENTAGE) return;
            if(peer5.config.USE_FS){
                var chunkId = chunkIds[iter];
                iter++;
                var thi$ = this;
                peer5.core.data.BlockCache.get(swarmId).getChunk(chunkId,function(succ,data){
                    var dataMessage = new peer5.core.protocol.Data(swarmId, chunkId,data);
                    var packedData = peer5.core.protocol.BinaryProtocol.encode([dataMessage]);
                    thi$.peerConnections[peerID].send(packedData);
                    radio('chunkSentEvent').broadcast(swarmId);
                    if(iter<chunkIds.length)
                        thi$.sendData(swarmId, peerID, chunkIds, iter);
                });
            }else{
                for(var i=0;i<chunkIds.length;++i){
                    chunkId = chunkIds[i];
                    var data = peer5.core.data.BlockCache.get(swarmId).getChunk(chunkId);
                    var dataMessage = new peer5.core.protocol.Data(swarmId,chunkId,data);
                    var packedData = peer5.core.protocol.BinaryProtocol.encode([dataMessage]);
                    this.peerConnections[peerID].send(packedData);
                    radio('chunkSentEvent').broadcast(swarmId);
                }
            }
d.h: falls der Block/Chunk vorhanden ist, wird mit (im Moment nicht gesetzter) (1- EMULATE_LOSS) Wahrscheinlichkeit zurückgesendet.
Ich sehe auch keine Checks, wiederholte Anfragen nach einem bestimmten Chunk zu ignorieren (d.h man kann diese einfach wiederholen).
Man kann also gezielt Blöcke von einem bestimmten Peer anfordern.
====================================================
# ===oOO=(Ö_Ö)=OOo==
====================================================
Zwischenergebnis (unter beachtung der Tatsache, dass das ganze nur mal schnell im Github-Webinterface durchgesichtet wurde):
Wir haben eine Datei. Zu dieser gehört ein "Schwarm".
Ein Schwarm sind einfach alle Peers, die diese Datei herunterladen.

Ein neuer Peer kommt rein, schickt eine Anfrage an den Initialserver/Bootstrapper und bekommt zufällige andere Peers als Nachbarknoten aus diesem Schwarm.
Nun werden von diesen Nachbarn Dateiparts aka Blocks/Chunks heruntergeladen. Nicht über Quantenkanäle oder Magie, sondern ganz schlicht über das gute alte IP. Auch wenn die Channel-Abstraction/WebRTC viel viel cooler klingen.

Diese sind per default verschlüsselt. Was zumindest aus der Sicht eines Peers absolut wurscht ist.
Feststellen, ob die Downloadanfrage von einem Abmahn-Client kam, kann er nicht.
Für die unmittelbaren Teilnehmer ist das ganze transparent.
Ein Peer kann sowohl mehrere Anfragen an den Bootstrapper stellen wie auch gezielt Blöcke von einem anderen Peer anfordern.
==================================
# ...oooo000OO(°_°)
==================================
Demnach:
a) - Downloadmöglichkeit feststellen - check.
Einfach einen Seedlink suchen und eine Anfrage senden.
Jeder zurückgelieferte Peer ist auch ein Anbieter. Hat doch noch nie jemanden interessiert, ob die Datei selbst "gerippt/whatever" oder nur heruntergeladen wurde.
Und wenn man mehfach die Initial-Anfrage verschickt, bekommt man auch andere Peers/Anbieter =)

b) einen kompletten Download abschließen - check.
hochspezialisierte Praktikanten/Praktikantin Softwareschmieden beauftragen, die in P2PController.js die Zeile 310 ändern (statt einer Liste ein einziges "Opfer" auswählen und Anfragen nur an diese IP stellen - ja, rein zufällig ist's der Ansatz 2) welcher ja angeblich aus der "Erzähl-mal-eine-Geschichte"-Ecke stammen würde =))
für ein paar Euro/Std mehr gibt es noch IP-Ausgabe dazu sowie 'n Patch der "allocatechunks"-Funktion (siehe oben), damit man nicht immer lästigerweise den Cache leeren muss und statt "lade fehlende Chunks nur bei einem Peer nach" => "lade Chunks/Blocks nacheinander von allen Peers und logge diese" bekommt.

Als böser Abmahner sucht man also einen SeedLink, "startet" diesen und lädt alle Blöcke herunter.
Peers, die alle Blöcke geliefert haben, sind "dran".
Lässt sich auch "nachhelfen", in dem die Blockanfragen nur an diesen Peer gesendet werden ODER grundsäztlich alle Blöcke, von 0 bis max, von jeweiligen Nachbarn geladen.
Mechanismen, die dies (komplette Datei an einen einzigen Peer ausliefern) verhindern, sehe ich im Moment nich. Und wenn diese implementiert werden:
Einfach mit dem Bootstrapper verbinden, PeerIPs abholen und dann mit ein paar eigenen Peers direkt mit den jew. Teilnehmern verbinden (auf die Schnelle sehe ich auch hier nichts, was dagegen sprechen würde - denn dann müsste der Initialserver an alle Peers, die an Anfrager X zurückgeliefert wurden, eine entsprechende Benachrichtigung schicken).

Also: Ein low-budget-modifizierter (3-4 Zeilen) Client wird dabei einfach alle Blöcke von einem Peer herunterladen.
Mit ein paar Zeilen mehr bekommt man das in "parallel".
Nein, das ganze zu ändern ist keine Raketenwissenschaft/Quantenphysik - eine JS IDE und ein paar Minuten (bis Stunden - je nach dem was man erreichen möchte und ob man JS kennt) Zeit.
In allen Fällen ist es doch absolut unnötig, den "Initial-Seeder" zu bestimmen - jeder Peer ist ein Kandidat.

Es hat schon was, wenn man nicht nur auf Marketinggelabbere und andere Blogs angewiesen ist, sondern sich auch Primärquellen reinziehen kann =)

Nicht, dass es in irgendwelcher Weise dem eigentlichen peer5/Sharefest Ansatz abträglich wäre
https://github.com/Peer5/ShareFest hat gesagt.:
One-To-Many sharing application. Serverless. Eliminates the need to fully upload your file to services such as Dropbox or Google Drive.
Nur dem Versuch daraus, auf Biegen oder Brechen, ein Ulitmate-Full-High-Ano-Filesharing zu machen.
=================================
#.......(_o_)........
=================================
PS:
Spiegelbest hat gesagt.:
Ein Abmahnanwalt kann im Browser sehen, dass ihr Sharefest benutzt, aber nicht wofür. Was bei Torrents im Tracker sichtbar ist, das ist bei WebRTC im Datenkanal unsichtbar, bzw. ohne IP.
April April oder doch *MMD*?
Ich könnte sogar ohne VPN hochladen, da niemand einen Uploader von einem Downloader unterscheiden kann und alles verschlüsselt übertragen wird.
...
Dass ein VPN überall Surfgrundausstattung sei ausdrücklich gesagt.

Aber natürlich ist auch ein VPN nicht sicher ... Und genau das ist der Grund, warum keiner solche Hackerboaderliner für voll nimmt.
na wat denn nu - mit oder ohne VPN? Vielleicht sollte man VPNs auch mal für sich alleine betrachten.

Ergo: ein haufen Sätze Beiträge mit "x" - oder ein gelungener Aprilscherz?
Vielleicht ist das der Grund, warum niemand "Sportfilesharer" ernst nimmt =)
 
Zuletzt bearbeitet:
Nach der anfänglichen Euphorie des Blogbetreibers Spiegelbest hat er sich nun wohl doch überzeugen lassen:

Der Spiegelbest-Blog: Sharefest-Links in Theorie und Praxis

Der Spiegelbest-Blog: Sharefest - abmahnriskant wie die Torrents

Der Spiegelbest-Blog: [news] Die Spiegelliste (nun doch) als Sharefest-Link

Wie sicher ist Sharefest?

Von nem obigen Artikel (ebookspender.org)
Da die Freaks -> hackerboard.de Sharefest ablehnend diskutieren und die Journalisten es nicht weniger negativ darstellen -> tarnkappe.info, nochmal was von mir dazu:
:D

Von dem Link Tarnkappe.info
Wer meint, er müsse via Sharefest von Spiegelbest die 90 aktuellen Titel der Spiegel Bestsellerliste herunterladen, soll dies bitte auf eigene Gefahr tun. Davon kann zum jetzigen Zeitpunkt nur abgeraten werden! So lautet auch das Fazit der Diskussionsteilnehmer bei hackerboard.de. Sobald die kritische Masse erreicht wird, werden sich auch die ersten Rechteinhaber für diese neuartige Technik interessieren. Nur weil etwas bisher noch nicht passiert ist, heißt es nicht, dass den Nutzern auch in Zukunft keine Abmahnungen drohen.
 
Diesmal mit Code, Screenshot und Video!!!1
----------
*hust* klassisches Trolling *hust* *mitmach*
http://ebookspender.blogspot.de/2014/04/sharefest-links-in-theorie-und-praxis.html hat gesagt.:
Ich empfehle jetzt jedem Nutzer, Sharefest-Links im Tor-Netz oder mit einen VPN zu laden. Und ich sage euch jetzt schon, dass dies den Hackern vom Hackeboard nicht genügen wird,
denn nach ihrem Verständnis ist Tor unsicher und ein VPN kann gehackt werden.
...
*vergeblich nach diesen Aussagen im Thread such* :(

Hm, ja, VPN-Sicherheit wurde im Forum zigfach durchgekaut - allerdings immer in einem bestimmten Kontext - z.B was genau geschützt werden sollte, gegen wen und wie die restliche Konfiguration des Rechners ausschaut. (Hint: VPN lässt sich "unter anderem" für eine sichere Verbinung in einem nicht vertrauenswürdigen Netzwerk (z.B offenem WLAN) verwenden)

Dieser "Argumentationslogik" nach wird aber in Autoforen auch behauptet, dass man sich nicht anschnallen sollte - da irgendwo diskutiert wurde, dass die Gurte nicht gegen einen Aufprall bei 200 km/h schützen :rolleyes:

Für mich stellt sich die Frage, was eine Diskussion soll, die so theoretisch ist.
...
Nochmal - und es wird von Schwarze Beere nicht bestritten - bei Sharefest wird ein Netz von Peers aufgebaut, ohne IPs, über den Browser! Es ist p2p ohne Abmahnscreen
...
Das gesagt, können die Teilnehmer des Austausches und der Inhalt der verschlüsselten Dateien indirekt trotzdem bestimmt werden. Dies ist aber sehr viel aufwändiger und umständlicher.
...
Spiegelbest hat gesagt…
@ der Lesser

Dass es IDs (nicht IPs!!) geben muss, ist ja unbestritten.
...
Zudem ist Sharefest so anonym oder unanonym wie das Tornetz.
Für mich stellt sich die Frage, wie man nur so viel komisches Zeug in fremde Postings reininterpretieren kann und ob es nicht zeitsparender gewesen wäre, mal in die RFCs Wikipedia zu schauen, statt dutzende Blogbeiträge/Kommentare über ein Thema zu verfassen, von dem man anscheinend keine Ahnung hat :)

Vor allem:
Edit: Wer meint, dass bei Sharefest IPs auslesen werden können, die eine einzelne identifizierbare Datei verteilt haben, soll es einfach beweisen, indem er einen Screenshot macht.
Immer wieder interessant/amüsant, wie Leute einen konkreten, arbeitsaufwändigen Gegenbeweis (Screenshot mit IPs und Datei, ne?) für ihre nicht belegten Behauptungen fordern :)
--------------------------------
"Beweis":
--------------------------------
Modifikation:
Code:
[color=#000080][b]diff --git a/core/controllers/P2PController.js b/core/controllers/P2PController.js
index a597791..9427508 100644
[/b][/color][color=#A00000]--- a/core/controllers/P2PController.js
[/color][color=#00A000]+++ b/core/controllers/P2PController.js
[/color][color=#800080][b]@@ -424,6 +424,19 @@
[/b][/color]         },
 
         receiveP2PChunk:function (swarmId, originPeer, chunkId, data) {
[color=#00A000]+            var str_data = String.fromCharCode.apply(null, data);
+            var cand_lines = this.peerConnections[originPeer].peerConnection.remoteDescription.sdp.split('\n');
+            var direct_ip = cand_lines.filter(
+                function(line){return line.lastIndexOf("c=IN",0) >= 0}
+            );
+            var ice_cands = cand_lines.filter(
+                function(line){return line.lastIndexOf("a=cand",0) >= 0}
+            );
+            console.log("receiving a chunk for ", swarmId);
+            console.log("ChunkId:", chunkId, "from peer:", originPeer);
+            console.log("chunk data:",str_data);
+            console.log("PeerIp:", direct_ip);
+            console.log(ice_cands.join("\n"));
[/color]             peer5.debug("receiving chunk " + chunkId);
             var blockMap = peer5.core.data.BlockCache.get(swarmId);
             if (!blockMap.hasChunk(chunkId)) {
[color=#800080][b]@@ -524,4 +537,4 @@
[/b][/color]             return this.resourceState[swarmId];
         }
     });
[color=#A00000]-})();
[/color]\ No newline at end of file
[color=#00A000]+})();
[/color][color=#000080][b]diff --git a/package.json b/package.json
index fbf2d46..aec8034 100644
[/b][/color][color=#A00000]--- a/package.json
[/color][color=#00A000]+++ b/package.json
[/color][color=#800080][b]@@ -4,7 +4,7 @@
[/b][/color]     "version": "1.0.0",
     "author": "",
     "dependencies": {
[color=#A00000]-        "express": ">=3.0",
[/color][color=#00A000]+        "express": "=3.0",
[/color]         "underscore": "",
         "uglify-js": "=2.2.5",
         "ws": ">=0.4",
[color=#000080][b]diff --git a/sharefest/server.js b/sharefest/server.js
index 53beb57..6d4662b 100644
[/b][/color][color=#A00000]--- a/sharefest/server.js
[/color][color=#00A000]+++ b/sharefest/server.js
[/color][color=#800080][b]@@ -45,10 +45,10 @@ app.configure('production', function () {
[/b][/color]     var options = {
         // Important: the following crt and key files are insecure
         // replace the following files with your own keys
[color=#A00000]-        key:fs.readFileSync('secret/private.key'),
-        ca:[fs.readFileSync('secret/AddTrustExternalCARoot.crt'),
-            fs.readFileSync('secret/SSLcomAddTrustSSLCA.crt')],
-        cert:fs.readFileSync('secret/www_sharefest_me.crt')
[/color][color=#00A000]+        key:fs.readFileSync('sharefest/server/secret/private.key'),
+        //ca:[fs.readFileSync('secret/AddTrustExternalCARoot.crt'),
+        //    fs.readFileSync('secret/SSLcomAddTrustSSLCA.crt')],
+        cert:fs.readFileSync('sharefest/server/secret/self.crt')
[/color]     };
     app.use(express.errorHandler({ dumpExceptions:true, showStack:true }));
 //    wsPort = process.env.WS_PORT || 443;
[color=#800080][b]@@ -63,4 +63,4 @@ app.configure('production', function () {
[/b][/color] //    signaling.start(server);
 });
 
[color=#A00000]-router.configure(app, __dirname);
[/color]\ No newline at end of file
[color=#00A000]+router.configure(app, __dirname);
[/color]
Das gibt einfach bei jedem emfangenen Dateiblock den Absender (=> "Verteiler") und den Inhalt (noch eindeutigere Identifizierung geht wohl kaum) aus.
Daher (lesbare Ausgabe) wird in der Demo eine Textdatei verwendet.

Vergleichsweise "Aufwändig und umständlich" (zumindest der Compiliervorgang für den Rechner) wäre es, die webRTC Browserkomponenten zu patchen, so dass ein wirklich sauberer Log gemacht wereden kann.
Screenshot:


Video:
1280x720, nicht skaliert. Wer mag, kann es bei YT/vimeo&Co hochladen (ich werd' mich da jetzt nicht nur für dieses eine Video anmelden - und ja, ich weiß, ich bin uncool :) )
(am 16.08.14, 15.11.14 neu hochgeladen, wegen "Diese Datei wurde vom User oder durch eine Abuse-Meldung gelöscht" :rolleyes: )
File-Upload.net - sharefest_demo.mp4
PS: "as is" ist die Sharefest-App erstmal sowieso nicht produktiv einsetzbar (Hint: leere Nachrichten == "DoS", gibt einen Neustart der Anwendung und alle Raum/Schwarminformationen gehen verloren ;) )
 
Alternativvorschlag:
Die Datei, die man teilen will, einfach mit einem guten Passwort (und natürlich guter Verschlüsselung) archivieren und irgendwo hochladen.

Dann den Link mit seinem Freund teilen und das Passwort über einen sicheren Seitenkanal mitteilen.
(Oder: Die Datei mit dem öffentlichen Schlüssel des Freundes verschlüsseln und hochladen)

Jetzt haben wir die selbe Situation wie die von sharefest intendierte*. IPs sind dem Hoster (und potentiellen Abmahnern?!) zwar bekannt, aber der Inhalt nicht.

Vorteil: Ich muss mein Tab nicht die ganze Zeit aufhaben und mein Freund kann auch runterladen, wann er will.

Noch eine Idee: SFTP mit Public-Key-Auth. Möchte man zusätzlich Anonymität kann man das über einen Tor Hidden Service abwickeln.
Es gibt sie also: Die sicheren Tauschmöglichkeiten. Sharefest gehört wohl leider nicht dazu.
 
Aber dafür braucht man Freunde die Bücher kaufen, sich mit Verschlüsselung
auskennen und Web-Space haben.
Dies könnte im betroffenen Milieu durchaus schwierig werden.

Gruss
 
Zurück
Oben