AirDrop Anywhere – Making it work on Windows | Hacker News Reader

AirDrop Anywhere – Making it work on Windows

bakedbean.org.uk

95 pointsg3rv431 comments

"it is unlikely that a non-Apple device has hardware support for adhoc wireless connections between devices. This makes implementation of AirDrop directly on non-Apple devices practically impossible without additional hardware. Instead we’ll implement a proxy..."

I get what they mean here, but it has been done. It does require a Wi-Fi card with support for monitor mode and frame injection. OWL did it with an Atheros AR9280.

Open drop also requires extracting keys from an Apple device if you want Apple interop.

See OWL:

https://github.com/seemoo-lab/owl

And Open drop:

https://github.com/seemoo-lab/opendrop

When you turn your android phone into a wifi hotspot, it creates a lan between your phone and the client. Isn't that enought ?

Not to send an AirDrop to an Apple phone, no. That requires the adhoc p2p wifi scheme they are using, plus the keys/certs.

Well, that’s why I said it’s unlikely :)! Without purchasing additional hardware it’s not practical to be able to run AirDrop directly on non-Apple devices.

There’s no need to extract any Apple keys to be able to receive files, but the public root key appears to be needed able to send files to an Apple device.

OWL, OpenDrop and their latest project PrivateDrop (https://github.com/seemoo-lab/privatedrop) are linked heavily throughout the series - their reverse engineering of the protocol have been absolutely invaluable in building something that works, more or less sanely on non-Apple devices! Huge kudos to them!

Ah, sure. I didn't mean it as criticism, just to say it's possible with the right wifi chipset.

> It does require a Wi-Fi card with support for monitor mode and frame injection. OWL did it with an Atheros AR9280.

I feel like Windows is in part to blame for wifi not evolving. The OS does only the most minimal, basic, simplistic wifi operations, so non-Apple laptops end up with wifi hardware supporting only the most basic, simple wifi capabilities.

I raelly want p2p connectivity to be better in this world, want our amazing digital connectivity to be distributed, not to move beyond relying on top down ISP based networking. Alas, the wifi hardware available on many laptops is just not there.

And even if it were there, it seems unlikely that Windows, Apple, and Google devices are willing to communicate with each other. Everyone has their own proprietary systems (or in Windows case, like the old days where you had to download winsock, it simply has: nothing).

Windows 10 has Miracast built in and has encouraged wifi drivers to support it. Miracast is built on top of Wifi Direct like most of these other p2p tools. Windows also has a hard to find "AirDrop"-like system, but between having no mobile devices anymore and incompatibility with Google and Apple's proprietary systems no one thinks to use it (because it's mostly just useful between Windows devices and at that point you probably have older tools like file shares that perfectly cromulent rather than worrying about physical proximity).

A lot of these things also don't get explored as much as they should be because the APIs are in the WinRT side of the fence and Project Reunion is only just now opening WinRT to a lot more classic Windows devs.

So Windows doesn't have "nothing" here, it's just trapped between rock (Apple) and hard place (Google).

Excellent point about Miracast.

It'd be interesting to see some example code that makes use of any platform SDKs windows has available for doing wifi-p2p connectivity with peers. Going from "this is a capability windows uses" to "this is a capability of the platform folks can use" is another jump in meta-level towards encouraging the virtuous hardware/software adoption cycle.

Seems the API is named almost exactly what you would expect, Windows.Devices.WifiDirect:

https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.WiF...

I appreciate the hard work and expertise. But I absolutely do not get the point in reverse engineering a protocol that has been actively closed off. We can all come up with a universal airdrop RFC instead. That effort would be better spent.

It's not some magic, it will be a very simple protocol.

Probably because reverse-engineering it is less effort than rewriting all the clients that Apple has already written.

AFAIK Apple has written exactly 2 clients (Ios and Macos). It shouldn't be too hard to write 2 extra clients. In return you get to design your own open protocol from scratch and don't need to rely on Apple not breaking it at any point of time.

Because AirDrop is already available on millions of Apple devices. If you start a new protocol it will only be available for a small user base and you need to ask Apple, Google and Microsoft to implement it.

I think that, like imessage, you need certificates signed by Apple in order to actually use it with Apple devices.

Really you'll be happier if you just ignore everything going on with iOS and Android.

This is not correct, you can receive files from non-Apple devices without any Apple keys. I’m still working on sending so haven’t uncovered the demons lurking there…

IIUC AirDrop is locked to Apple Hardware anyways (by device IDs and similar) so even if you could speak the protocol you wouldn't be able to connect.

^^ this! No need to install anything on my Apple devices. Long term plan is to have an instance of AirDrop Anywhere running perpetually on a Raspberry Pi and have a web interface accessible over the LAN for non-Apple devices to connect to when sharing files.

That said, this is all just a bit of fun so monetising it isn’t really on the cards anyway :)

It's pretty vulgar that Apple people continue to feel like, well, I have a protocol that works on my devices, so what if the rest of the world can't participate? "Works for me!" has it's merits, oh sure, but some willingness to see the faults & deficiencies would be a nice balance.

Is it any different from Linux users pushing software that depends on Linux syscalls to function and scoffing at Microsoft's attempts to achieve platform parity with WSL? I can't tell you how many times I've heard someone in computing say "just use linux!" instead of attempting to solve whatever problem a user is having with their current hardware and OS. We all want to believe that our personal choices are the best ones anyone can make for themselves.

Very little in open source hard-relies on Linux sys-calls. Trying to make this a "both sides" argument is farcical.

Saying that a platform shouldn't lock you in to specific proprietary approaches has a real & substantial non-personal advantage to it that mere personal preference doesn't encompass, as it seeks technical ecosystems capable of organic growth. I don't find your comparison quite valid.

Why would you need MS/Apple/Google to implement it? Just write your client and install it. Anyway you need to install the reverse engineered clients on non-apple devices, which are the majority.

>> But I absolutely do not get the point in reverse engineering a protocol that has been actively closed off.

You might be in the wrong forum. ;P

I kid obviously - but in all seriousness some people actually do this stuff for fun! And also just to know more about the services we use every day.

The fun and the learning, I definitely understand. For me, though, while I don't mind working around technical limitations to develop something, I get immensely frustrated at working around artificial barriers.

All technical limitations are artificial barriers enforced by humans. Software and hardware doesn't just fall out of the sky.

Technical limitations are the result of humans straining in the direction of producing better things, and needing to make tradeoffs by virtue of not yet being gods. I'd put those as distinct from artificial barriers, which are when a product is intentionally worse than it could be (e.g. detect when running in Wine and refuse to run), and was designed to be so.

It's been a decade since AirDrop was released. It's clearly a useful capability, and I would love to be able to share with any device this way. Nevertheless, no universal protocol has emerged, simple or otherwise, that could take its place.

We already have a standard file share protocol, Bluetooth. The problem is the UX sucks so much that almost no one uses it.

It’s hard to say exactly why Bluetooth can not fix these issues but perhaps the proprietary nature of AirDrop lets apple innovate without concern for standards or legacy.

How about making it work on Macs first?

Airdrop is the one component that is completely hit or miss for me.

So convenient when it just “works”. Infuriating when it doesn’t.

Seems interesting, and seems the developer has made good progress. This would potentially open up AirDrop for Android too. That would be great!

Looking forward to "John Anderton" style unsolicited personalized ads bombarding people via AirDrop.

you can try elapp dont know how they do it but it works on iOS Android Windows and Mac

https://www.elapp.com/

Reply on news.ycombinator.com