
Drop.lol – copy files over the network with WebRTC or TURN relays - pcr910303
https://drop.lol/
======
ignoramous
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
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
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.

~~~
ignoramous
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
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
> 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).

------
anderspitman
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.

------
Fnoord
See also: magic-wormhole [1] (written in Python)

[1] [https://github.com/warner/magic-
wormhole](https://github.com/warner/magic-wormhole)

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

~~~
osrec
Why is this funny to a Dutch person in particular?!

~~~
supakeen
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
The domain licorice.fun is available!

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

------
quickthrower2
This works beautifully. I wonder how secure it is.

~~~
SahAssar
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
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
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.

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

