ShareFest
June 12, 2013 9:22 AM Subscribe
ShareFest is a "One-To-Many sharing application. Serverless. [It] Eliminates the need to fully upload your file to services such as Dropbox or Google Drive. Put your file and start sharing immediately with anyone that enters the page. Pure javascript-based. No plugins needed thanks to HTML5 WebRTC Data Channel API."
BT Sync is awesome. That's exactly what I've been looking for to answer a very old AskMe.
posted by anotherpanacea at 9:38 AM on June 12, 2013
posted by anotherpanacea at 9:38 AM on June 12, 2013
Received, Philosopher Dirtbike.
posted by chickencoop at 9:43 AM on June 12, 2013
posted by chickencoop at 9:43 AM on June 12, 2013
Neat. Although doing this with Javascript conjures up numerous lines from Lovecraft's works.
Yet I soon subordinated all my fears to my growing curiosity and fascination. Just what Crawford Tillinghast now wished of me I could only guess, but that he had some stupendous secret or discovery to impart, I could not doubt. Before I had protested at his unnatural pryings into the unthinkable; now that he had evidently succeeded to some degree I almost shared his spirit, terrible though the cost of victory appeared. Up through the dark emptiness of the house I followed the bobbing candle in the hand of this shaking parody of man. The electricity seemed to be turned off, and when I asked my guide he said it was for a definite reason.
"It would be too much... I would not dare," he continued to mutter. I especially noted his new habit of muttering, for it was not like him to talk to himself. We entered the laboratory in the attic, and I observed that detestable electrical machine, glowing with a sickly, sinister violet luminosity. It was connected with a powerful chemical battery, but seemed to be receiving no current; for I recalled that in its experimental stage it had sputtered and purred when in action. In reply to my question Tillinghast mumbled that this permanent glow was not electrical in any sense that I could understand.
posted by jeffburdges at 9:44 AM on June 12, 2013 [2 favorites]
Yet I soon subordinated all my fears to my growing curiosity and fascination. Just what Crawford Tillinghast now wished of me I could only guess, but that he had some stupendous secret or discovery to impart, I could not doubt. Before I had protested at his unnatural pryings into the unthinkable; now that he had evidently succeeded to some degree I almost shared his spirit, terrible though the cost of victory appeared. Up through the dark emptiness of the house I followed the bobbing candle in the hand of this shaking parody of man. The electricity seemed to be turned off, and when I asked my guide he said it was for a definite reason.
"It would be too much... I would not dare," he continued to mutter. I especially noted his new habit of muttering, for it was not like him to talk to himself. We entered the laboratory in the attic, and I observed that detestable electrical machine, glowing with a sickly, sinister violet luminosity. It was connected with a powerful chemical battery, but seemed to be receiving no current; for I recalled that in its experimental stage it had sputtered and purred when in action. In reply to my question Tillinghast mumbled that this permanent glow was not electrical in any sense that I could understand.
posted by jeffburdges at 9:44 AM on June 12, 2013 [2 favorites]
Also, their site works through all my cross site script blocking, meaning they've used well behaved Javascript too.
posted by jeffburdges at 9:48 AM on June 12, 2013 [3 favorites]
posted by jeffburdges at 9:48 AM on June 12, 2013 [3 favorites]
testing, 1, 2, 3...
Also, whichever designer decided the wildcard character aka the "assterix" was a good thing to put into logos is either a juvenile genius or an idiot.
posted by ennui.bz at 9:49 AM on June 12, 2013 [1 favorite]
Sorry! Your browser isn't supported yet.apparently Chromium 25.0.1364.160 isn't good enough.
Please use Latest Chrome (26+) or Firefox Nightly (webrtc flag/pref enabled) to try out Sharefest.
Also, whichever designer decided the wildcard character aka the "assterix" was a good thing to put into logos is either a juvenile genius or an idiot.
posted by ennui.bz at 9:49 AM on June 12, 2013 [1 favorite]
One-to-Many?
dont they mean One Too Many?
stop jamming me sorry tom petty
posted by Colonel Panic at 9:57 AM on June 12, 2013 [2 favorites]
dont they mean One Too Many?
stop jamming me sorry tom petty
posted by Colonel Panic at 9:57 AM on June 12, 2013 [2 favorites]
Worked well here - Chrome Version 27.0.1453.110 m. Some add'l info here.
posted by PuppyCat at 9:58 AM on June 12, 2013
posted by PuppyCat at 9:58 AM on June 12, 2013
Worked pretty well on Chrome 29.0.1530.2 but cratered the rev of Aurora I'm on.
posted by vuron at 10:00 AM on June 12, 2013
posted by vuron at 10:00 AM on June 12, 2013
Can anybody explain how this is anonymous? Is it actually truly anonymous for those with agressive ISPs?
posted by Doleful Creature at 10:10 AM on June 12, 2013
posted by Doleful Creature at 10:10 AM on June 12, 2013
I'd expect Google Drive and DropBox associate an email address with your account, possibly credit card information as well. Only your IP address is associated to you ShareFest uploads. Although obviously you expose your Twitter, Reddit, Metafilter, etc. accounts by posting ShareFest links.
ShareFest itself sounds fairly anonymous if you access it through Tor. You could obtain an anonymous DropBox account with exactly the same effort required to obtain an anonymous Twitter account though.
As I see it, transience sounds like ShareFest's main feature, upload your file, share the link privately, and stop sharing once your friends get the file. If your friends keep the link alive and pass it on, that's their problem, not yours. There is no server to archive your file that authorities might investigate once the file peaked their interest, so it's potentially transient or even covert more than anonymous.
posted by jeffburdges at 10:25 AM on June 12, 2013 [1 favorite]
ShareFest itself sounds fairly anonymous if you access it through Tor. You could obtain an anonymous DropBox account with exactly the same effort required to obtain an anonymous Twitter account though.
As I see it, transience sounds like ShareFest's main feature, upload your file, share the link privately, and stop sharing once your friends get the file. If your friends keep the link alive and pass it on, that's their problem, not yours. There is no server to archive your file that authorities might investigate once the file peaked their interest, so it's potentially transient or even covert more than anonymous.
posted by jeffburdges at 10:25 AM on June 12, 2013 [1 favorite]
This looks really sweet. I have to send gigs of RAW photos or video all the time for work, and every solution I've tried so far takes fucking forever and is a pain in the ass (our IT guy is also our design guy, so he hasn't had time to set up a dedicated FTP server or anything, and even then, we can't explain that to our bosses because they're kinda tech naifs). If this is reasonably fast, I will use it all the time.
posted by klangklangston at 10:36 AM on June 12, 2013
posted by klangklangston at 10:36 AM on June 12, 2013
(I may have been the only person to ever earn rapidshare/megaupload perks through legal uploading.)
posted by klangklangston at 10:37 AM on June 12, 2013 [1 favorite]
posted by klangklangston at 10:37 AM on June 12, 2013 [1 favorite]
This is too fast and loose - I suspect there will be issues.
I clicked on the testing URL above - and it instantly downloaded the png. I didn't even get a chance to view whether I wanted it or not.
There would be very little difficulty in writing a script that uploaded a million trojans to this site.
> peaked their interest
It's "piqued". Sorry, a word I love that's getting glommed into another perfectly good word, "peaked".
posted by lupus_yonderboy at 10:47 AM on June 12, 2013 [2 favorites]
I clicked on the testing URL above - and it instantly downloaded the png. I didn't even get a chance to view whether I wanted it or not.
There would be very little difficulty in writing a script that uploaded a million trojans to this site.
> peaked their interest
It's "piqued". Sorry, a word I love that's getting glommed into another perfectly good word, "peaked".
posted by lupus_yonderboy at 10:47 AM on June 12, 2013 [2 favorites]
Is it actually truly anonymous for those with agressive ISPs?
It appears that "Encryption is mandatory for all WebRTC components," which is what ShareFest uses to communicate with you and you use to communicate with other users. So when Philosopher Dirtbike uploaded a file and you downloaded it, a hypothetical third party who was reading all of our internet traffic would see:
(1) A given IP address (P.D.'s) goes to the ShareFest site and sends an encrypted blob of data which could be inferred to be sharing a new file.
(2) ShareFest sends back a blob of data that could be inferred to be the access key for the file. At this point the third party doesn't know the access key or anything about the file.
Now on some other channel (Metafilter), P.D. gives you the access key, which looks like "http://www.sharefest.me/966af07a" .
(3) Your IP tells ShareFest that you want to retrieve the file with that access key. Because this is an "http" instead of "https" url, the third party now knows the access key too. (If it's examining packet contents.)
(4) ShareFest sends back an encrypted blob of data telling you IPs to retrieve the file from.
(5) Encrypted channels open between your IP address and other IP addresses (possibly including P.D.'s -- depends how many people are sharing the file), and you receive a certain amount of data representing the file, possibly mixed in and indistinguishable from any incoming blobs of data for other files you're simultaneously downloading.
Once everyone stops sharing the file, the key becomes useless. So the way the system currently works, the only thing that is publicly exposed is that you are using the service, how much you are downloading, and -- when you retrieve a file -- what the file key is. That would allow an ISP to throttle your overall use of the service (which wouldn't be surprising), and to determine what the file is called by inspecting your packets and starting a download themselves while it's still being shared (which would be very surprising).
Incidentally, the only reason a third party could figure out the key, which is the main weakness of the system, is because ShareFest doesn't use SSL. I wonder why not.
posted by jhc at 10:49 AM on June 12, 2013 [3 favorites]
It appears that "Encryption is mandatory for all WebRTC components," which is what ShareFest uses to communicate with you and you use to communicate with other users. So when Philosopher Dirtbike uploaded a file and you downloaded it, a hypothetical third party who was reading all of our internet traffic would see:
(1) A given IP address (P.D.'s) goes to the ShareFest site and sends an encrypted blob of data which could be inferred to be sharing a new file.
(2) ShareFest sends back a blob of data that could be inferred to be the access key for the file. At this point the third party doesn't know the access key or anything about the file.
Now on some other channel (Metafilter), P.D. gives you the access key, which looks like "http://www.sharefest.me/966af07a" .
(3) Your IP tells ShareFest that you want to retrieve the file with that access key. Because this is an "http" instead of "https" url, the third party now knows the access key too. (If it's examining packet contents.)
(4) ShareFest sends back an encrypted blob of data telling you IPs to retrieve the file from.
(5) Encrypted channels open between your IP address and other IP addresses (possibly including P.D.'s -- depends how many people are sharing the file), and you receive a certain amount of data representing the file, possibly mixed in and indistinguishable from any incoming blobs of data for other files you're simultaneously downloading.
Once everyone stops sharing the file, the key becomes useless. So the way the system currently works, the only thing that is publicly exposed is that you are using the service, how much you are downloading, and -- when you retrieve a file -- what the file key is. That would allow an ISP to throttle your overall use of the service (which wouldn't be surprising), and to determine what the file is called by inspecting your packets and starting a download themselves while it's still being shared (which would be very surprising).
Incidentally, the only reason a third party could figure out the key, which is the main weakness of the system, is because ShareFest doesn't use SSL. I wonder why not.
posted by jhc at 10:49 AM on June 12, 2013 [3 favorites]
I clicked on the testing URL above - and it instantly downloaded the png. I didn't even get a chance to view whether I wanted it or not.
Yeah. This thing is cool, but very badly behaved at the moment.
posted by invitapriore at 10:56 AM on June 12, 2013 [1 favorite]
Yeah. This thing is cool, but very badly behaved at the moment.
posted by invitapriore at 10:56 AM on June 12, 2013 [1 favorite]
Pure javascript-based.
I like this. I wrote a secure file storage and -sending app/website, where all the encryption is done on the client side in Javascript. It works across all modern browsers, but the 2xxx-bit RSA encryption is punishingly slow on everything except Chrome (and Chromium, maybe?)
Other than that, it just turns your browser window into a file-explorer screen; you can drag-n-drop files and do all that other stuff. Client-side key selection and encryption. Not possible to recover plaintext even if all server-side data is compromised.
I give accounts to my clients for long-term storage of their sensitive docs. The system works as an irrevocable document give-away: once I send/upload to a client, I can't ever see, change or delete it.
posted by spacewrench at 11:13 AM on June 12, 2013
I like this. I wrote a secure file storage and -sending app/website, where all the encryption is done on the client side in Javascript. It works across all modern browsers, but the 2xxx-bit RSA encryption is punishingly slow on everything except Chrome (and Chromium, maybe?)
Other than that, it just turns your browser window into a file-explorer screen; you can drag-n-drop files and do all that other stuff. Client-side key selection and encryption. Not possible to recover plaintext even if all server-side data is compromised.
I give accounts to my clients for long-term storage of their sensitive docs. The system works as an irrevocable document give-away: once I send/upload to a client, I can't ever see, change or delete it.
posted by spacewrench at 11:13 AM on June 12, 2013
There would be very little difficulty in writing a script that uploaded a million trojans to this site.
and
Yeah. This thing is cool, but very badly behaved at the moment.
Don't think of it as a link to a landing page, think of it as a link to a file. There's nothing wrong with saying "hey, click this link to download this thing." HTTP supports that (with a header like "Content-Disposition: Attachment;filename=foo") because it's a convenient thing to be able to do. It's up to you, your browser, and your operating system to decide whether to save the file, run it, delete it, or whatever. For example, my browser would automatically download a .gif, but would ask me about an .exe. If you want to you can set your browser to ask you about everything.
So yeah, don't go to an untrusted ShareFest file url, let a program download and run it. This is also true of any other untrusted download link, email attachment, etc. To the extent this is a slightly easier way to share malicious programs, that's because there's less oversight than sharing via Dropbox or whatever -- it's an unavoidable aspect of convenient, decentralized file sharing.
posted by jhc at 11:17 AM on June 12, 2013 [2 favorites]
and
Yeah. This thing is cool, but very badly behaved at the moment.
Don't think of it as a link to a landing page, think of it as a link to a file. There's nothing wrong with saying "hey, click this link to download this thing." HTTP supports that (with a header like "Content-Disposition: Attachment;filename=foo") because it's a convenient thing to be able to do. It's up to you, your browser, and your operating system to decide whether to save the file, run it, delete it, or whatever. For example, my browser would automatically download a .gif, but would ask me about an .exe. If you want to you can set your browser to ask you about everything.
So yeah, don't go to an untrusted ShareFest file url, let a program download and run it. This is also true of any other untrusted download link, email attachment, etc. To the extent this is a slightly easier way to share malicious programs, that's because there's less oversight than sharing via Dropbox or whatever -- it's an unavoidable aspect of convenient, decentralized file sharing.
posted by jhc at 11:17 AM on June 12, 2013 [2 favorites]
> Any site can prompt your browser to start a file download instead of in-line display.
Sure, but that doesn't mean it's not a bad feature.
> It's up to you, your browser, and your operating system to decide whether to save the file, run it, delete it, or whatever.
The argument that internet users are responsible and informed adults who will make intelligent choice about how to respond when faced with a decision is not a convincing one.
If I were writing malware of some type, I'd be looking for the site that had the fewest actions between "receiving my phishing email" and "my trojan running" - and this one is it.
posted by lupus_yonderboy at 11:41 AM on June 12, 2013
Sure, but that doesn't mean it's not a bad feature.
> It's up to you, your browser, and your operating system to decide whether to save the file, run it, delete it, or whatever.
The argument that internet users are responsible and informed adults who will make intelligent choice about how to respond when faced with a decision is not a convincing one.
If I were writing malware of some type, I'd be looking for the site that had the fewest actions between "receiving my phishing email" and "my trojan running" - and this one is it.
posted by lupus_yonderboy at 11:41 AM on June 12, 2013
Am I the only one who looks at the logo and sees that asterisk and reads the name as "Shartfest"?
I will actually play with this when I am not behind a crazy firewall for work, but in the meantime I am 10 years old
posted by sparklemotion at 11:44 AM on June 12, 2013 [2 favorites]
I will actually play with this when I am not behind a crazy firewall for work, but in the meantime I am 10 years old
posted by sparklemotion at 11:44 AM on June 12, 2013 [2 favorites]
Javascript Cryptography Considered Harmful
Doing crypto with Javascript, as currently implemented by most browsers, is a very bad idea and opens up a number of novel avenues for attack.
There is basically never a good reason to perform client side cryptography using JS. If you need to do client-side crypto in Javascript, it's presumably because you need to set up a secure channel ... meaning you don't already have a secure channel. Which means an attacker can pretty trivially intercept the JS code and suborn it.
You can always deploy the JS over SSL/TLS or something like that, but then you've set up a secure channel (using the well-tested crypto code built into your browser or OS) and shouldn't need the Javascript-crypto layer.
It seems tempting to implement client-side crypto to solve apparent problems like "how do I upload a file to this website and not let the site operator read it?" ... the obvious, and bad, solution is to use SSL to some JS which encrypts the file on the client side and then uploads it without the key. But this gives the user an almost entirely false sense of security. If they can't trust the site operator with the file, why are they trusting the site operator to provide them with the Javascript to encrypt it (and which could introduce a backdoor)? They shouldn't be. If you can't trust a party with the key, you can't trust them to deliver the encryption code to you without buggering it along the way to suit their evil ends (presumably the same ones that cause you to not trust them with the key). About the only thing it gives you is some protection of the data at-rest on the far end against a third party who grabs a snapshot of the database but doesn't actively operate the site in a hostile way... and you can get that in other ways, more easily, if you trust the site operator.
There is no easy way around what Matasano calls it the "chicken and egg problem" when you are delivering the cryptographic code over the wire. What you have to do instead is use established, trusted encryption libraries that already exist on the user's computer ... e.g. what SSL/TLS does.
What browsers probably ought to do is offer APIs for symmetric file encryption, rather than asymmetric transit encryption ... for all I know this might already be the case, and I just haven't seen anything that takes advantage of it. I think there are still some implementation issues you'd have to work out if you allowed JS to use this API (how would you make sure the JS wasn't storing the key and immediately decrypting the file afterwards or doing something else sinister?) but they are more tractable than the inherent problems of client-side encryption using code sent by the remote end.
posted by Kadin2048 at 5:25 PM on June 12, 2013 [5 favorites]
Doing crypto with Javascript, as currently implemented by most browsers, is a very bad idea and opens up a number of novel avenues for attack.
There is basically never a good reason to perform client side cryptography using JS. If you need to do client-side crypto in Javascript, it's presumably because you need to set up a secure channel ... meaning you don't already have a secure channel. Which means an attacker can pretty trivially intercept the JS code and suborn it.
You can always deploy the JS over SSL/TLS or something like that, but then you've set up a secure channel (using the well-tested crypto code built into your browser or OS) and shouldn't need the Javascript-crypto layer.
It seems tempting to implement client-side crypto to solve apparent problems like "how do I upload a file to this website and not let the site operator read it?" ... the obvious, and bad, solution is to use SSL to some JS which encrypts the file on the client side and then uploads it without the key. But this gives the user an almost entirely false sense of security. If they can't trust the site operator with the file, why are they trusting the site operator to provide them with the Javascript to encrypt it (and which could introduce a backdoor)? They shouldn't be. If you can't trust a party with the key, you can't trust them to deliver the encryption code to you without buggering it along the way to suit their evil ends (presumably the same ones that cause you to not trust them with the key). About the only thing it gives you is some protection of the data at-rest on the far end against a third party who grabs a snapshot of the database but doesn't actively operate the site in a hostile way... and you can get that in other ways, more easily, if you trust the site operator.
There is no easy way around what Matasano calls it the "chicken and egg problem" when you are delivering the cryptographic code over the wire. What you have to do instead is use established, trusted encryption libraries that already exist on the user's computer ... e.g. what SSL/TLS does.
What browsers probably ought to do is offer APIs for symmetric file encryption, rather than asymmetric transit encryption ... for all I know this might already be the case, and I just haven't seen anything that takes advantage of it. I think there are still some implementation issues you'd have to work out if you allowed JS to use this API (how would you make sure the JS wasn't storing the key and immediately decrypting the file afterwards or doing something else sinister?) but they are more tractable than the inherent problems of client-side encryption using code sent by the remote end.
posted by Kadin2048 at 5:25 PM on June 12, 2013 [5 favorites]
> Javascript Cryptography Considered Harmful
In what sense is WebRTC doing "Javascript cryptography"?
posted by pw201 at 2:12 AM on June 13, 2013
In what sense is WebRTC doing "Javascript cryptography"?
posted by pw201 at 2:12 AM on June 13, 2013
« Older "aboriginal landscapes of fabulous hybrid... | Before there was a [US] national museum, we had a... Newer »
This thread has been archived and is closed to new comments
... and to add some substance to this comment, i also mention BitTorrent Sync.
posted by mrgrimm at 9:24 AM on June 12, 2013 [4 favorites]