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.
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!
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).
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.
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
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.
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?
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.
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?
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.
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).
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.
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.
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.
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.
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.
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.
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.
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?
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?
99 comments
[ 2.8 ms ] story [ 190 ms ] threadIf 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/
(It's not just file sharing, though: it aims to address your entire encrypted p2p communication needs.)
It's of course the exact same logic as with encrypted email ("public key encryption" or "asymmetric encryption").
-----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;
Maybe I'm just not in the target group.
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.
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.
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! :)
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.
* 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
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.
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).
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...)
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.
Plus all the security/privacy issues...