Live data from Hacker News

OpenDrop: An Open Source AirDrop Implementation

github.com

31–40 of 231 posts

Re: OpenDrop: An Open Source AirDrop Implementation

#31
post #25
post #24

Earlier quoted context omitted.

You just have to be within bluetooth distance; AirDrop doesn't require the same wifi network. It does require wifi to be enabled, because AirDrop creates its own wifi network side channel for the actual transferring of files.

Really? I'll give it a try again. It was clearly not working for me when the router was down.

Yes, no router needed since it relies on Wifi Direct.

Re: OpenDrop: An Open Source AirDrop Implementation

#32
post #24

Earlier quoted context omitted.

You just have to be within bluetooth distance; AirDrop doesn't require the same wifi network. It does require wifi to be enabled, because AirDrop creates its own wifi network side channel for the actual transferring of files.

Yep. But still it’s kind of annoying to have to enable everything. It’s confusing to people who don’t know this.

Enable what? Modern MacOS/iOS discourage you from disabiling Wi-Fi/Bluetooth anyway.

Re: OpenDrop: An Open Source AirDrop Implementation

#33

Could this technology be used to create a "shadow" internet/network/messaging service where devices connect and communicate directly with each other. This way governments can't just block internet access or services during demonstrations.

FireChat.

Re: OpenDrop: An Open Source AirDrop Implementation

#35
Interestingly the article on the bottom links to a Usenix 2019 (held Aug 14 - 16) paper with the title "A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Tracking Attacks on iOS and macOS Through Apple Wireless Direct Link"

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

Re: OpenDrop: An Open Source AirDrop Implementation

#37

I wonder if it's more reliable than Apple's own implementation for MacOs. It used to be rock solid – and between iOS devices it still is – but between Macs I regularly have to switch both to "Search for an older Mac" to make them see each other, with no explanation why.

I was complaining about this with a coworker today. AirDrop 1 was flawless, since 2.0 it has been more often than not unreliable between Macs.

I’d love to know if anyone knows the technical details about what caused this regression?

Re: OpenDrop: An Open Source AirDrop Implementation

#38
post #5
post #3

I wish we had something like AirDrop to work between android and iOS devices.

Knowing Apple, such an effort would likely be destroyed by an army of lawyers the moment you bring out an app that provides such features. 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.

> The Apple ecosystem is very closed and Apple will fight tooth and nail to keep it that way.

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

Re: OpenDrop: An Open Source AirDrop Implementation

#39

I'm guessing someone will take a $10 esp32 chip and put this code on it and just drop the esp32 in some hidden location and it just sending images to any open airdrop that passes by.

I had it a couple times in trains that people tried airdropping me porn when I forgot to turn it off

Re: OpenDrop: An Open Source AirDrop Implementation

#40
post #7

Earlier quoted context omitted.

iMessage too. It's insane to me that this is still a problem.

That's not a problem. That was precisely Apple's idea: a not interoperable message network. We had XMPP among others, and Apple decided not to be open. We now also have Signal or Telegram, which are multi-platform.

Sorry but how is iMessage being a walled garden not a problem for those outside that wall?
Post reply on HN