The Cross-Network File Transfer Problem

Introduction

Two devices in the same room. The user wants to move a file from one to the other. This should be a solved problem. Apple has built two billion devices. Google ships nearby sharing on every Android phone. There are dozens of well-funded apps and a thriving ecosystem of open-source alternatives.

And yet, in practice, the moment those two devices are on different networks - phone on cellular, laptop on a corporate VPN - every single one of those tools silently fails.

This is not a corner case. It is the dominant failure mode for proximity file transfer in 2026. The user is sitting at their desk, both devices working, both with internet connections, both visible to the other across two feet of physical space. The transfer just doesn't happen, or it hangs, or the apps can't see each other at all. Most users assume this is their problem. It is not. It is an architectural property of every proximity transfer tool currently in production.

This guide explains, at a technical level, why each major approach fails - AWDL, Quick Share, mDNS-based discovery, WebRTC peer connections - and what kind of architecture would actually solve the problem.

It is written for engineers and technical readers who want a comprehensive understanding rather than a marketing comparison. It cites primary sources where possible.

What "different networks" actually means

Before discussing why current tools fail, it's worth being precise about what we mean by "different networks." The phrase covers several distinct technical situations, all of which break proximity transfer in different ways.

Different physical networks. One device on cellular (LTE or 5G), the other on WiFi. The two devices have completely separate paths to the internet through different infrastructure operated by different parties. They have no common network segment.

Different VLANs on the same physical infrastructure. A corporate office where the guest WiFi is on VLAN 20 and employee devices are on VLAN 10. Physically the same building, the same access points, but logically separated by network configuration. Devices on different VLANs cannot directly address each other.

The same WiFi network with AP isolation enabled. Hotels, conferences, coffee shops, and many corporate guest networks deliberately isolate clients from each other. Two devices both connected to "Conference WiFi" cannot reach each other even though they share the same SSID. This is sometimes called "client isolation" or "wireless isolation" and is enabled by default on most enterprise-grade access points.

The same network but separated by VPN tunnels. A laptop running a corporate VPN routes traffic through a remote corporate gateway, while the phone on the same WiFi routes traffic locally. They share the access point but their packets traverse completely different paths.

The same network but with restrictive firewall rules. Many corporate networks block UDP traffic, multicast, or specific port ranges. Devices that are nominally on the same network may not be able to use the discovery or transport protocols proximity tools require.

Each of these situations breaks proximity transfer in slightly different ways, but the failure mode is consistent: tools that depend on devices being able to discover and address each other on a shared network cannot do their job.

AWDL: how AirDrop actually works, and why it stops at Apple

AirDrop is the most widely used proximity transfer tool on the planet, but understanding why it fails for cross-network and cross-platform scenarios requires understanding what it actually is.

AirDrop is built on a protocol called Apple Wireless Direct Link (AWDL), which Apple introduced around 2014 and has never publicly documented. AWDL was reverse-engineered by researchers at TU Darmstadt's Secure Mobile Networking Lab (SEEMOO) and published at ACM MobiCom '18 in a paper titled "One Billion Apples' Secret Sauce: Recipe for the Apple Wireless Direct Link Ad hoc Protocol" by Stute, Kreitschmann, and Hollick.^[1] The same researchers later released OWL (Open Wireless Link), an open-source AWDL implementation in C, and OpenDrop, a Python tool that uses OWL to enable AirDrop on Linux devices.^[2]

The technical operation of AWDL is genuinely interesting:

AWDL is a Layer 2 ad-hoc protocol built on IEEE 802.11. It is not WiFi Direct. It is not WPS. Apple built a custom protocol on top of standard 802.11 frames that allows multiple devices to communicate without an access point.

The synchronization mechanism uses Availability Windows. Each AWDL node announces a sequence of time windows during which it is listening on the AWDL channel. An elected master node synchronizes these windows across the cluster. Outside these windows, nodes can return their WiFi radios to their normal access point or turn the radio off entirely to save power. This is how AWDL coexists with regular WiFi connections without breaking either.

Communication uses link-local IPv6 addressing. AWDL provides a virtual network interface (awdl0 on macOS, equivalent on iOS) with link-local IPv6 addresses (the FE80::/10 range). Devices discover each other through AWDL and then communicate via standard IPv6 over the AWDL link.

AirDrop on top of AWDL is HTTP-based. Once two devices have established AWDL connectivity, the actual file transfer happens over a relatively conventional HTTP-based protocol. The novelty is entirely in the underlying ad-hoc link layer.

This architecture has a critical implication: AWDL requires both devices to be Apple devices running a chip that supports AWDL. The protocol is proprietary, undocumented, and effectively impossible to implement on non-Apple hardware without significant reverse engineering effort. The OWL project demonstrated it could be done on Linux, but only with specific WiFi cards (Atheros AR9280 or similar) operating in monitor mode with frame injection - not something a typical Windows or Android device can do.

This is why AirDrop has never worked between iPhone and Windows, between Mac and Android, or to any non-Apple device. It is not a policy choice that Apple could change with a software update. It is an architectural property of the protocol AirDrop depends on.

There is a small but interesting development worth noting. In iOS 26, EU regulators required Apple to deprecate AWDL in favor of the IEEE 802.11 Wi-Fi Aware standard, an open protocol with similar functionality.^[3] As of November 2025, Pixel 10 phones gained limited AirDrop interoperability via Wi-Fi Aware, the first non-Apple devices to support AirDrop in any form. This change is meaningful but does not solve cross-network transfer - Wi-Fi Aware, like AWDL, requires both devices to be in direct radio range and capable of forming an ad-hoc connection.

Quick Share: Google's answer, with the same architectural ceiling

Google's equivalent is Quick Share (formerly known as Nearby Share, renamed in early 2024). Like AirDrop, it is a proximity-based file sharing protocol built on a combination of Bluetooth Low Energy for discovery and direct WiFi for the actual transfer.

The architecture is similar in spirit to AirDrop but different in detail:

Discovery uses BLE advertisements. Quick Share devices broadcast their presence via BLE. Other Quick Share devices in range detect these advertisements and present the device to the user as a potential recipient.

Transfer uses peer-to-peer WiFi. Once a sender selects a recipient and the recipient accepts, the two devices establish a direct WiFi connection - either through WiFi Direct or through a temporary access point - and transfer the file at WiFi speeds.

Authentication leverages Google account identity. Devices signed into the same Google account are trusted automatically; for transfers between different accounts, the user is prompted to confirm.

Quick Share's compatibility surface is wider than AirDrop's - it works between Android devices, Chrome OS devices, and Windows PCs (via a standalone Quick Share for Windows app released in 2024). However, it does not support iOS, and Google has given no indication this will change. The reasons are partly architectural: iOS does not expose the low-level radio APIs Quick Share's discovery and transfer mechanisms require. They are also partly business: there is no commercial pressure on either Apple or Google to interoperate when both companies benefit from ecosystem lock-in.

Like AirDrop, Quick Share also requires that both devices be in direct radio range and capable of forming a peer-to-peer wireless connection. It does not work across networks in any meaningful sense - even when both devices have internet connections, Quick Share cannot use them for transfer because the protocol assumes a direct radio link.

mDNS-based discovery: why Snapdrop and LocalSend fail across subnets

A large category of open-source AirDrop alternatives - Snapdrop, LocalSend, ToffeeShare, and many others - use a different architectural approach. Rather than relying on proprietary radio protocols, they use multicast DNS (mDNS) for device discovery on the local network.

mDNS, specified in RFC 6762, is the protocol underlying Apple's Bonjour and Linux's Avahi. It allows devices to discover each other on a local network without a central DNS server.^[4] When a device wants to find other devices offering a particular service (file sharing, AirPlay, network printing), it sends a multicast query to a well-known address - 224.0.0.251 for IPv4 or ff02::fb for IPv6 - on UDP port 5353. Other devices on the same network segment that offer the requested service respond with their addresses.

This works beautifully when both devices are on the same network segment. It does not work across network boundaries, by design.

The reason is fundamental to how IP multicast works. Multicast packets sent to 224.0.0.251 are link-local - they have a TTL of 1 and are not forwarded by routers between subnets. This is not a configuration choice. It is the defined behavior of the multicast address ranges mDNS uses.

When a Snapdrop user has their phone on one network and their laptop on another - even in the same building - the laptop's mDNS query never reaches the phone, and the phone's response would never reach the laptop even if it did. Each device sees an empty list of nearby Snapdrop users and silently fails to discover the other. This is well-documented behavior. From Cisco's documentation on the Service Discovery Gateway feature: "Because mDNS uses a link-local multicast address, its scope is limited to a single physical or logical LAN."^[5]

There are workarounds, but none of them are practical for end users:

mDNS gateways or "reflectors" can be configured on enterprise routers to forward mDNS queries between subnets. Cisco, Cato Networks, and other enterprise networking vendors offer this functionality.^[6] However, it requires explicit configuration by a network administrator, is generally disabled by default for security and performance reasons, and is not under the control of the user trying to share a file.

Manual entry of IP addresses would in theory bypass discovery entirely. Some tools support this. None expose it as a usable consumer feature.

TCP-based discovery on the same network would work in theory but is rarely implemented because it sacrifices the zero-configuration property that made mDNS attractive in the first place.

The summary: any tool that relies on mDNS for discovery - and most browser-based proximity transfer tools do - will silently fail whenever devices are on different network segments. This includes most situations in any modern enterprise office, hotel, or conference venue, where network segmentation is the default rather than the exception.

WebRTC peer connections: the corporate firewall problem

A more sophisticated category of tools uses WebRTC to establish peer-to-peer connections between browsers. WebRTC was originally designed for real-time audio and video communication but works equally well for file transfer via the data channel API.

WebRTC's NAT traversal mechanism is Interactive Connectivity Establishment (ICE), specified in RFC 5245. ICE is a sophisticated protocol that combines several techniques to find a working communication path between two peers behind NAT devices and firewalls.^[7]

The two key protocols ICE uses:

STUN (Session Traversal Utilities for NAT), specified in RFC 8489, allows a client behind a NAT to discover its public IP address and port as seen from the outside world. The client sends a request to a STUN server on the public internet; the server responds with what address it sees the request coming from. The client can then advertise this address to its peer, allowing the peer to send packets directly back to it through the NAT.

TURN (Traversal Using Relays around NAT), specified in RFC 8656, provides a relay server when direct connections fail. Both peers connect outbound to a TURN server; the server forwards packets between them. This is slower (extra hop, extra latency) and more expensive (the relay provider pays for bandwidth) but works through almost any network configuration.

In well-behaved networks, STUN succeeds and ICE establishes a direct peer-to-peer connection. In other networks, ICE falls back to TURN. The problem is that "other networks" includes many of the situations where users actually want to transfer files.

Several NAT configurations and firewall rules consistently break direct WebRTC connections:

Symmetric NAT. A NAT type where the external port assigned to outbound packets depends on the destination. STUN cannot reliably help in this case because the address learned by talking to the STUN server may not work for connecting to a different peer. Industry estimates suggest 20-30% of WebRTC connection attempts encounter symmetric NAT on at least one side.

Restrictive firewalls that block UDP. Many corporate networks allow only TCP traffic outbound, and only on standard ports (80, 443). WebRTC's preferred transport is UDP. When UDP is blocked, even STUN cannot complete its handshake.

Deep packet inspection. Some corporate networks inspect outbound traffic for specific protocols and block anything that doesn't match expected patterns. STUN/TURN traffic, which has identifiable signatures, is sometimes filtered specifically.

Restrictive port ranges on outbound TURN. Even when TCP TURN is available, some corporate networks only allow outbound traffic on port 443. TURN servers typically operate on port 3478 (UDP/TCP) or 5349 (TLS); a network that only allows port 443 outbound will fail to reach standard TURN servers.

Estimates from production WebRTC services suggest roughly 30% of attempted connections require TURN relay, and a meaningful fraction of those fail because of restrictive corporate firewalls.^[8] This translates directly into "WebRTC-based file transfer just doesn't work" for a significant minority of users in corporate environments.

The broader point: even when a tool is sophisticated enough to use WebRTC and modern NAT traversal, it still depends on assumptions about network behavior that don't hold in many real-world environments. The corporate user trying to send a file from their personal phone to their work laptop is exactly the user most likely to be on a network that breaks WebRTC.

What about the failure modes the user actually experiences?

Each of these architectural failures produces a different user experience, but they share a common feature: the user has no way to diagnose what went wrong.

When AirDrop fails because the recipient is on a non-Apple device, the recipient simply doesn't appear in the share sheet. The sender sees their own devices and any contacts, but not the colleague sitting across the table with a Windows laptop. There is no error message. The protocol does not exist on the recipient's device.

When Quick Share fails because the recipient is on iOS, similarly there is nothing to indicate why - Quick Share's discovery mechanism never sees a Quick Share-compatible device.

When Snapdrop or LocalSend fails because devices are on different VLANs, both devices show empty device lists. mDNS queries are sent and silently dropped at the router boundary. Neither device knows the other exists. Both users assume the tool is broken.

When WebRTC-based tools fail because of corporate firewall rules, the typical symptom is the connection appearing to start, then hanging at "connecting" indefinitely. ICE is attempting connectivity checks that are failing, but the application has no way to surface this clearly to the user.

This is the dominant practical problem. Users have access to multiple "nearby file sharing" tools, and across the various network configurations they encounter, none of them work reliably. The tools that work on their home network don't work at the office. The tools that work in the office don't work at the conference. Users develop folk knowledge - "AirDrop only works between Apple devices," "you have to be on the same WiFi for that one" - but there is no general-purpose tool that just works regardless of network topology.

What architecture would actually solve this?

Stepping back from the specific failure modes, the underlying issue is that all of these tools share an assumption: that proximity transfer requires the two devices to discover and address each other on a shared network. AirDrop and Quick Share assume direct radio range. mDNS-based tools assume a shared subnet. WebRTC tools assume traversable NAT and permissive firewall rules.

A tool that does not require any of these assumptions would have to abandon the idea that the devices need to communicate with each other on a network at all. Each device would have to reach a shared point on the public internet - a server - independently, using whatever internet connection it has. The "nearby" property would have to come from a different mechanism entirely.

This implies a relay-based architecture. The sender uploads the file to a relay server reachable from the public internet. The receiver, also reachable from the public internet, downloads the file from the same relay. Network topology between the two devices is irrelevant; only each device's independent ability to reach the relay matters.

But a naive relay-based architecture has two obvious problems.

The relay sees the file. Conventional relay-based transfer (like email attachments, WeTransfer, Dropbox) hands the file to the relay in plaintext. The relay can read it. Server compromise exposes everything that's in flight.

There's no proximity property. The whole point of "nearby file transfer" is that the sender wants to share with someone specific in the room, not with everyone on the internet. A simple relay link can be forwarded to anyone, removing the proximity guarantee that AirDrop and Quick Share provide.

A complete architectural solution has to address both. The first problem is solved by end-to-end encryption with the relay holding only ciphertext - a well-understood pattern. The second problem is harder because it requires some channel by which the sender can give the recipient (and only the recipient, and only in the room) the cryptographic key to decrypt the file.

The interesting question is what that side channel should be.

A QR code displayed on the sender's screen is one option. The recipient scans it with their camera. This works but requires the recipient to point a camera at the sender's screen, which is awkward in many settings.

A Bluetooth handshake is another option, but it inherits all the pairing problems that made Bluetooth-based file transfer painful in the first place, and it doesn't work on many corporate networks where Bluetooth is disabled by IT policy.

A short code typed manually is the approach Magic Wormhole takes. It works but requires both users to be running the same software and is awkward for non-technical users.

A URL fragment containing the key, the approach taken by phntm.sh and similar tools, is elegant but has subtle vulnerabilities - analytics scripts can leak fragments to servers, and the user has to share the URL through a channel that itself doesn't compromise the key.

Acoustic transmission of the key - the approach chirpfile uses - is a less obvious option but has unique properties no other side channel can match. Sound has a physical envelope that doesn't extend much beyond a single room. The key cannot be received by anyone outside that envelope. This makes physical presence in the same room a cryptographic requirement, not a policy claim. The mechanism is detailed in our acoustic data transmission guide and security model.

Each of these side channels has tradeoffs. None is universally best. But all of them, combined with end-to-end encryption and a public-internet relay, share the property that they decouple device-to-device communication from network topology - which is the assumption every existing proximity transfer tool fails on.

Comparing the approaches

The bottom row of the table represents the architectural combination that solves all four problems simultaneously: works across any network configuration, works across any OS combination, never exposes plaintext to the relay, and provides a meaningful physical-presence guarantee. As far as we know, no other production tool combines all four properties through any mechanism.

This is not a claim that acoustic key delivery is the only valid answer to the cross-network proximity problem. It is a claim that the architecture type - encrypted relay plus out-of-band key delivery via a side channel with a physical envelope - is the only architectural answer that works generally. The specific side channel can vary.

What this means in practice

For the user, the practical implication is that no current "nearby file transfer" tool works reliably across the full range of network situations they will actually encounter. AirDrop fails on cross-platform. Quick Share fails on cross-platform. Snapdrop and LocalSend fail on cross-network. WebRTC tools fail on restrictive networks. Email and Drive expose plaintext to a third party.

A tool that works in all these situations has to be architecturally different from all of them. Specifically:

• It cannot rely on direct radio protocols, because those fail across networks
• It cannot rely on mDNS or other local-network discovery, because that fails across subnets
• It cannot rely solely on WebRTC peer connections, because those fail in restrictive corporate environments
• It cannot upload plaintext to a relay, because that fails the privacy requirement
• It cannot share keys through the same channel as the data, because that defeats the encryption

The architecture has to combine an end-to-end encrypted relay with an out-of-band key delivery channel that is physically constrained to the immediate vicinity. Several side channels can serve this role; acoustic transmission has the property that it requires no special hardware, no pairing, and no shared network - just a speaker and a microphone.

Conclusion

The cross-network file transfer problem is not a missing feature in any existing tool. It is a structural property of how every existing tool was architected. Each one was designed around an assumption that breaks in the configurations users actually encounter most often.

Solving the problem requires abandoning those assumptions. The two devices do not need to discover each other on a network. They do not need to be in the same broadcast domain. They do not need to traverse each other's NAT or coexist on the same VLAN. They only need to each independently reach a relay on the public internet, plus a side channel for the key that has a physical envelope.

This architectural shift is small to describe and significant in its consequences. It is also the only way we know of to build a proximity transfer tool that genuinely works across all the network configurations users encounter in 2026.

References