Show HN: LANDrop – A cross-platform AirDrop-like file transfer tool(landrop.app)
landrop.app
Show HN: LANDrop – A cross-platform AirDrop-like file transfer tool
https://landrop.app/
100 comments
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.
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.
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.
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.
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).
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).
> 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.
> 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.
> 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.)
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.)
libsodium is a solid choice.
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?
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.
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...
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...
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.
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.
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.
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.
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?
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?
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/7993f5ec5199b6637...
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...
I see. I stand corrected - apologies, @yvbbrjdr. Clearly my crypto 101 was too long ago! But my other points still stand I think.
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.
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
1: https://doc.libsodium.org/secret-key_cryptography/secretstre...
2: https://doc.libsodium.org/key_exchange
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..
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..
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.
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.
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.
[deleted]
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.
Will draft a crypto spec if I have time :)
> 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.
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.
> on an open source project (since the project is transparent)
Not as transparent since the mobile apps are closed source at the moment.
Not as transparent since the mobile apps are closed source at the moment.
[deleted]
Your comment about manipulating raw bytes in C++ is a language criticism, not a criticism of this project.
Any pointers to good sources on crypto protocol design?
https://blog.cryptographyengineering.com/useful-cryptography... this link page is from 2012, but still pretty good.
Thank you
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.
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
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
Also ShareDrop: https://www.sharedrop.io/
https://github.com/szimek/sharedrop
https://github.com/szimek/sharedrop
Also FilePizza: https://file.pizza/
https://github.com/kern/filepizza
https://github.com/kern/filepizza
to point out this is different and needs network data to upload and download files.
Tried using Sharedrop and it was super slow. Way quicker to just upload to wetransfer.
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.
I prefer PWA like snapdrop. All you need is a browser.
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.
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.
Tried snapdrop, but it didn't work. Not sure if it's related to the GFW....
Easily self hostable as well
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.
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.
Sry about the spelling. Will fix it soon!
Thanks for not making another Electron based desktop app.
Amazing work, congrats!
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...
- https://github.com/LANDrop/LANDrop/blob/master/README.md - https://github.com/LANDrop/LANDrop/workflows/Package/badge.s...
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...
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.
No walled gardens, no subscriptions and no deliberate limitations on number of devices.
Well done.
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!)
- 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!)
Go bears!
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.
Hope this helps. Nice tool and I can see myself using this if these issues are sorted.
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.
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.
I used Resilio Sync (ex BTSync) to transfer between devices, but it's not open source and by default allows to use "relay" servers: https://www.resilio.com/individuals/
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.
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.
It's possible that the iPad failed to bind to the discovery port. It should show you a banner when that happens. Did it?
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.
APK will be signed soon! I just didn't have the bandwidth to generate a keypair :).
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!
I'm not sure why it didn't work on your machine.. It works on mine..
How does this compare to LanXchange?
https://github.com/tfg13/LanXchange
https://github.com/tfg13/LanXchange
LanXchange: Uses Java, no iOS support and I see nothing around if there is any use of encryption.
What does it do that https://www.sharedrop.io/ and https://snapdrop.net/ don't do?
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.
Great advice. Thanks!
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.
Because a post like this one with ZERO comments from the OP in a presence of questions that need answering is plain ridiculous.
Maybe they posted it to come back a few hours later or even tomorrow. The good thing about forums is that they are asynchronous.
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.
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.
Sry! New to HN here. I posted it right before bedtime and didn't know a lot of people would be interested :).
Very useful! Tried the iPhone and Windows clients and they works!
Just
"python -m http.server"
If the network is trusted.
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>never tried to post code on here. didn't realise it wouldn't render.
if you want a proper version of that with some handy complimentary features, then have a look at https://github.com/sebageek/servefile
looks polished, how this is different from Syncthing? a true question, not an argument.
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.
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.
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 :)
- 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 :)
- 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!
Will fix the typo!
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?
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?
It doesn't use the Internet, but it does send broadcasts to your local network for discovery.
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.