6 ms·

Drop.lol – copy files over the network with WebRTC or TURN relays

129 points by pcr910303 7y ago

quickthrower2 7y ago
This works beautifully. I wonder how secure it is.
- SahAssar 7y ago
  WebRTC is end-to-end encrypted, but the handshake goes over the server in cleartext. So you need to trust the server, but not the TURN relays.
  - vincentchu 7y ago
    I made a similar version awhile back: https://qqsend.me https://qqsend.me It uses AES encryption to encrypt the contents of the data so that any TURN relays couldn't see the contents of what was being transferred. The key material between sender/recipient are transferred via the hash-param of the URL, which AFAIK isn't sent to the server and is hidden.
    - SahAssar 7y ago
      The data going over TURN is always encrypted in WebRTC, so relays can never see what you send (at least in all normal implementations). The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something. Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust). If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files. Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
  - dbrgn 7y ago
    The handshake could be encrypted with something like https://saltyrtc.org https://saltyrtc.org.
    - SahAssar 7y ago
      I might not just understand the cryptography here, but how does that protect against the server or a third party with access to the handshake to act as a relaying party (basically doing a MITM attack)? Does it actually not need to trust the server or have any preexisting trust in the other party?
ignoramous 7y ago
See https://instant.io https://instant.io [0] for a similar file sharing service, but over BitTorrent over WebRTC (not sure if it requires a relay TURN server when peers are behind symmetric NAT) [1][2]. Other such services shared on news.yc previously: https://sharedrop.net https://sharedrop.net, https://file.pizza https://file.pizza, wormhole et al [3][4]. Just a reminder that, WebRTC doesn't leak your public-IP if you're behind a VPN [5]. --- [0] https://news.ycombinator.com/item?id=9568939 https://news.ycombinator.com/item?id=9568939 [1] https://news.ycombinator.com/item?id=19603947 https://news.ycombinator.com/item?id=19603947 [2] https://tools.ietf.org/html/rfc8445 https://tools.ietf.org/html/rfc8445 [3] https://news.ycombinator.com/item?id=17356023 https://news.ycombinator.com/item?id=17356023 [4] https://news.ycombinator.com/item?id=14649727 https://news.ycombinator.com/item?id=14649727 [5] https://news.ycombinator.com/item?id=12527956 https://news.ycombinator.com/item?id=12527956
- amelius 7y ago
  Cool, but none of these services seem to be operational at the moment. (Which is somewhat strange given that they are supposed to be run mostly in the browser.)
  - untog 7y ago
    I’ve had great success with Sharedrop, but it’s at https://sharedrop.io https://sharedrop.io, not .net as the OP linked. One reasons services might have shut down is running the TURN server. An added annoyance over what would otherwise just be static files.
    - amelius 7y ago
      Ok thanks, I'll check out Sharedrop. Regarding the TURN server, is that something that is specific to the service? It seems to me that a more general approach would be preferable, i.e. not connected to any particular service. Also, I'm wondering how IPFS is doing these days.
    - ignoramous 7y ago
      My bad. The mirror is at https://snapdrop.net https://snapdrop.net [0]. [0] https://news.ycombinator.com/item?id=21439659 https://news.ycombinator.com/item?id=21439659
lebaux 7y ago
As much as I'm a fan of these FOSS WebRTC solutions, nothing quite worked for me reliably in a room of people with a variety of devices and technical knowledge. I use https://fileroom.io/about https://fileroom.io/about but it is not FOSS, it does use their own servers for storage (you have to believe they delete the files) and the project looks dead overall. But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Also, users should be able to asign a name?
- XaspR8d 7y ago
  > But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Which is funny, isn't using a standard <input type="file"> much more straightforward than actually accepting a drag and drop? FWIW I've been seeing this pattern all over the place lately, where drag-and-drop is so emphasized that the click-to-browse option is hidden (or entirely missing).
eterps 7y ago
As a Dutch person this domain name made me laugh. Nice tool though.
- theraido 7y ago
  Was looking for this comment ;)
- osrec 7y ago
  Why is this funny to a Dutch person in particular?!
  - jtr1 7y ago
    It means drool
  - himlion 7y ago
    Drop is our national licorice candy, and lol means fun (not just as the acronym).
  - supakeen 7y ago
    It's a few things, drop is the word for licorice and lol is the word for fun. It's also one letter off 'droplul' which would be a swear word for asshole, literally: licorice dick.
    - mc3 7y ago
      The domain licorice.fun is available!
Fnoord 7y ago
See also: magic-wormhole [1] (written in Python) [1] https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole
mathfailure 7y ago
Doesn't work for me. Tried Chromium (Linux) -> Chromium (Android) - fails. Tried Firefox (windows) -> Chromium (Linux) - fails.
kirstenbirgit 7y ago
Love these sorts of tools that don't require login or registration, and are usable immediately! Great job.
anderspitman 7y ago
If you're on the CLI and need to quickly get a file from one machine to another, check out my https://patchbay.pub https://patchbay.pub service. There are now a couple open source implementations that can handle the file sharing case.

129 points by pcr910303 7y ago

quickthrower2 7y ago

This works beautifully. I wonder how secure it is.

SahAssar 7y ago
WebRTC is end-to-end encrypted, but the handshake goes over the server in cleartext. So you need to trust the server, but not the TURN relays.
- vincentchu 7y ago
  I made a similar version awhile back: https://qqsend.me https://qqsend.me It uses AES encryption to encrypt the contents of the data so that any TURN relays couldn't see the contents of what was being transferred. The key material between sender/recipient are transferred via the hash-param of the URL, which AFAIK isn't sent to the server and is hidden.
  - SahAssar 7y ago
    The data going over TURN is always encrypted in WebRTC, so relays can never see what you send (at least in all normal implementations). The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something. Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust). If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files. Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
- dbrgn 7y ago
  The handshake could be encrypted with something like https://saltyrtc.org https://saltyrtc.org.
  - SahAssar 7y ago
    I might not just understand the cryptography here, but how does that protect against the server or a third party with access to the handshake to act as a relaying party (basically doing a MITM attack)? Does it actually not need to trust the server or have any preexisting trust in the other party?

ignoramous 7y ago

See https://instant.io https://instant.io [0] for a similar file sharing service, but over BitTorrent over WebRTC (not sure if it requires a relay TURN server when peers are behind symmetric NAT) [1][2]. Other such services shared on news.yc previously: https://sharedrop.net https://sharedrop.net, https://file.pizza https://file.pizza, wormhole et al [3][4]. Just a reminder that, WebRTC doesn't leak your public-IP if you're behind a VPN [5]. --- [0] https://news.ycombinator.com/item?id=9568939 https://news.ycombinator.com/item?id=9568939 [1] https://news.ycombinator.com/item?id=19603947 https://news.ycombinator.com/item?id=19603947 [2] https://tools.ietf.org/html/rfc8445 https://tools.ietf.org/html/rfc8445 [3] https://news.ycombinator.com/item?id=17356023 https://news.ycombinator.com/item?id=17356023 [4] https://news.ycombinator.com/item?id=14649727 https://news.ycombinator.com/item?id=14649727 [5] https://news.ycombinator.com/item?id=12527956 https://news.ycombinator.com/item?id=12527956

amelius 7y ago
Cool, but none of these services seem to be operational at the moment. (Which is somewhat strange given that they are supposed to be run mostly in the browser.)
- untog 7y ago
  I’ve had great success with Sharedrop, but it’s at https://sharedrop.io https://sharedrop.io, not .net as the OP linked. One reasons services might have shut down is running the TURN server. An added annoyance over what would otherwise just be static files.
  - amelius 7y ago
    Ok thanks, I'll check out Sharedrop. Regarding the TURN server, is that something that is specific to the service? It seems to me that a more general approach would be preferable, i.e. not connected to any particular service. Also, I'm wondering how IPFS is doing these days.
  - ignoramous 7y ago
    My bad. The mirror is at https://snapdrop.net https://snapdrop.net [0]. [0] https://news.ycombinator.com/item?id=21439659 https://news.ycombinator.com/item?id=21439659

lebaux 7y ago

As much as I'm a fan of these FOSS WebRTC solutions, nothing quite worked for me reliably in a room of people with a variety of devices and technical knowledge. I use https://fileroom.io/about https://fileroom.io/about but it is not FOSS, it does use their own servers for storage (you have to believe they delete the files) and the project looks dead overall. But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Also, users should be able to asign a name?

XaspR8d 7y ago
> But this drop.lol thing does not allow "click to browse" and that is rather cumbersome on mobile. Which is funny, isn't using a standard <input type="file"> much more straightforward than actually accepting a drag and drop? FWIW I've been seeing this pattern all over the place lately, where drag-and-drop is so emphasized that the click-to-browse option is hidden (or entirely missing).

eterps 7y ago

As a Dutch person this domain name made me laugh. Nice tool though.

theraido 7y ago
Was looking for this comment ;)
osrec 7y ago
Why is this funny to a Dutch person in particular?!
- jtr1 7y ago
  It means drool
- himlion 7y ago
  Drop is our national licorice candy, and lol means fun (not just as the acronym).
- supakeen 7y ago
  It's a few things, drop is the word for licorice and lol is the word for fun. It's also one letter off 'droplul' which would be a swear word for asshole, literally: licorice dick.
  - mc3 7y ago
    The domain licorice.fun is available!

Fnoord 7y ago

See also: magic-wormhole [1] (written in Python) [1] https://github.com/warner/magic-wormhole https://github.com/warner/magic-wormhole

mathfailure 7y ago

Doesn't work for me. Tried Chromium (Linux) -> Chromium (Android) - fails. Tried Firefox (windows) -> Chromium (Linux) - fails.

kirstenbirgit 7y ago

Love these sorts of tools that don't require login or registration, and are usable immediately! Great job.

anderspitman 7y ago

If you're on the CLI and need to quickly get a file from one machine to another, check out my https://patchbay.pub https://patchbay.pub service. There are now a couple open source implementations that can handle the file sharing case.