OpenDrop: An Open Source AirDrop Implementation
github.com
github.com
Some examples:
* 1-tap file transfers: https://darker.ink/static/media/uploads/08_awarebeam_1.mp4
* Sharing presentations, images and drawings: https://darker.ink/static/media/uploads/05_meshpresenter_1.m...
* Playing Quake 3 (OpenArena): https://darker.ink/static/media/uploads/02_openarena_1.mp4
If you want to know more details, this talk is a good starting point:
https://fosdem.org/2019/schedule/event/device_to_device_netw...
https://darker.ink/blog/mobile-design-with-device-to-device-...
Abstract:
"Apple Wireless Direct Link (AWDL) is a key protocol in Apple's ecosystem used by over one billion iOS and macOS devices for device-to-device communications. AWDL is a proprietary extension of the IEEE 802.11 (Wi-Fi) standard and integrates with Bluetooth Low Energy (BLE) for providing services such as Apple AirDrop. We conduct the first security and privacy analysis of AWDL and its integration with BLE. We uncover several security and privacy vulnerabilities ranging from design flaws to implementation bugs leading to a man-in-the-middle (MitM) attack enabling stealthy modification of files transmitted via AirDrop, denial-of-service (DoS) attacks preventing communication, privacy leaks that enable user identification and long-term tracking undermining MAC address randomization, and DoS attacks enabling targeted or simultaneous crashing of all neighboring devices. The flaws span across AirDrop's BLE discovery mechanism, AWDL synchronization, UI design, and Wi-Fi driver implementation. Our analysis is based on a combination of reverse engineering of protocols and code supported by analyzing patents. We provide proof-of-concept implementations and demonstrate that the attacks can be mounted using a low-cost ($20) micro:bit device and an off-the-shelf Wi-Fi card. We propose practical and effective countermeasures. While Apple was able to issue a fix for a DoS attack vulnerability after our responsible disclosure, the other security and privacy vulnerabilities require the redesign of some of their services." [1]
I got nothing to add regarding OpenDrop other than that I love interoperability, and that I love it when FOSS enables this.
[1] https://www.usenix.org/conference/usenixsecurity19/presentat...
I’m glad Apple are taking the privacy issue to heart, but for every inch we’ve won in privacy, we lost an inch in openness and interoperability. Apple is perhaps one of the worst offenders when it comes to vendor lock-in.
I use almost only Apple products out of sheer laziness (and honestly inertia.) At least their war with Qualcomm and NVIDIA creates some competition in their respective markets...
It's a tradeoff. The point is not MANY eyes, it's ANY eyes. Proprietary software has NO public eyes on it, zero, and the vendor must (1) report to you promptly when there's a new vulnerability, (2) produce a fix for it. Most vendors do neither until forced. How many undisclosed vulns does your vendor have? You'll never know.
Of course FLOSS has bugs, it's software, and ALL software has bugs. In the FLOSS case you know what everyone else knows, AND you can fix them, hire someone to do it, or choose not to use the software, all with that knowledge.
If that were true, security flaws would never be found in proprietary software by outsiders. And they are, so it's not true. Eyes have less visibility into the codebase, but people are looking and do find flaws.
> How many undisclosed vulns does your vendor have? You'll never know.
How many undisclosed vulns does RedHat, Canonical, or Mozilla have in their FLOSS software? You'll never know.
> Of course FLOSS has bugs, it's software, and ALL software has bugs.
Then "many eyes makes bugs shallow" is at least partly debunked and your "ANY eyes make bugs shallow" is debunked completely - otherwise the original developers would see every bug, in FLOSS and proprietary software.
> In the FLOSS case you know what everyone else knows
There may be bugs which nobody knows about. The claim "many eyes make bugs shallow" suggests that open source software has more eyes on the code, and that having more eyes on the code is all it takes to reduce bugs. OpenSSL turned out to have very few eyes on the code, and it wouldn't be too surprising if codebases with many eyes on them had the developers focused on the bits they were developing and not looking for security flaws.
What you're falling to is the selection bias because bugs in open source software are more often publicised than when a private team discovers something and patches it without telling anyone. Same as an open source bug being fixed quietly. Like the so-called VLC vulnerability that turned out to be the fault of the tester's out of date system library that had already been fixed upstream.
Surely to debunk the theory you have to show that fewer bugs are in proprietary software of the same vintage?
AFAIK the many eyes hypothesis is that: as time progresses fewer exploitable bugs will exist in software that has the source open for inspection than in comparable closed source software(?).
When an ages old exploit/bug gets patched that is the many eyes principle working; a piece of software can't get more secure (or otherwise improve) without patching old code, surely.
I don’t, so I didn’t.
I consider both of these advantages, but some users don't. I consider the benefits of open source far exceeds the perceived benefits of Apple's Ecosystem.
Maybe as developers it's important to teach our Apple Peers the problems they perpetuate by paying for walled gardens.
Some of us used to live in the FOSS garden, and decided to trade extra money in exchange for receiving a lot of time back and a shiny finish. Everyones values vary.
Apple advertises similar to Luxury car buyers to make you believe you are getting a high quality product. But it's going to be really hard to prove things are quicker.
Live in their ecosystem, and everything 'just works'. Watch, Phone, Tablet, Laptop.
Linux/Windows you don't quite have that level of integration ...
You expect more from luxury items than with a $300 windows/linux laptop, a $100 fitbit, or a $200 android tablet - good luck with getting a similar level of interoperability between them...
[1] https://qz.com/1660460/hong-kong-protesters-use-airdrop-to-b...
China == (mainland + (Hongkong SAR + Macau SAR) + (... possibly other de jure claims))
If it can be used by protestors it also can be used by advertisers.
Mainland news put HK protesters as violent, rebellious youngsters that are causing trouble and injury to everyone else by having greedy demands of something better than what mainland has. Such story leads to minimal sympathy and curiosity.
Even knowing that this information is filtered, few will end up truly questioning it, and thus even when they leave GFW, they will not know that there is conflicting information to find.
However, many do not feel compelled to evade it, and have no idea of what happens "on the outside".
I do not know what provider they use, but their knowledge of VPNs go no further than knowing that "VPN = facebook access", so it would seem that "commoners" still manage at least in some bigger regions.
I’d love to know if anyone knows the technical details about what caused this regression?
The "Share Only With Your Contacts" option still seems broken to me, I usually have to temporarily allow all access before AirDropping something.
AirDrop 2 is still so finicky I just much rather put stuff on a USB key.
When it works, it just works.
On the Mac though, it is a different story. Just yesterday my wife was trying to send me a PDF and I had to send it to my phone from her Mac, then dump it into iCloud Drive. I rebooted my Mac and then it worked again - but these are stock 2018/2019 Apple laptops, they shouldn't have these issues.
It does have a centralised signalling server for key exchange between peers, but it does attempt to do peer-to-peer data transfer (only falling back to a TURN-style relay if both clients are behind NATs and aren't on the same local network). An explanation of the cryptography and design was given at PyCon 2016[2]. It also has built-in optional Tor support (though I'm not sure if it attempts to use an onion service for data transfer).
[1]: https://github.com/warner/magic-wormhole [2]: https://youtu.be/oFrTqQw0_3c
(The technical reader will note that a terminal does not give you apt, but mentioning that I have Debian running on the phone is more confusing, as it sounds like I replaced Android (which I did not) or maybe that it costs a lot of battery (the tools are idle when not in use, unlike many apps unfortunately...).)
[1]: https://kivy.org/
If you're somewhere with poor (or no) network connectivity you can still use Google Files or AirDrop (I believe, not 100% sure on AirDrop).
The pilot had taken a video of the Falcon 9 second stage separating from the first on its first launch that docked with the ISS. He then walked through the cabin sharing with anyone that was interested.
The point is, options are good. Most of us subscribe to the Unix philosophy of "Write programs that do one thing and do it well" so why are so many advocating for a pancea solution that does everything for every use case?
If I remember correctly, you can configure (I don't know what the default is) to power save or even turn off WiFi on Android when you turn off the screen. Are you sure that's not interfering with this beta app?
http://techland.time.com/2014/01/01/sadly-but-inevitably-goo...
Many popular file manager apps on android have peer-to-peer xfers as well, via WiFi direct, etc.
EDIT - As people are pointing out this isn't universal because it doesn't work on Apple devices or desktops / laptops, but it's as close as I can think of currently.
- "is a standard"? What does this mean? Google Files is not a standard of any kind.
- others have mentioned that this is very far from universal. Whatever about Apple devices, you're also discounting all non-mobile devices. Transferring files easily from computer to phone is probably the most common use-case. Yes, you can use Google Drive for that, but that's neither p2p nor seamless.
- the above commenter mentioned wanting a "secure" solution. That's a bit of a subjective term, but I would guess, at least on HN, the typical one would be e2e encrypted, and private. Google Files is neither of these things.
- the p2p function is severely limited in that it requires both a Google account, and location services to be enabled. Neither of which are necessary to initiate a p2p file transfer.
(as another commenter has mentioned), if we're just looking for "the closest thing", I would suggest https://send.firefox.com/ It isn't p2p, but it is secure and universal, so it ticks a lot more boxes overall.
I wouldn't exactly call that universal...
Still, about 8x better than AirDrop!
The US's market share split is more like 55% Android and 45% iOS, so anything that doesn't support both platforms is going to fail half the time here.
> Triggering macOS/iOS receivers via Bluetooth Low Energy. Apple devices start their AWDL interface and AirDrop server only after receiving a custom advertisement via Bluetooth LE (see USENIX paper for details). This means, that Apple AirDrop receivers may not be discovered even if they are discoverable by everyone.
If someone reverse engineer BLE advertisement, yes they can build such hardware.
XMPP over Zeroconf (https://xmpp.org/extensions/xep-0174.html) has already existed for many years and at least previously has been trivial to enable on Ubuntu (I haven't tried it recently).
Your statement may be tongue-in-cheek, but this sort of attitude is why we don't have this deployed on devices en-masse. Non-technical users want something that just works with one tap, not something that requires them to manually set up an ad-hoc WiFi network every time they want to use it.
My original point was simply that the technology exists, and pointing out that there isn't a decent client doesn't negate my point.
It is unfortunate that our ecosystem is arranged such that a decent client hasn't happened.
Or they could just 'listen in' to record the signatures of all detected phones, so they can work out and identify who is in the crowd etc.
Military systems use frequency hopping etc and would be a more difficult target. But doubtless motivated governments could hamper their use in crowds too. Here's a fun comment I just found when I googled that: https://www.quora.com/Is-noise-jamming-an-AESA-radar-possibl...
In any society, there is state-"friendly" communication and state-"unfriendly" communication. Also there are state-"essential" communications like state-propoganda [1]. Is it possible to build communication networks that allow for secure and anonymous state-unfriendly communication, such that trivially jamming it also jams state-friendly and state-essential communications?
As you might realize, a yes answer to this question is sufficient for protestors communication needs. Not the harder question of completely unblockable communications - which as we know is impossible. Of course, in the real world, the answer to my question might not be a "yes/no" but a resource-tradeoff.
[1] which every country in the world democratic or dictorial engages in. If you don't agree, please read Manufacturing Consent.
That air-drop does work in the Hong Kong protests really just says that the state wasn't really prepared, but they probably will be next time.
Although, really, China is so far ahead in the practical application of face recognition and making protesters disappear or arranging counter-riots etc that I guess airdrop is not really where they think the fight goes?
I don't entirely agree. It's a resource tradeoff scenario where the state has to expend political-capital (because they are also blocking people living nearby) to prevent the protestors from communicating. In fact, the protestors in Hong Kong have been protesting in different neighborhoods so non-protestors can see first hand the brutality of the state.
I agree with your larger point though that communication jamming is probably a minor point right now in the Chinese state's gameplan for dealing with these protests.
It’s not perfect - there are trade offs, like how the wireless performance is reduced somewhat when AWDL is active due to channel hopping and how AWDL expects a single node to play the role of clock sync source. It’s also not very well tested yet.
However, it works and in theory it allows an infrastructure-free IPv6 mesh network to be built ad-hoc.
In theory, other Android devices support WiFi Direct too, maybe they just don't ship userspace apps for that, like Samsung does.
I even use it even between my laptop and my phone fairly frequently, since the top suggestion on my phone keyboard in the browser is dro.pm and I just have to add a slash (long-press "m") and a letter. It's quicker to use dropm than to open a chat with myself or send myself an email or something.
Of course this is just protected by https, and although it is source-available and the links are really gone after expiry (or when you edited it, the old contents are irretrievable), magic-wormhole is superior in that you don't have a trusted third party. For the cases where the other party doesn't have magic-wormhole installed, this might be helpful. This also alleviates the requirement of WebRTC for both parties to be online simultaneously.
> magic-wormhole is superior in that you don't have a trusted third party.
Well, magic-wormhole does need a trusted third party called Rendezvous Server. [1]
[1]: https://magic-wormhole.readthedocs.io/en/latest/api.html#ren...
The Apple ecosystem is very closed and Apple will fight tooth and nail to keep it that way. Removing vendor lock-in would, after all, allow users to try switching to another brand without an enormous amount of hassle.
In general you are right, Apple is very adamant about keeping full control over their ecosystem (and locking users in). They even sponsor a C compiler project so that they can avoid gcc. There are exceptions though, like AirPrint which is a marketing name for open standard technologies: https://wiki.debian.org/AirPrint
We had XMPP among others, and Apple decided not to be open. We now also have Signal or Telegram, which are multi-platform.
Sorry, I was being a bit sarcastic :P ;)
If you say "yeah sure it is, we're even releasing it as open source" then you prevent the product falling at the first hurdle because people want an interoperable solution. Once you have adoption network effect carries you through.
Sounds like most probably a standard corporate lie by Jobs; do you have evidence to the contrary?
Things that they’ve adopted/forked/bought are but there’s not much they’ve started from scratch and released as OSS.
There is almost no expectation of it from people who know Apple.
Promising something unexpected and not delivering is undoubtedly more damaging than saying nothing.
iMessage isn't the first nor last proprietary chat platform. It's seen as a competitive advantage, just like BBM was back in the day.
Does Android have something similar to iMessage?
Kind of-ish. The RCS support is rolling out slowly. Of course there is a big difference in that RCS is not end to end encrypted. Also, there is nothing stopping Apple from implementing RCS as well, but I doubt they will do.
If there's one thing that Apple hates more than lost profits, it's handing over control of anything to carriers. Cheap-subscription iMessage/Facetime for Android would strangle RCS/Duo in the cradle and put a thumb in the eye of the carriers, while bringing in some steady and significant regular revenue. Let's not forget that Apple is already offering a subscription service on Android, Apple Music. They're not averse to the concept.
No. The parent to your comment means open iMessage between Android and iOS.
It has some massive annoyances but it's very well embedded.
edit: Okay, on a closer look, it seems like you do need two licenses, because the iOS license can only be purchased through the iOS app. Just wish they'd provide a brief trial so I could test it.
edit2: Nevermind, apparently, if you install the apps, you can use them in a limited fashion before buying. It doesn't say anywhere what the limits are, but it says there are limits.
I grew to dislike the app after running into the limits/ads. It does work, but it feels cheap and unpolished. There's no way I'd ever buy one of the pricing plans. I just don't feel like I would be getting my money's worth, especially when I could just go through a more involved solution.
Uses WebRTC for file transfer.
Works perfect between IOS, Android, Linux, MacOS and Windows.
What does Apple sell? A commodity computing device running undifferentiated software? Or the experience of a holistic tool?
When someone distributes a Messenger by itself, you don't ask why it isn't open. You don't ask why the hardware device isn't open. Why should a vendor unbundle the two just to make you happy?
What if it doesn't really unbundle, what if the capabilities combine to offer most buyers something they value more than pieces parts?
Requiring a device certificate to communicate puts a pretty high bar on the integrity of the system. Being closed also allows unrestricted innovation at a faster pace.
It’s very difficult to add features once an open standard is out. Just look at the evolution of the major web browsers for example.
Theoretically but has there been any new actual development in AirDrop though? From the outside it seems like it's been the same since it was released but my only Apple device is my iPad Pro so I don't really have a use for it.
Few days back my home router broke down and I was unable to send URLs from my iPhone to Mac just because there was no common network.
I wish for AirDrop to be more like Pushbullet.
How do you figure? I've never seen any discouragement from it.
"Disabling" Bluetooth is similar, it will disconnect from paired devices, but BTLE is still available.
You have to use airplane mode, or go in to the Settings app to fully disable it. If that isn't discouragement, I don't know what is.
In fact, it can be much faster than copying using traditional file shares etc, as wireless routers can slow things down.
Maybe things like hyper local advertisements.
But it would also need to seamlessly mix bluetooth and wifi discovery too.
It is an okay language, but after tracking down why it doesn't build and considering messing around in my system and making either installing older versions of libraries or messing around with symlinks I stopped and asked myself "really? I want to spend my time fixing this?" and just deleted the entire clone of the git repos.
Python is a nice language and all, but it is not a language suitable for writing applications that you distribute. (I wish the Python core developer would devote some time to making Python less horrible for distributing applications, but after around 30 years, I don't think so).
- Realize nothing I work on really has so much impact as this one lone hero is likely to have already achieved by releasing this code
- Open HN thread with a sense of wonderment
- Read top comment, engulfed by a wave of revulsion, remember why we can't have nice things
Except to add that Python has issues but is clearly winning hearts and minds for a reason. It’s wonderful that an open source language has become so powerful, versatile, and widely adopted.
I’d take this era of computing over the days of ActiveX and Flash being the ubiquitous approach to releasing software.
The C way of referring to header files and libraries on the host system invariably leads to situations where the app wants to use a specific version that your system doesn't have. And we're not necessarily talking about system libs, either. Apparently authors thought the only way to mitigate the problem was to invent Automake/Autoconf in order to sniff what your system is capable of. (The saner solution for non-system libs would be to "vendor" your dependencies inside the app's source tree.)
Python has that pretty much solved with PIP. (Dependencies can still be a problem if a package uses the C way to link to things like Readline or OpenSSL or whatever.)
To be fair java based software install isn't much better.
R is oddly a standout, in ease of installing packages. (Except the one time it didn't work, but in this case it wasn't much worse than anything else).
In general software distribution could be made much better.
Just hope you are lucky enough to have the right C dependencies installed.
npm was also really bad about nothing building or working a few years back. It's improved, and there are alternatives like yarn. Rust/Cargo has this issue as well (whenever I attempted to pick up some Rust; every example I found would break -- constant language changes were an issue; not sure if that's still the case).
Package management is a big problem in general, but we have solutions like the ones I've mentioned. This is a bad argument against not using Python. I honestly thing this type of application is fine in Python (you might need a privileged container if you go the docker route; wasn't sure how low level the Wi-Fi stuff it needs is).
What language do you recommend for this type of application and why?
(With disk and memory sizes, dynamically linked binaries aren't really as relevant anymore since the often trivial cost of size more than makes up for the nontrivial cost of having to fiddle around to make things actually work)
I agree that the situation isn't perfect in the python world but it's actively being worked on and I think PyOxidizer looks like one of the most interesting recent developments in this space: https://pyoxidizer.readthedocs.io/en/latest/
Some other alternatives (depending on your use case, e.g. target platform) are PyInstaller, py2exe, py2app, cx_Freeze, Shiv, PEX (basically tooling for native .pyz), XAR, Nuitka (compiles Python into a native binary), pyninst (creates windows installer), PEP 441 style .pyz (executable python archive, can easily vendor in dependencies). Then there's tools like fpm if you want to create packages for deb, rpm, FreeBSD, macOS .pkg, paceman, tar-archives, etc.
I've used some of these in enterprise settings building rich GUI-applications being distributed to end users who have no idea of what Python is and to whom underlying technology choices are invisible.
The thing is: for it to be useful people have to use it. And for people to use it nothing works better than one clear, idiomatic way.
If you have many solutions you often end up having no solution.
This is the #1 reason why .NET Core gets so much of my mindshare these days. If I write something and put it out there, it will Just Work (TM) 99.99999% of the time. As soon as the user runs `dotnet build` or `dotnet run`, it'll automatically go grab the exact right versions of packages from NuGet and set everything up locally. The only time anything tricky ever happens is if some third-party library doesn't ship a native library dep for each platform; that's rare, but does occasionally happen.
I built all of Cronitor in Python, still love it, but when we started building server agents it was not a hard decision to leave Python behind. (In this case, for Go)
I was working on a Flask project many years ago and it didn't seem straightforward to "vendor" dependencies with the `pip install` paradigm. Guess I was wrong.
https://medium.com/underdog-io-engineering/vendoring-python-...
There's a reason why virtualenv and similar exist. Another interesting point. Gentoo Linux (which uses Python in the Portage package manager) doesn't support installing modules as system (by default) to presumably avoid breaking the system package manager.
I learned this when taking a computational finance class specifically to figure out why that and the quant/ai/ml community gravitated around python.
Python's advantages here came from about 12 years ago, when the syntax was friendly but other similar syntax friendly languages had a lot of overhead and other compromises. But these differentiators are mostly non-existent today, and Python is the only one with basically two different programming languages (py 2.x, py 3.x) operating under a single "Python" brand.