[HN Gopher] Show HN: LANDrop - A cross-platform AirDrop-like fil...
___________________________________________________________________
Show HN: LANDrop - A cross-platform AirDrop-like file transfer tool
Author : yvbbrjdr
Score : 223 points
Date : 2021-06-12 04:11 UTC (18 hours ago)
(HTM) web link (landrop.app)
(TXT) w3m dump (landrop.app)
| n3storm wrote:
| Is there a directive, good practice, neuroscience advantage I am
| not aware of in not publishing screenshots or screencapture of
| sofware?
| yvbbrjdr wrote:
| Just lazy and not having the time to do this yet. Making a
| screenshot work with the webpage takes a lot of effort.
| sm4rk0 wrote:
| How does this compare to LanXchange?
|
| https://github.com/tfg13/LanXchange
| rvz wrote:
| LanXchange: Uses Java, no iOS support and I see nothing around
| if there is any use of encryption.
| usui wrote:
| Some good comments on cryptography that I will probably bookmark
| and use to study in the future, but as an end-user, I've been
| hoping for years on a local-network-only solution that basically
| works on all platforms. Functionality-wise, cryptography can
| shape up in time whereas I can use these non-trivial features
| today. Bravo for the privacy-conscious approach and development
| of apps closer to native. I tested it in these directions and
| double checked with sha256sum:
|
| - 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!)
| huhtenberg wrote:
| There's gotta be a rule that requires a "Show HN" poster to
| engage in the comments.
|
| Because a post like this one with ZERO comments from the OP in a
| presence of questions that need answering is plain ridiculous.
| yvbbrjdr wrote:
| Sry! New to HN here. I posted it right before bedtime and
| didn't know a lot of people would be interested :).
| smichel17 wrote:
| It would be more realistic to make it a soft rule: make the
| story downranked on the front page if OP does not engage in the
| comments.
| forgotpwd16 wrote:
| Maybe they posted it to come back a few hours later or even
| tomorrow. The good thing about forums is that they are
| asynchronous.
| bennyp101 wrote:
| Looking at Github, it says they are in CA, so thats 03:59
| currently - maybe they posted it and then fell asleep.
| arkitaip wrote:
| That's like making major code updates on a Friday afternoon
| after a really long and hectic dev cycle.
| arkitaip wrote:
| I don't get the mindset where you finally ship but botch the
| launch marketing. The window of opportunity is so small and
| rarely comes back, that you really need to get the basics
| right, e.g. closely monitor launch posts, answer within
| minutes, be truthful, thank people if they provide useful
| feedback, etc.
| tjohns wrote:
| First off, this looks like a nice project. So please take this as
| constructive criticism:
|
| 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.
| slim wrote:
| Re 3. This is from the repo under control of the author. What
| makes you think that you will be safer if the author submits
| the same apk to the google store?
| mkl wrote:
| Google does some vetting. Also, if the author doesn't get in
| first, someone else could put it in the store, claiming the
| name and making it hard for the author to update.
| yvbbrjdr wrote:
| Thanks for your advice!
|
| 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.
| 627467 wrote:
| I agree with you, the details on the frontpage are enough for
| 99.99% of users, but IMO security is something that people
| rely on "trusted sources" so having somewhere easily
| accessible for these "trusted sources" to learn how it works,
| helps, specially when a project is new.
|
| 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.
| faeyanpiraat wrote:
| App seems to be using this:
| https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...
|
| 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).
| GordonS wrote:
| You could have "state-of-the-art cryptography algorithm" as a
| link to a page with more details. Or just put the name of the
| algorithm in brackets afterwards, e.g. "state-of-the-art
| cryptography algorithm (ChaCha blah AES blah)".
| yvbbrjdr wrote:
| I see. Should've been more concrete about this.
| _1tan wrote:
| libsodium is a solid choice.
| OJFord wrote:
| > App seems to be using this:
| https://libsodium.gitbook.io/doc/secret-
| key_cryptography/aea...
|
| > 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.
| tjohns wrote:
| > 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?
|
| 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.)
| fulafel wrote:
| Glancing at your crypto implementation[1], it seems to contain
| newbie mistakes - eg no public key crypto involved in your public
| keys, usage of low level raw crypto algorithm primitives from
| libsodium without session, replay etc related security concerns,
| no signs of design requiremnts re what security guarantees it's
| trying to provide, no PK key management, etc. You're also hand
| rolling wire protocol code in C++, manipulating raw bytes and
| lengths, which is a receipe for memory safety vulnerabilities.
|
| 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...
| eps wrote:
| If you feel like throwing "newbie" accusations around, it'd be
| prudent to back your list of grievances up with more than a
| single link to crypto.cpp. Chances are you misread the code,
| didn't grok what the op was doing, etc.
|
| 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.
| rvz wrote:
| > 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.
| 4684499 wrote:
| > on an open source project (since the project is
| transparent)
|
| Not as transparent since the mobile apps are closed source
| at the moment.
| dintech wrote:
| I read this as a genuine attempt to assist the developer and
| protect 3rd parties. If that's gate-keeping, we're in trouble
| as a society.
| fulafel wrote:
| Well, it's about 2 screefuls of very simple code. Eg for the
| PK part, if you ctrl-f for publicKey and remotePublicKey, you
| see there are no usages that could plausibly be doing public
| key crypto or PK key generation based on crypto 101 from
| school.
|
| 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?
| [deleted]
| kaetemi wrote:
| Just point out the attack vectors, with some reference on
| solving those.
|
| 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.
| opheliate wrote:
| I'm not sure what you mean by there being no public key
| cryptography here. In the Crypto constructor, a random
| secret key is generated, and then the generator for
| Curve25519 is scalar multiplied on the elliptic curve by
| this secret key to generate a public key. That's the
| standard process for X25519 key generation, and it's what
| Libsodium does to generate a secret key/public key pair
| [1].
|
| 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/7993f5ec5199b
| 6637...
| fulafel wrote:
| I see. I stand corrected - apologies, @yvbbrjdr. Clearly
| my crypto 101 was too long ago! But my other points still
| stand I think.
| yvbbrjdr wrote:
| The reason I "rolled my own" key exchange is that I'd
| want to use the IETF variant of Chacha20-Poly1305 in my
| protocol and there doesn't seem to be helper functions
| for key exchange for this algo.
| opheliate wrote:
| Unless I'm misunderstanding you, the crypto_secretstream
| construction [1] that I (and others) have recommended
| uses ChaCha20Poly1305-IETF as its symmetric cipher. There
| wouldn't be a key exchange for this algorithm, since it's
| symmetric. However, the crypto_kx functions [2] generate
| a 256 bit shared secret, which should work for a
| ChaCha20Poly1305 key I believe?
|
| 1: https://doc.libsodium.org/secret-
| key_cryptography/secretstre...
|
| 2: https://doc.libsodium.org/key_exchange
| yvbbrjdr wrote:
| Probably should have used higher-level functions. Maybe
| next time :). I don't think I can change the protocol and
| break compatibility at this time lol.
|
| 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..
| opheliate wrote:
| Yeahhh, that's a fair point about unnecessary complexity.
| The docs say if only one symmetric key is necessary, you
| can just set one of tx/rx to null, and the other will
| still be the requisite 256 bits, but I appreciate why
| that's a bit ugly.
| yvbbrjdr wrote:
| Will draft a crypto spec if I have time :)
| api wrote:
| Crypto people: "programmers really need to get better at
| using crypto!"
|
| 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.
| _1tan wrote:
| Any pointers to good sources on crypto protocol design?
| api wrote:
| A great starting point to learn about crypto is to first
| study current best practices until you understand _exactly
| why_ they are best practices. Then go through a list of
| vulnerabilities that have been found in flawed algorithms or
| constructions and try to understand how each of these
| vulnerabilities works. Keep digging into these rabbit holes
| until you feel like you have a grasp on what a good
| construction looks like and common pitfalls.
| fulafel wrote:
| https://blog.cryptographyengineering.com/useful-
| cryptography... this link page is from 2012, but still pretty
| good.
| _1tan wrote:
| Thank you
| [deleted]
| api wrote:
| Your comment about manipulating raw bytes in C++ is a language
| criticism, not a criticism of this project.
| mixcocam wrote:
| Just "python -m http.server"
|
| If the network is trusted.
| byteface wrote:
| 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>
| byteface wrote:
| never tried to post code on here. didn't realise it wouldn't
| render.
| grandchild wrote:
| if you want a proper version of that with some handy
| complimentary features, then have a look at
| https://github.com/sebageek/servefile
| sgt wrote:
| Does it work over WiFi direct.. meaning I can send a file to
| someone on Android without them being on the same WiFi network?
| That is the primary reason I find AirDrop so useful.
| yvbbrjdr wrote:
| No :) iOS wouldn't let apps do this.
| rvz wrote:
| Thank goodness for this. A true cross platform alternative to
| AirDrop, Dukto and Dropcopy that _actually_ works everywhere. Not
| a dreadful Electron app and also works on mobile devices as well
| and best of all is open source.
|
| No walled gardens, no subscriptions and no deliberate limitations
| on number of devices.
|
| Well done.
| edwinyzh wrote:
| Very useful! Tried the iPhone and Windows clients and they works!
| forgotpwd16 wrote:
| There're a few such tools, e.g. TrebleShot and NitroShare. Does
| this improve something over the current solutions or is an
| alternative? Also Snapdrop and ShareDrop are two web apps
| offering similar functionality. Good choices in case someone
| doesn't want to install anything.
| yvbbrjdr wrote:
| I've done my research and also found a lot of similar stuff.
| They are all not as convenient as AirDrop, so I wanted to make
| a thing that's close enough.
| jimmydorry wrote:
| Sharing from win10 to iPadOS (14.4.2) was very flakey. Installed
| the app on PC and tablet easily, however win10 couldn't see the
| tablet unless I restarted the app each time.
|
| 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.
| yvbbrjdr wrote:
| It's possible that the iPad failed to bind to the discovery
| port. It should show you a banner when that happens. Did it?
| GekkePrutser wrote:
| Some things I'm missing are:
|
| - 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 :)
| yvbbrjdr wrote:
| - It's mainly me and some friends that does non-code stuff. No
| companies involved at this moment. - No cloud service is used.
| Your app doesn't connect to the Internet. See the privacy
| policy. - :) will post screenshots when I have time.
|
| Will fix the typo!
| GekkePrutser wrote:
| Ah cool, no company involvement makes it much more
| interesting to me. Because sooner or later they'll always
| want to monetise and that has privacy impacts generally.
|
| 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?
| yvbbrjdr wrote:
| It doesn't use the Internet, but it does send broadcasts to
| your local network for discovery.
| maxloh wrote:
| Will the Flutter app be open sourced too?
| yvbbrjdr wrote:
| No :). I might charge the app for like $0.99 in the future.
| chetangoti wrote:
| This looks good.
|
| There is similar tool which web based and opensource
| Snapdrop[0](https://snapdrop.net/) which works on the same
| network.
|
| [0] https://github.com/RobinLinus/snapdrop
| crossroadsguy wrote:
| Having actual apps go a long way. Especially if it's trying to
| be an AirDrop like app and these apps not being electron apps
| is such an added bonus.
| nguyenkien wrote:
| I prefer PWA like snapdrop. All you need is a browser.
| luke2m wrote:
| Easily self hostable as well
| yamrzou wrote:
| Also ShareDrop: https://www.sharedrop.io/
|
| https://github.com/szimek/sharedrop
| dzhiurgis wrote:
| Tried using Sharedrop and it was super slow. Way quicker to
| just upload to wetransfer.
| plibither8 wrote:
| Also FilePizza: https://file.pizza/
|
| https://github.com/kern/filepizza
| jerrygoyal wrote:
| to point out this is different and needs network data to
| upload and download files.
| anaganisk wrote:
| I was never able to make file.pizza work either on lan or
| over the web.
| chkal wrote:
| Same here.
| quenix wrote:
| Ditto, never got it to work.
| edwinyzh wrote:
| Tried snapdrop, but it didn't work. Not sure if it's related to
| the GFW....
| yvbbrjdr wrote:
| Yeah I've also done my research and found a lot of similar
| stuff. The problem with this particular one is it requires
| Internet* to work. I don't feel good about WebRTC and having to
| share my public IP address for such a task.
|
| 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.
| smir wrote:
| looks polished, how this is different from Syncthing? a true
| question, not an argument.
| Shish2k wrote:
| Syncthing requires setup on both ends, and then automatically
| keeps two complete folders in sync across a network (local or
| internet), conceptually similar to a network file system.
|
| 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.
| jacobmischka wrote:
| Looks neat, nice work. I would suggest changing the download
| links to have more affordances that they're clickable, it just
| looked like a table of version numbers to me at first and I
| didn't realize they were links at all.
| yvbbrjdr wrote:
| Great advice. Thanks!
| AM1010101 wrote:
| Just tested out with my iPhone to Ubuntu 20.04. Works nicely with
| photos. Tried to sending some videos (iPhone to Linux) and some
| of them fail. A short 30 second video worked fine but longer 4
| and 8 minute ones failed. Those longer videos may have also been
| stored on iCloud and not locally. Within the iOS app it doesn't
| "select" the longer video files to be able to send them.
|
| Hope this helps. Nice tool and I can see myself using this if
| these issues are sorted.
| yvbbrjdr wrote:
| Thx for your report! Yeah it's a known issue on iOS that it
| takes a long time to process videos.. especially long ones..
| sgt wrote:
| That could be due to having to download from iCloud if the
| video is not present on the device.
| quyleanh wrote:
| Does it support M1 Mac?
| yvbbrjdr wrote:
| Yes! Apart from the desktop version, you can even run the
| mobile app on your M1 Mac.
| jlanger wrote:
| I agree completely with @tjohns first point, if you're calling
| out UX as a top point then you really should have screenshots.
| You should have screenshots anyway.. I dislike having to download
| something just to see what it looks like. Not having screenshots
| just makes the barrier to entry higher.
|
| 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.
| yvbbrjdr wrote:
| Sry about the spelling. Will fix it soon!
| 12ian34 wrote:
| Great effort here. Agree with others re UX and the unsigned APK.
| I currently use Syncthing to fulfil my LAN file transfer needs.
| It's not quite the same but it does have a bunch of other use
| cases which I like, plus it's well-known, well-supported, also
| open, and I trust it.
| yvbbrjdr wrote:
| APK will be signed soon! I just didn't have the bandwidth to
| generate a keypair :).
| api wrote:
| Does this work on ZeroTier? Most LAN things do.
| yvbbrjdr wrote:
| Does ZeroTier support UDP broadcasting? If so it works.
| api wrote:
| Yes, usually so, though on Windows there are issues due to
| Windows TCP stack stupid behaviors around multicast. They're
| not ZeroTier-specific issues.
| 2mia wrote:
| is the passing badge hardcoded fo always green?
|
| - https://github.com/LANDrop/LANDrop/blob/master/README.md -
| https://github.com/LANDrop/LANDrop/workflows/Package/badge.s...
| tenryuu wrote:
| No, it does link to a file in the repo at all. It will change
| based on the outcome of the workflow name specified in the URL.
| https://docs.github.com/en/actions/managing-workflow-runs/ad...
| integricho wrote:
| Thanks for not making another Electron based desktop app. Amazing
| work, congrats!
| taylorfinley wrote:
| First impression, this looks nice! But on Linux dragging a folder
| into the file box doesn't work, that's a pretty simple but
| important feature IMO. Good work!
| yvbbrjdr wrote:
| I'm not sure why it didn't work on your machine.. It works on
| mine..
___________________________________________________________________
(page generated 2021-06-12 23:02 UTC)