Show HN: LANDrop – A cross-platform AirDrop-like file transfer tool
landrop.app
landrop.app
1. This really should have screenshots published. Especially when comparing with something polished like AirDrop, the UX is important. You even call this out as one of the features, so it's really odd not seeing the screenshots to support that statement.
2. "Uses state-of-the-art cryptography algorithm" isn't very reassuring. It would be nice to know what standards your using, maybe some details about the underlying protocol.
3. For Android, please consider publishing in Google Play or other stores. I'm not going to enable "untrusted sources" and install a random APK off the Internet.
I have little experience with cryptography, and have no idea whether it is a good choice or not.
If it is, how would you convince regular people that the state of the art “something something sodium chachacha” crypto algorithm in the app is the best for them?
It might be better not to mention the name.
Some stats would be nice, like: your files would take X years to decrypt if stolen (backed by some trusted sources).
Personally, I'd make a separate page with more details for the subset of folks who are interested. It doesn't need to be on the main page, but at least something to reassure technical users that the project hasn't rolled it's own DIY crypto would help. :)
(And yes, libsodium is a great choice.)
> I have little experience with cryptography, and have no idea whether it is a good choice or not.
libsodium is from DJB & Tanja Lange, it doesn't get better/more trusted than that without preferring to trust some state entity of choice. (For some reason ranging from regulatory requirement to hopelessly misguided.)
https://en.m.wikipedia.org/wiki/Daniel_J._Bernstein#Cryptogr...
But yeah, average user doesn't care. It probably doesn't belong on the front page unless this intends only to target a security conscious audience.
1. Yeah. I should have had screenshots on my webpage :). 2. It's Chacha20-Poly1305-IETF. I haven't have time to document the protocol, so if anyone wants to see it, they need to read the code :). 3. Yeah, that's also in the plan.
My point is that average people might not care about the exact algo being used. They might not even care that it's actually encrypted, so there is no need to specify it in the homepage. The only point of documenting this might be just for devs or people who wouldn't use before they know how it works.
After a while people just "know" that signal is secure not because they know how it works but because they heard enough "trusted sources" describe signal as such.
Use an pre vetted implementation of a good security protocol for this, or if this is a hobby project, spend some time reading up on crypto protocol design.
[1] https://github.com/LANDrop/LANDrop/blob/master/LANDrop/crypt...
As it stands your comment reads like a common variety abrasive and dismissive gatekeeping... rant, basically, which is unfortunately so popular in crypto circles.
Edit - the project does dearly need a crypto spec. "Uses state-of-the-art cryptography algorithm" claim begs to be described to be valid.
It does not need a spec. It just needs to put a small print on "algorithm" and mention that it is using a cryptography library called libsodium. That's it.
As for the armchair field marshal cryptographers ranting around and nitpicking "useful projects", they are the same ones who praised Signal for their actual "state-of-the-art cryptography algorithm" for end-to-end encryption until they added a cryptocurrency coin in the messenger. Same with Keybase.
At least this project does not have such frivolous features and is only using libsodium like everyone else.
It is very easy to give "expert" criticism (constructive or not) on an open source project (since the project is transparent) but it is much harder for the critics to dive in and fix the aforementioned issues themselves. I would have much more respect for those who do both.
Not as transparent since the mobile apps are closed source at the moment.
Not sure how to respond about gatekeeping. What do you think would be a good way to write a comment pointing out these kinds of security problems? Or do you think it's unfair to do it at all?
To establish a shared secret session key, the standard ECDH procedure is used, as seen in Crypto::setRemotePublicKey, where we multiply the other party’s public key by our secret key on curve25519 to establish a shared secret. This shared secret is then used for encryption, since symmetric encryption is generally cheaper + more secure than asymmetric.
I absolutely agree that this project needs a more formal cryptographic approach, and should be using a higher level construct (e.g: crypto_secretstream, also from libsodium), but as far as I can tell at first glance, this is a working implementation of X25519.
1: https://github.com/jedisct1/libsodium/blob/7993f5ec5199b6637...
1: https://doc.libsodium.org/secret-key_cryptography/secretstre...
The crypto_kx functions seem to generate 2 symmetric keys for 2 directions. That creates complications in the code and that's why I didn't use it initially..
No need to "you're implementing things yourself. bad. use someone else's library". That is gatekeeping indeed, and a rather insulting way to express your concerns.
If you simply demonstrate the complexity of dealing with all security concerns, they'll realize what they need. Prepackaged "always do this" does not teach well.
Also crypto people: “how DARE ye mere mortal even touch crypto!!!”
This doesn’t help. The only people who will listen to “don’t roll your own crypto” are the very people who ought to be learning how to do it. The arrogant types who should never touch crypto will ignore this advice and still write bad crypto.
The most effective thing would be to just tell programmers why crypto is hard in ways other code is not.
Crypto is hard because you can’t simply unit test for vulnerabilities. “Anyone can write a crypto system they themselves can’t break.”
For the majority of code it’s good code if it works and is fast and lacks things like memory safety bugs.
For crypto it can work perfectly and still be grossly insecure. The only way to tell is to deeply understand cryptanalysis and do academic mathy stuff.
As a result if you use crypto it’s best to write boring conservative crypto and use it the way pro cryptographers suggest. Try to use a peer reviewed library or if you can’t and must implement then try to ape a peer reviewed library exactly.
Don’t even try to invent new stuff in crypto unless your understanding is very thorough and don’t use anything new without peer review.
Edit: another example of abnormally hard code is distributed databases. They can be unit tested but adequately doing so is extremely difficult. It’s easy to write one that seems to work but loses data at scale or under edge case failure scenarios. Crypto is even worse.
There is similar tool which web based and opensource Snapdrop[0](https://snapdrop.net/) which works on the same network.
Also, it requires you to open a webpage every time you use it. I'd really like the user experience of AirDrop that you need to do nothing to receive files. So I made LANDrop a daemon-like stuff.
* It has a mode that you can save the page offline, but that doesn't work with iOS.
Second point, you really need to make sure spelling is correct (i.e. "celluar" should be "cellular"), that degrades the perceived quality of the product. If I see spelling mistakes on the landing page then I assume there might be other kinds of mistakes... like in the codebase for instance.
- https://github.com/LANDrop/LANDrop/blob/master/README.md - https://github.com/LANDrop/LANDrop/workflows/Package/badge.s...
No walled gardens, no subscriptions and no deliberate limitations on number of devices.
Well done.
- Mac <==> Mac (Wireless)
- Mac <==> Mac (Thunderbolt 4 Bridge)
- Mac <==> Android
- Mac <==> iOS
- iOS <==> Android
Features I'd have interest in:
- Choose interface/IP address to listen on by default instead of all interfaces (can still be first-time default). This helps prevent accidentally sending over a not fully-trusted network. I imagine that with the next iPad supporting Thunderbolt 4, it could be easy to send over wire. This also helps smoothen someone's lack of confidence in the network security of the app. You also probably already thought of this since there is an "Advanced" section which currently supports changing the port
- Have some way to verify the target's IP address for the Flutter app on iOS and Android prior to sending
- A command-line interface to automate sending and receiving
- A way to donate if you're open to that
(@yvbbrjdr go bears!)
Hope this helps. Nice tool and I can see myself using this if these issues are sorted.
After understanding the workflow, sending files was pretty slick, but janky.
I suspect the iPadOS app is only announcing when it opens for the first time.
Because a post like this one with ZERO comments from the OP in a presence of questions that need answering is plain ridiculous.
If the network is trusted.
import os
from flask import Flask, request, render_template, redirect
import requests
import shutil
app = Flask(__name__)
@app.route('/handle_form', methods=['POST'])
def handle_form():
f = request.files['file']
f.save(os.getcwd()+'/files/'+f.filename)
return redirect("/", 302);
@app.route("/")
def index():
return render_template("index.html");
if __name__ == "__main__":
app.run(host='0.0.0.0', port=8080, debug=True)
# <!-- index.html -->
# <!DOCTYPE html>
# <html>
# <head>
# <title>Send File</title>
# </head>
# <body>
# <h1>Send File</h1>
# <form action="handle_form" method="post" enctype="multipart/form-data">
# <input type="file" name="file">
# <input type="submit" value="Upload">
# </form>
# </body>
# </html>This only requires having the app installed on both ends, and then manually send & receive individual files on-demand (over the local network). It’s more on the level of peer-to-peer instant-messaging.
- Who is behind this? A company or is it completely free?
- Is there any cloud service used?
- What does the UI look like?
And please fix the "celluar" spelling mistakes (in different places), it just makes it look less professional :)
Will fix the typo!
I missed the internet part, sorry! It doesn't say so explicitly, just that the info is not collected. But how do the peers find each other then?