An easy way to share files P2P, and how it works | Hacker News Reader

An easy way to share files P2P, and how it works

torrentfreak.com

175 pointsshacharz98 comments

I submitted a feature request for encryption over this (it's probably vulnerable to MITM attacks as-is, as you never verify the recipient). My request was:

* Generate the URL like sharefest.me/roomid#randomstring

* Sharefest encrypts the file contents before and after transmission with randomstring as key using the SJCL.

* Send the URL/key out of band, over a secure channel.

* Voila, end-to-end crypto.

I don't know if anything became of it, though.

EDIT: Oh, here it is: https://github.com/Peer5/ShareFest/issues/24

Yea you're right, we just didn't get around to it yet. Thanks for the issue.

You are quite welcome, hopefully you'll find some time soon, it would make Sharefest the file transfer mode of choice for paranoid people like me :)

Out of interest, if the decryption is being done in a client by JavaScript, what's stopping a MITM attacker replacing the JavaScript crypto library with something that captures the source URL and key?

That's a well-known problem with JavaScript crypto: http://www.matasano.com/articles/javascript-cryptography/

The short answer is that so long as the page is loaded entirely over TLS, and the TLS isn't stripped or subverted in any way, it's safe from MITM. Sharefest doesn't currently support TLS, so they would need to set that up prior to enabling end-to-end encryption.

The P2P crypto is done by the browser. But not doubt that we need to load the entire page and scripts securely securely...

Nothing (assuming the MITM is someone who can break HTTPS or Peer5 themselves), which is why I proposed this:

https://github.com/Peer5/ShareFest/issues/30#issuecomment-20...

You can download ShareFest, audit it and store it locally so you can run your known-good version. It's just an HTML page and a few JS files (or at least it was, last time I looked).

I was going to create a version of this that was a single webpage and had as little code as possible (for auditability and ease of saving/deployment), but other projects got in the way (plus it's easier to improve ShareFest than write it from scratch).

It's clearly not baseless paranoia anymore.

That's true, I guess. The funny thing is that the most I ever transfer is family photos and code, but I don't see why anyone should be able to look at even my family photos.

The other thing is, as with almost all web-based solutions, you're being tracked by various scripts in the background (Google API/JS, etc.). So, if you're paranoid, you're better off with a client solution.

Client side solutions can do even more tracking because there is no browser sandbox. And for example the µTorrent client has ads in it which are probably tracked.

Yes, I suggest using open-source clients that don't include ads (such as RetroShare). µTorrent is not open-source, btw.

So if the issue is tracking regardless, why not use a non-tracking web app?

Sure, but a client solution doesn't have the ease-of-use of this for the other party. I use Ghostery, incidentally, but your general point is that security on a live webpage is impossible, which I agree with. That's why I proposed that the app be made into a downloadable package as well.

It would be interesting to create a self sustained WebRTC client that can communicate with the web version.

It already can, the web version is just an HTML file with some JS too.

Personally, I don't see a better platform than RetroShare. That is why I believe, we're better off if we all get behind RetroShare:

Developers can extend this platform with as many plugins as they wish - as an open-source solution, it's totally open. (I believe fragmentation, more specifically increasing the number of less advanced solutions doesn't help...)

Why downloadable package is necessarily more secure than a live webpage over TLS (HTTPS)? Given that you can verify that Sharefest is Sharefest (using the certificate in the future), I don't see the big difference. I do think that a live webpage can be updated with security fixes more easily.

Being a live webpage also give us, as the developers, much less headaches in terms of protocol compatibility -- We maintain just one "version" of Sharefest client at the same time.

Because a downloadable package can't be replaced by something else the next time you use it, while Sharefest can, and nation-states can easily serve you whatever they want, even over SSL.

But nation-states can do that for downloadable packages as well, perhaps even the verifiers for those packages...

How?

They can spoof the package and its key. If the root of trust (CA) is tempered as you suggest and the chain of trust is broken, I don't see how you can really secure it.

Excellent, I was making a list of this kind of service but having the source code available is a must. And this is exactly what we need against NSA...

If someone is interested I share a list of similar approaches:

https://www.getshareapp.com/v2 (from BitTorrent, requires a plugin):

http://www.jetbytes.com/

http://www.filesovermiles.com/

http://host03.pipebytes.com/

Nice, well jetbytes and pipebytes do transfer the file via a server.

Supposing you're ok with using a client (open-source): http://retroshare.sourceforge.net is exploding.

(It's not just file sharing, though: it aims to address your entire encrypted p2p communication needs.)

There should be a HN keysharing thread. FWIW, here is mine:

  -----BEGIN PGP PUBLIC KEY BLOCK-----
   Version: OpenPGP:SDK v0.9
  
  xsBNBFHUtg4BCACvWPNRhEGm/n3o+1tr1ye71SWwiCYDdC8cTn7t38Gmo/E/HG4q
  hgOJvRp8kAStwryzggAwRrE8rfEsJEP6YaGw+vTQVQffwKw6C4MlGx3TJ5OgklLl
  93eAw0hfTVNZCcQ42g/wzEjigAcmb+Kd15M8wCKKNX0VR96SJjJMS+z7Fv0UGKSo
  MJnqS+6HLyR6SrgbIsRrGOziHDIz03ycH2T3Ckc66zmwvzi6uwcQFpVoqmtQZIiE
  nFzNJHLrtr+SlXQLw4rJgNixsUgiCBzm7nM2548ygk3OEOVFQA2HfSvrG8PlhdKo
  KtJBimYkov6eEgyDFrwBwUaqLUeSxHaH563JABEBAAHNJHBocmVlemEgKEdlbmVy
  YXRlZCBieSBSZXRyb1NoYXJlKSA8PsLAXwQTAQIAEwUCUdS2DgkQ7F/6kYGHq0IC
  GQEAAMNmB/9SOQFld2G8roNu+VOX5L0h0u6Hl4IsOpdxRkMofO0LFzH7n7+6EkBS
  sXOdBvcLo3UL2cJxCf3bI/u2MJrrRbIdls2id2g4egAtnupXtLVu6q6S1vRg40PB
  2ab4iJKe4Siz5QedsZd6HGfaV46fEWl6Tfu/sbIVH+5vHqc9A/CYUW8HjGQRFm0Z
  Q4P1jwHkMTt/o6fUWWmja6/2Wz3j4v8HtkAuvusVqlPXmdDDNpyOt9L3stTQF1XQ
  XskJaegiNhp8j7MlMEb9TGNFRaim1G/w8EwCauO8j+fjHJxvXmmqCzL/pG1cxKik
  WYWfKn3+Q5MUfPpGltj0HdOkEw/yuu35
  =37ck
  -----END PGP PUBLIC KEY BLOCK-----
  --SSLID--a71db6edde2788ece31c3437098be374;--LOCATION--mba;
  --LOCAL--192.168.0.4:33395;--EXT--92.229.126.245:44003;

I've added you as a friend on Retroshare. Don't forget to approve me.

I think you need to send me your public key for that.

Exactly. Both sides must initially exchange their public key (called "certificate" in this case).

It's of course the exact same logic as with encrypted email ("public key encryption" or "asymmetric encryption").

Sorry. Here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: OpenPGP:SDK v0.9

xsBNBFG0XDIBCADiHErShXdFVj8+XSsmYfVaeYwr3nykLVbfDQbQvYx2gNO23iXv UyGOqTqx7UtC3EP3oAoJqAAs7sK5OjklivV4WqxVQUwX9sqEYn2ht0u20K3rBXhh /c9TfcFFeGi9SwTkiA/754sQYu7Lz5iR4q6xmrb+Ki4CCuoxl06/7MBLoKOhS4ZO 2bkegwynbx5oMHAgfvR1Ov6au9IxFrm7W6HIC1IDRLisEQZnKg6PYE8KXTV1NbsU wikQ6hSIrnrlPvbkimbiVUTX8NwRSRXrDPW1YYw5oqU/HgNUA78Y9LIkTLwmdFrz 0LWs+gDTN3eethggEGrAkKVlQOPFg/3lUIdDABEBAAHNJGF3ZXNvbWUgKEdlbmVy YXRlZCBieSBSZXRyb1NoYXJlKSA8PsLAXwQTAQIAEwUCUbRcMgkQTx3tq5dI1QoC GQEAABbhCADSG2iosMirYi6MDJYvY7cwPluxpWYXkzNdW/fMJI+2iIWs39lGUDBY //tBZLwUW1zh5Bb1w+I0Ms8R35zgKH4f59pMpNTTeKTttQ8CQFekW3dCwKbNQRIc 6bdyafSilnI6jNrn4sYiMOmflqGurSVYFmQ8DUVg+pNHKGh909Gs3IahsWxpaGux NSPZ43h5oz/mDObJV9DUUxO8zpT011Fcx7/pqBfnZ39cArNCHs4SNMwwCyrfAo7F 0HgmrYZ5szRwXBROqInBNUdiNa3U/7FDBiw1NHRkWXEtPgkynO73Jl+NKngzxFb9 M6zkGiKprN4RnetC0JBWJIYq3y4GLew8 =vojG -----END PGP PUBLIC KEY BLOCK----- --SSLID--6786bb2895fc63074c4623ca891c851a;--LOCATION--Earth;

Here I am:

    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: OpenPGP:SDK v0.9

    xsBNBFHYH2QBCAChckyg3kkChkKonezTlhUgeXMVqPP3Pn8W5LJrRsRTWG6VnMa4
    L5lB71dPLKRKZt68ZHTY/s2FC/W6fR32me2pKb1IKZGZlnbrWEIEAtonqgjR9dJo
    VkEEHFe+an2HLbfIxFXFRDKeBCfcP+cnOoehSDvsuopoVy6MKSnjd/OHOiV2k5jC
    tCGQiJN1L1rIq+0S6YyouHUrLCMgMu1PM37vhRhXR0Y3XIgwaCqmtyiiiu3Kck9s
    kvI7E8Tk/3HqscgfwUPg9anT6gHWGrUY3iqIvTFfuNOiW2EuEj4SYxNBLhXgJ+9J
    styxRQMTp2z2G1/9pqEcObBBrURGwdGwImLjABEBAAHNSVN0YXZyb3MgS29yb2tp
    dGhha2lzIChHZW5lcmF0ZWQgYnkgUmV0cm9TaGFyZSkgPHN0YXZyb3NAa29yb2tp
    dGhha2lzLm5ldD7CwF8EEwECABMFAlHYH2QJEK4oESk9rbCrAhkBAAAOcAf+KeGg
    dDVoBYcJbtjIZQr/HbU0cDajv03nbq41n5Kcx+zR8FIIEK7s0bzimqFmfKlZnIlR
    I3Jh+WPTY/k0AKP8BX6ykP2VkzK0zj7St+HB9rHhTjff4ImdAjRz7sL7SDSlyk2V
    YcvnthVPENKF7qMPePC9agU7M8E+xQ76VAcIpL5TE9tDg0BhSBk89aejvNwMWwxO
    fVYc8BT8XrWKe8Y4Ln3qHQl9SoD8ab3jzed7ZhyYxwgFDcEouRlsx4XfcPfWvXTz
    oHbfOHxpYVpp2hpcuiRvgJKde3fwt81WZ+WRN7bHT1u22Ojc/rBNCJ0A4wvGiRJS
    jqophn2OYb5W7Dcp3Q==
    =5kYc
    -----END PGP PUBLIC KEY BLOCK-----
    --SSLID--ad7dd0f6c5b84fe6cabf3ac62bb2618a;--LOCATION--Laptop;
    --LOCAL--192.168.1.102:62835;--EXT--0.0.0.0:0;

add you

Why not simply paste the key into the about field of the personal properties page?

Done! Not that I am really using it (yet?), but I'd love to play with it, especially the forum feature (reminds me of usenet clients, which I never really got to use because that was before my time) - so feel free to "add me" if you're a "casual" yourself, or even if you're super serious about it, but don't mind playful old me.

I added you. Add me too and we can start an HN channel.

Cheers!

Done.

I add my public key to my gravatar image. The page I made to do this is here http://kybernetikos.github.io/VisualSecrecy/

Thanks, I was just looking for something like this!

Obviously it's just a proof of concept, but I think the principle is good. Let me know if you use it.

It looks awesome but they don't seem to have an x64 build for Ubuntu :(

That's the nice thing about browser technology... alleviates the pains cross platform

True. If you can present a browser-based solution with this feature set, no ads, no tracking, and source code available, I'm definitely sold.

That's what we aim for

Similar approach to ShareFest - http://rtccopy.com/

Hi errbysam, We used it to cross-reference and discover this bug in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=842283 star it to get it fixed faster.

Awesome catch, Thanks! upvoted & cc'd

This might be cool in theory, but no way in HELL it's the 'easiest way in the world.' As of right now, only chrome can transfer files to chrome, and firefox to firefox.

As of now, the easiest, best, fastest, and most secure way to transfer files is by using BTSync. (http://labs.bittorrent.com/experiments/sync.html)

Create a shared folder, give out the secret or read only key, done.

You forgot "Install BTSync", which is strictly more work than visiting a webpage.

... and "vaguely understand keys/secrets" which is an additional cognitive burden.

And currently the only means of sharing in a matter that can claim to deliver anything close to anonymity and security.

And you know it's "secure" because it's so open-source, right?

Speaking of which, is there a website where people share what they "sync" with BTSync? There was a website called 12char.com, but it's dead now. Are there alternatives to 12char?

http://reddit.com/r/btsecrets

Thanks!

Recently, I started building a website which does pretty much exactly this. When I had it up and running after a few days (the WebRTC API is relatively simple), I found sharefest and have been using that since.

It's a great way to get files from one place to the other. The (encrypted) data does not go via a server, making this potentially the fastest, most scalable and safest type of file transfer available in a browser. One of the extra perks is that sharing files on a local network becomes really really fast. It's miles ahead

Props to the devs for making this! :)

Thanks!

Waiting for the day RIAA will "demand" that browser vendors, such as Google, Microsoft and Apple especially, stop implementing protocols that "make it easy" to pirate files. And the companies might actually listen. So far Google has fulfilled their every request and then some (hello ContentID, mass DMCA automation tool for links, and SEO punishments!), so it wouldn't surprise me if they did this, too.

I would hope at least Mozilla would not comply with such a request..

There is no right for such a demand as these protocols are just a technology that is not even necessarily related to the sharing of files.

Why can FF and Chrome not share? Is there a major difference in their implementations?

They currently can't interoperate, but it's on their todo's I want to believe Chrome 31 and FF 26 will interoperate

Sharefest was covered at Google I/O's WebRTC pres: https://www.youtube.com/watch?feature=player_detailpage&v=p2...

Yup, thanks it's on the bottom of the webpage.

I've been using http://dropandload.com/ which does something similar. It's cool that this is open source.

I don't think this is p2p, it's server streaming.

Would it be possible to create a sharefest tracker? I.e. A piratebay with no magnet link or torrent file needed. Just a simple download button.

Hmm, isn't that sharefest.me already? you just put the link for a file and bam...you're in a p2p network e.g: http://www.sharefest.me/d09118ed

Won't work for me. I want to send a file, know when it's done and close my computer. With Dropbox and others I know when it's sent from my perspective. With P2P the whole system becomes unstable. And for all of my file sharing, it is unacceptable. Too much uncertainty.

if you're only sending to one recipient we have that feature in (you get file downloaded green message on the top) if you have multi recipient that's a more complex ui problem that we're thinking of... Thanks for the feedback

Thanks for the reply! If I have to think that will I also CC somebody/team/any group before sending it out, then it becomes too complex for me. It's not then the easiest by far since I already have a working solution!

Maybe I'm just not in the target group.

Well I agree that dropbox is easy, but it's also limited. Space for example. Also, if you're sending to a group of co-workers you don't have to upload the entire thing to the cloud. it'll transfer blazingly fast inside the LAN.

storage space and bandwidth are not really limiting factors on today's internet. i have over 100gig of online storage and 25mbps internet, for example. (corrected 1gig to 100gig).

1 gig is nothing (for many people needs). anyway I don't see sharefest as a replacement, but rather another tool.

2 (up to 18) gigs from Dropbox free. Google Drive 15 gig free. For team of 15, Dropbox offers $2000/year for unlimited storage.

Like djim said, storage space and bandwidth are non-issues.

May I suggest trying to get Sharefest popular within a niche? You may have to adapt to that particular niche, but I think it'll help you a lot.

If the files I'm sending would be huge, which for me they never are, and if I'm inside a LAN then I can use a file server for that. It would also be a directory for those files.

I think there's something in your product, but it doesn't have any selling points for me. Even if you make it as good as Dropbox or any other service, I won't change. For that, you need to be better than existing solutions.

Either be better or be different. Generic user facing file sharing - been there, done that.

If anyone has bitdefender installed, it may block websockets from communicating with the server. If you don't receive a url when adding a file, check your websockets status here: http://websocketstest.com/

How about a checkbox for keeping the file in local storage, so when you restart the browser, you can share that file without having to download first? Or is that done already anyway?

I've received a feedback that people want a copy to clipboard button, I'm against it just because there's no way to do it today without flash. what do you guys think?

Can you defer loading the Flash until the user clicks the "copy" button? Or just load one of the tiny Flash shims that are invisible, discussion at http://stackoverflow.com/questions/400212/how-to-copy-to-the...

Some1 has shared this firefox swarm: http://www.sharefest.me/97dc9020

Nice. Here's one for Chrome http://www.sharefest.me/53e62808

Of course we're looking for any feedback that you guys can give for us to improve.

There are a bunch of js error in Firefox Nightly, you might want to update you code :-).

Oh thanks! Our latest tests ran only on FF 22.

The FAQ link goes to the Github bugtracker. Can we have a proper FAQ page, please?

Yes, sorry about that. We surely need one... Check out the live chat in the meantime http://webchat.freenode.net/?channels=sharefest

This. Is. Amazing.

Thanks!

Nice! Didn't know about it before.

works like magic, how did they not think of it till now?

WebRTC was not there to help... It's just recently that DataChannels API hit Chrome and FF. Quite experimental stuff

Hey thanks, It's lately enabled thanks to WebRTC data channel http://www.wertc.org

http://www.webrtc.org

I'll keep using Google Drive.

Sharefest and google drive are made for different purposes. Sharefest is a file sharing/transfer platform. When Drive is, well as its name infers...a drive.

Sharing files is a major feature of Google Drive.

Yes, but it's much more limited by the inherent use of server storage. They, for instance, give 15GB (https://support.google.com/drive/answer/2736257?hl=en) for ALL your files. So you end up thinking, should I share via Drive and waste 10% of my space for this one time sharing.

Plus all the security/privacy issues...

Reply on news.ycombinator.com