AirDrop, Quick Share and Wi-Fi Direct: How They Work and What to Set

AirDrop, Quick Share and Windows nearby sharing all work the same basic way: a short range Bluetooth signal finds nearby devices, then the file itself travels over a faster link, usually a direct Wi-Fi connection that needs no router or internet. The privacy setting that matters most is who can see you: set receiving to contacts or your own devices, and switch to "Everyone" only for the minutes you need it.

That is the short answer. The longer one matters because these features ship on billions of devices, announce something about you whenever they look for a receiver, and have been the subject of published research: the PrivateDrop work on AirDrop's contact hashes (USENIX Security 2021) and the QuickShell findings on Quick Share (DEF CON 32, August 2024). This post explains how each feature discovers and transfers, what every receive setting does according to the vendor's own documentation, what the research found and what was fixed, how organisations restrict the features, what to set before you travel, and what records a transfer leaves behind.

Key takeaways

• AirDrop uses Bluetooth Low Energy to discover and Apple-created peer-to-peer Wi-Fi to transfer, inside a TLS connection, according to Apple Platform Security. Apple describes the link as its own technology rather than as Wi-Fi Direct, and says no access point or internet connection is involved in the local transfer.
• Quick Share (previously Nearby Share) runs on Android 6 and later, Chromebooks and select Windows PCs. Its visibility options are Your devices, Contacts and Everyone for 10 minutes, which switches back to your previous choice automatically.
• Windows nearby sharing sends over Bluetooth or, on the latest Windows 11, over the same private Wi-Fi network. Microsoft warns that "Everyone nearby" exposes your PC's Bluetooth MAC address and name to devices around you.
• Since iOS 16.2, AirDrop's "Everyone for 10 Minutes" reverts to Contacts Only (or Receiving Off if you are not signed in). From iOS 26.2, iPadOS 26.2 and macOS 26.2, a stranger must also enter an AirDrop code that your device shows before a transfer goes through.
• PrivateDrop researchers at TU Darmstadt showed in 2021 that AirDrop's hashed phone numbers and email addresses could be recovered by a nearby stranger. In January 2024, a Beijing forensic institute reported using AirDrop data in device logs to identify senders.
• Security researchers reported ten Quick Share vulnerabilities to Google in January 2024. Google fixed all of them and issued two CVEs, then fixed a bypass of one fix, which the researchers published in April 2025.
• Organisations can disable AirDrop on supervised iPhones and on Macs, block Wi-Fi Direct and outgoing Bluetooth sharing on managed Android devices, and must test Windows controls on a pilot group.

A dated timeline of wireless file sharing and its research

Dates below come from the vendors' own pages and the researchers' own publications. Where a source gives only a month or a version number, the table says so.

How AirDrop, Quick Share and Windows nearby sharing discover and transfer

All three features split the job into two phases. Discovery has to be cheap enough to run on a battery and short range enough that "nearby" means nearby, so it uses Bluetooth. Transfer has to be fast enough for a video, so it uses Wi-Fi. The privacy questions mostly live in discovery, because that is when your device either says something about you to strangers or stays quiet.

AirDrop

Apple's Platform Security guide describes AirDrop in more detail than any other vendor describes its equivalent. When you sign in to iCloud, the device stores a 2048-bit RSA identity. When you turn AirDrop on, the device creates an "AirDrop short identity hash" derived from the email addresses and phone numbers on your Apple Account.

When you pick AirDrop in a share sheet, your device broadcasts a Bluetooth Low Energy signal that includes your short identity hash. Apple devices nearby that are awake and have AirDrop on hear it. What happens next depends on the receiver's setting:

• In Contacts Only mode, the receiver compares your short hash with hashes of people in its Contacts app. If there is a match, it answers over peer-to-peer Wi-Fi with its own identity information. If not, it stays silent.
• In Everyone mode, the receiver answers even when there is no match.

The sender then opens a peer-to-peer Wi-Fi connection and sends a long identity hash. If that matches a known contact on the receiver, the receiver answers with its own long hashes, and once verified, the sender sees the receiver's first name and photo from Contacts. Devices that cannot be verified appear with a silhouette and their device name, the one set in Settings, General, About, Name, under "Other People".

When the sender picks a recipient, the two devices open a TLS connection and exchange iCloud identity certificates, which each side checks against its Contacts. The receiver is then asked to accept the transfer. Apple says the Wi-Fi radio talks directly between devices "without using any internet connection or wireless access point". Apple's user guides add two practical details: the devices should be within about 30 feet (10 metres), and if you walk out of Bluetooth or Wi-Fi range after a transfer starts, it continues over the internet. You can stop that from using mobile data with Settings, General, AirDrop, Use Cellular Data.

Quick Share

Google's help page describes Quick Share from the user's side rather than at protocol level. You open it from the Share menu, the Quick Settings tile or the Settings app. The sender picks a nearby device, and the receiver taps Accept or Decline. Google's troubleshooting steps say Bluetooth must be on, suggest bringing devices within 1 foot (30 cm) of each other, and note that on Android 12 or earlier Location must be on, which reflects how Android ties Bluetooth and Wi-Fi scanning to location permission on older versions.

Google's page does not list the radios. The QuickShell researchers describe Quick Share as using Bluetooth, Wi-Fi, Wi-Fi Direct, WebRTC and NFC depending on the devices and conditions, with its own application layer protocol on top. Google's page also documents an option that does not stay local at all: when sending by QR code to an iPhone, iPad or Mac that lacks AirDrop interoperability, files are end-to-end encrypted, uploaded to Google servers and kept available for download for 24 hours, with limits of 10 GB per 24 hours, 1,000 files per session and 20 receivers at a time. Both devices need internet access for that path.

Windows nearby sharing

Microsoft's support article describes nearby sharing as a way to send documents, photos and links to nearby PCs "by using Bluetooth or Wi-Fi". On the latest Windows 11, a PC can share over Wi-Fi if the receiving PC is on the same private Wi-Fi network; otherwise it uses Bluetooth. Both PCs must turn the feature on under Settings, System, Nearby sharing (Settings, System, Shared experiences on Windows 10, version 1803 or later). The receiver chooses Save or Save and open when the notification appears. Microsoft does not describe a peer-to-peer Wi-Fi link for this feature, which is the main architectural difference from AirDrop and Quick Share.

What Wi-Fi Direct is and how these features use it

Wi-Fi Direct is a Wi-Fi Alliance certification programme that lets devices "create their own Wi-Fi networks without an internet connection", in the Alliance's words. There is no access point. One device takes the role of group owner, a little like a temporary router, and others join it. The Alliance lists three things it enables: devices connecting directly, either one-to-one or as a group of several devices at once, and the ability to see available devices and send or accept invitations to connect.

On Android, apps reach Wi-Fi Direct through the Wi-Fi P2P framework. Android's developer documentation describes the WifiP2pManager class with methods to discover, request and connect to peers, and notes that the link works "across distances much longer than a Bluetooth connection". Apps that target Android 13 (API level 33) or later must declare the NEARBY_WIFI_DEVICES permission for peer discovery and connection; earlier versions required fine location permission. So an app that only wants a nearby printer no longer has to ask for your location.

The Alliance also certifies Wi-Fi Aware, for infrastructure-free discovery, with privacy features such as periodically changing over-the-air identities, and TDLS, which lets two clients on the same network talk directly.

Of the three sharing features, only Quick Share is documented (by the QuickShell researchers' protocol analysis) as using Wi-Fi Direct. Apple calls AirDrop's link "Apple-created peer-to-peer Wi-Fi technology" and never says it is Wi-Fi Direct, and Microsoft describes Bluetooth or the shared local network.

A side effect matters for travellers: while a peer-to-peer link is up, your Wi-Fi radio is talking to another device, not just to your access point. The QuickShell research showed why that matters. One of the flaws Google fixed (CVE-2024-38271) let a remote device force a lasting Wi-Fi connection, which the researchers described as a key building block of their chain.

The spec comparison table

This table describes what each vendor documents. Where a vendor does not document something, the cell says "not documented" rather than filling a gap from memory.

The 1 foot figure for Quick Share comes from Google's troubleshooting advice, not a stated maximum range, so read it as "how close to stand when it is not working" rather than as a limit on how far a device can be seen.

What the receive settings do on each platform

AirDrop on iPhone and iPad

Open Control Center, touch and hold the top-left group of controls, then tap AirDrop. The choices are:

• Receiving Off. Your device does not answer discovery. You can still send.
• Contacts Only. The default, according to Apple Platform Security. You appear only to senders whose phone number or email is in your Contacts, and they need your Apple Account email or phone number on your contact card for it to work in the other direction.
• Everyone for 10 Minutes. Any nearby Apple device can see you and send a request. After 10 minutes it changes back to Contacts Only if you are signed in to an Apple Account, or to Receiving Off if you are not.

On iOS 26.2, iPadOS 26.2 and macOS 26.2 or later, there is an extra step for strangers. If someone not in your contacts tries to send you something, you can choose to continue, and your device shows an AirDrop code. The sender types that code on their device to complete the transfer. After that, the sender is added to an "Other Known" list in your Contacts for 30 days, during which they can share with you without a new code. To end that early, open Contacts, find the person in Other Known and select Forget This Person.

Two more behaviours are worth knowing. Items sent between devices signed in to the same Apple Account are accepted automatically. And if a child's device receives or tries to send certain sensitive content, Communication Safety can warn the child, blur the content and offer resources.

AirDrop on a Mac

Click Control Center in the menu bar, then AirDrop. Apple's Mac guide lists Contacts Only or Everyone. In Finder, AirDrop also appears in the sidebar, and incoming requests show there rather than in Notification Center when that window is open. Some received items go straight to Downloads; for others, macOS asks where to save. The Mac guide does not describe the 10 minute timer for the Mac's Everyone option, so check yours after use rather than assuming it reverts.

Quick Share on Android

Open Settings, search for Quick Share, then tap "Who can share with you". The choices are:

• Your devices. Your device stays visible to your other devices signed in to the same Google Account, even with the screen off.
• Contacts. While your screen is on and unlocked, you are visible to nearby contacts.
• Everyone for 10 minutes. Google says that, "to protect your privacy", visibility switches back to your previous selection after 10 minutes.

There is also Receive mode on the Quick Share page. While you are on that screen, your device is visible to anyone nearby. Leaving the screen ends it. To receive from someone else, your screen must be unlocked. Transfers between devices on the same Google Account are accepted automatically, and clipboard content shared between your own devices is copied automatically. Samsung Galaxy devices with One UI 2.1 or later can have different settings; Google points those users to Samsung's own page.

Windows nearby sharing

Open Settings, System, Nearby sharing, and choose between off, your own devices (signed in with the same Microsoft account) and Everyone nearby. Microsoft's note on Everyone nearby is unusually frank: your PC's Bluetooth MAC address and name are made available to devices around you, and "this info could be used to link your PC to you". The same page lets you change where received files are saved.

Why did Apple limit "Everyone" to 10 minutes?

Apple's support pages document the behaviour, which arrived in iOS 16.2, but do not explain the reasoning. What the change does is easy to state. Before it, a phone set to Everyone stayed open to every nearby stranger until its owner remembered to change it back. After it, an open window closes itself, so the risky state is temporary by design. Google uses the same pattern for Quick Share's Everyone option and gives its reason directly: it switches back "to protect your privacy".

A permanent Everyone setting causes two problems. A stranger in a train carriage or lecture hall can send unwanted images to anyone left open, and the person still sees the request even if they decline it. And an Everyone device answers discovery from anyone, which shows its device name and, as the PrivateDrop research below explains, can expose more. The iOS 26.2 AirDrop code adds a second gate, so even within the 10 minute window a stranger cannot complete a transfer without a code your device displays.

What the PrivateDrop research found about contact hashes

The PrivateDrop paper, by Alexander Heinrich, Matthias Hollick, Thomas Schneider, Milan Stute and Christian Weinert of TU Darmstadt, appeared at the 30th USENIX Security Symposium in 2021. Its abstract says AirDrop is integrated into "more than 1.5 billion end-user devices" and reports "two design flaws" that let attackers learn the phone numbers and email addresses of both sender and receiver.

The root cause is the contact check described earlier. To decide whether two people know each other, AirDrop exchanges hashes of phone numbers and email addresses. Hashing hides a value only when the set of possible inputs is too large to try. Phone numbers are a small, structured space, so a hash of one can be reversed by computing hashes for every plausible number in advance. The researchers note that recovering phone numbers takes milliseconds with known techniques, and that email addresses fall to dictionary guesses based on common formats.

The two flaws, at the level the researchers describe them publicly:

1. Sender leakage. A sender always includes its own hashed identifiers when it looks for receivers. Anyone nearby with a Wi-Fi capable device can collect them by waiting for a target to open the share sheet, then recover the values offline. The researchers say this was also independently published in July 2019, shortly after their May 2019 disclosure to Apple.
2. Receiver leakage. A receiver answers with its own hashed identifiers if it knows the sender. A widely known person, the researchers' example is a company manager, could therefore learn the private contact details of everyone who has that person in their address book.

The researchers' fix, PrivateDrop, replaces hash exchange with private set intersection, a cryptographic method that lets two parties learn whether they share contacts without revealing the rest. Their iOS and macOS prototype added an authentication delay "well below one second", and they shared it with Apple in October 2020. As of 20 April 2021, they wrote, Apple had not indicated it was working on a fix, and the only self-protection was to disable AirDrop discovery and avoid opening the share sheet.

In January 2024 the researchers added a third item to their site. A Beijing forensic institute had reported, and international media covered, that it identified senders of "inappropriate information" by extracting hashed contact identifiers from log files on receiving devices and reversing them. The researchers verified that such logs can be collected with Apple's sysdiagnose feature from an unlocked device, and that the logs hold partial hashes of 40 bits each, which can produce a few candidate matches rather than a single answer.

What has changed since? Apple's Platform Security page on AirDrop, dated 18 February 2021, still describes short and long identity hashes. The 10 minute limit and AirDrop codes reduce how easily a stranger can interact with you, but no Apple page fetched for this post says the hash design was replaced. Treat contact hash exposure as a residual risk whenever you open a share sheet in a crowd.

What implementation flaws have been reported in Quick Share, and were they fixed?

Two security researchers presented "QuickShell" at DEF CON 32 in August 2024 and published their write-up on 10 August 2024. They chose Quick Share for Windows because it was Google's first native Windows app handling so many protocols, because much of its code is in an open source repository, and because it might come pre-installed on many new PCs.

By fuzzing the protocol, they found ten vulnerabilities: unauthorised file writes in Quick Share for Windows and for Android, a forced Wi-Fi connection on Windows, a directory traversal on Windows, and six denial of service bugs on Windows. They reported them to Google in January 2024. Chained together, some of the flaws allowed code to run on a Windows PC with Quick Share installed. This post does not describe the chain.

Google reproduced and fixed all ten and issued two CVEs: CVE-2024-38271 for forcing a lasting Wi-Fi connection and CVE-2024-38272 for bypassing the file approval dialog on Windows. Google's statement, quoted by the researchers, said the vulnerabilities had not been exploited in the wild to its knowledge and that fixes apply automatically.

That was not the end. In follow-up work published on 3 April 2025, the researchers reported issues with two of the fixes, including a way around the approval fix that again let a file land on a user's device without consent. They reported it in August 2024, Google fixed it and issued CVE-2024-10668, and the researchers recommended updating Quick Share for Windows to version 1.0.2002.2. Their conclusion is a useful general rule: the original fix stopped the symptom, while the root cause, writing received files to disk before approval, was left in place.

Google's November 2025 post on AirDrop interoperability says the new layer is written in Rust to remove memory safety bugs in code that parses data from other devices, that files still need your approval, and that an independent penetration testing firm assessed it. Those are Google's statements; no independent public research on that layer was found for this post.

Do these features work across platforms now?

Partly, and only on specific devices. According to Google's help page and its November 2025 announcement:

• Android to Apple, peer-to-peer. Quick Share can send to iPhone, iPad and Mac from a Pixel 8a or later and from certain Samsung, Oppo, OnePlus, Vivo, Xiaomi, Honor, Transsion and Motorola devices. The Apple user must set AirDrop to Everyone for 10 Minutes and accept the AirDrop notification.
• Apple to Android, peer-to-peer. Receiving from Apple devices is supported on Pixel 9 or later (excluding Pixel 9a) and the same set of other makers, with Quick Share visibility set to Everyone for 10 minutes or in Receive mode.
• Android to Apple, without AirDrop support. The QR code path uploads end-to-end encrypted files to Google servers for 24 hours.
• Contacts Only across platforms. Not supported. Google says it works with AirDrop's Everyone for 10 minutes mode and that it would welcome working with Apple to enable Contacts Only "in the future".

Apple's AirDrop pages describe sharing with "nearby Apple devices" and do not mention Android, so the cross-platform details above come from Google. Cross-platform sharing always needs the open mode on at least one side, which is where the 10 minute timer earns its keep. Google advises confirming the other person's device name in person before sending.

Windows is separate. Windows nearby sharing works between Windows PCs. Android to Windows sharing uses Google's Quick Share for Windows app, which is the app the researchers studied.

How enterprise policies restrict them

Apple devices

Apple's device management schema for the restrictions payload (com.apple.applicationaccess) defines allowAirDrop. Set to false, "the system disables AirDrop". On iOS it was introduced in iOS 7.0 and requires a supervised device; on macOS it applies from 10.13. It is not available under User Enrollment, the lighter enrolment used for personally owned devices, so a bring your own device programme cannot switch AirDrop off this way.

A second key, forceAirDropUnmanaged (iOS 9.0 and later), treats AirDrop as an unmanaged destination. That fits a managed open-in policy: work documents in managed apps cannot be AirDropped out, while the user keeps AirDrop for personal photos. A minimal profile fragment looks like this:

<dict>
  <key>PayloadType</key>
  <string>com.apple.applicationaccess</string>
  <key>PayloadIdentifier</key>
  <string>com.example.restrictions.airdrop</string>
  <key>PayloadUUID</key>
  <string>REPLACE-WITH-A-UUID</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
  <!-- Supervised iOS and macOS 10.13+: turn AirDrop off -->
  <key>allowAirDrop</key>
  <false/>
  <!-- Alternative for managed open-in: keep AirDrop but treat it as unmanaged -->
  <key>forceAirDropUnmanaged</key>
  <true/>
</dict>

Use one or the other, not both, depending on whether the goal is "no AirDrop" or "no work data over AirDrop".

Android devices

Android does not expose a Quick Share switch in the platform's user restrictions reference, but it does expose the radios and channels Quick Share relies on. From the UserManager reference:

• DISALLOW_WIFI_DIRECT (API level 33): prevents all users from using Wi-Fi Direct. Only a device owner, or the profile owner of an organisation owned managed profile acting on the parent profile, can set it.
• DISALLOW_BLUETOOTH_SHARING (API level 26): disallows outgoing Bluetooth sharing. Set by a device owner it applies globally.
• DISALLOW_NEAR_FIELD_COMMUNICATION_RADIO (API level 35): turns NFC off and stops it being turned back on in Settings.

A device policy controller app would apply them like this:

val dpm = context.getSystemService(DevicePolicyManager::class.java)
val admin = ComponentName(context, MyDeviceAdminReceiver::class.java)

// Requires device owner, or org-owned managed profile acting on the parent profile
dpm.addUserRestriction(admin, UserManager.DISALLOW_WIFI_DIRECT)
dpm.addUserRestriction(admin, UserManager.DISALLOW_BLUETOOTH_SHARING)

Most organisations set these in their device management console. Quick Share also has cloud and other paths, so test what still works afterwards.

Windows PCs

Microsoft's support article covers the user setting but not an admin control. Microsoft's privacy documentation for managing Windows connections lists a Group Policy, Computer Configuration, Administrative Templates, System, Group Policy, "Continue experiences on this device", backed by a registry value EnableCdp under HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System, as part of the shared experiences controls. That page does not say in so many words that it disables nearby sharing, so apply it to a pilot group and confirm that Settings, System, Nearby sharing is greyed out before rolling it out. To check what a machine currently has:

# Read the policy value if it exists (no output means the policy is not set)
Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\System' -Name EnableCdp -ErrorAction SilentlyContinue

Treat the separate Quick Share for Windows app like any third party desktop app: allow or block it, and keep installed copies at or above the version the researchers recommended.

What should you set before travelling or at events?

Crowded places put many strangers in Bluetooth range. A short routine:

1. AirDrop: Contacts Only or Receiving Off. Open Control Center and check. Avoid opening the share sheet in a crowd if the PrivateDrop sender leakage worries you, because that is when your device broadcasts your hashed identifiers.
2. Quick Share: Your devices or Contacts. Do not stay in Receive mode longer than the transfer takes.
3. Windows: Off or My devices only. Everyone nearby exposes your PC's Bluetooth MAC address and name.
4. Rename devices. AirDrop shows unverified devices by the name in Settings, General, About, Name. A name like "Priya's iPhone" tells strangers who you are; "iPhone" tells them less.
5. Turn off AirDrop's cellular fallback when roaming. Settings, General, AirDrop, Use Cellular Data.
6. Update before you leave. The Quick Share fixes were delivered as updates, and Google says they applied automatically. Confirm that Quick Share for Windows is current on laptops that have it.
7. Need to receive from a stranger? Use Everyone for 10 Minutes, confirm the sender's device name in person, use the AirDrop code where your device asks for one, and check that the setting has reverted afterwards.
8. Journalists and people at higher risk: make Receiving Off the default, and remember that an unlocked device can hold partial hashes of people who sent you files.

A decision table for receive settings

Step by step: check what your devices support and how they are set

The commands below read state; none of them change settings or delete data.

1. Check for Wi-Fi Direct support on Linux

# List interface modes the wireless card supports; P2P-client and P2P-GO mean Wi-Fi Direct
iw list | grep -A 12 "Supported interface modes"

# Show which wireless interfaces exist, including any p2p-dev interface wpa_supplicant created
iw dev

If you see P2P-device, P2P-client or P2P-GO, the card can take part in Wi-Fi Direct groups. On a server or kiosk that never needs this, you can disable P2P in the wpa_supplicant configuration your distribution uses (p2p_disabled=1) after checking your distribution's documentation for the right file.

2. Check Android features and Quick Share files with adb

# Does this device declare Wi-Fi Direct hardware?
adb shell pm list features | grep -i wifi.direct

# Is the device managed, and by which admin app?
adb shell dumpsys device_policy | grep -i -E "admin|owner" | head -20

# List files received through Quick Share (Google's documented location)
adb shell ls -la "/sdcard/Download/Quick Share"

The feature android.hardware.wifi.direct indicates Wi-Fi Direct support. The last command lists what has arrived through Quick Share, which Google says lands in Files, Downloads, Quick Share.

3. Check AirDrop activity on a Mac

# Show recent log lines from sharingd, the macOS process that handles AirDrop
log show --last 1h --predicate 'process == "sharingd"' --info | tail -50

# List extended attributes macOS attached to a received file, if any
xattr -l ~/Downloads/received-file.pdf

Log content varies by macOS version and much of it is redacted. The point is simply that AirDrop activity leaves records on the device.

4. Confirm settings on iPhone, Android and Windows

• iPhone: Settings, General, AirDrop shows the current mode and the Use Cellular Data toggle.
• Android: Settings, search Quick Share, "Who can share with you".
• Windows: Settings, System, Nearby sharing, plus "Save files I receive to".

5. If you build an app that shares files

If your mobile app implements its own nearby sharing, it carries the same risks the QuickShell research showed: a parser that reads data from strangers, file writes before approval and path handling. Check the dependencies that do that work:

# Android: print the resolved dependency tree for the release build
./gradlew :app:dependencies --configuration releaseRuntimeClasspath

# iOS with CocoaPods: show locked versions
cat Podfile.lock | head -60

# Scan the repository's dependencies and SBOM with Safeguard
safeguard scan --dir .

What logs or records exist of a transfer?

More than most people expect, spread across devices and services:

• The files themselves. AirDrop saves most items in the app they came from, some in Files on iPhone and iPad, and some in Downloads on a Mac. Quick Share saves to Files, Downloads, Quick Share. Windows saves to the folder chosen under "Save files I receive to".
• Device logs on Apple devices. The PrivateDrop team verified in 2024 that logs obtainable through sysdiagnose on an unlocked device contain partial hashed contact identifiers of people who sent files to that device. That is the record the Beijing institute reportedly used.
• The Other Known list. On iOS 26.2 and later, a stranger who completed an AirDrop code exchange appears in Contacts under Other Known for 30 days unless you forget them.
• Google servers, for the QR path only. Files sent to Apple devices without AirDrop interoperability are uploaded, end-to-end encrypted, and kept for 24 hours. Google says the peer-to-peer AirDrop interoperability path does not route data through a server and does not log shared content.
• What is not documented. None of the vendor pages fetched for this post describes a user-visible transfer history inside AirDrop, Quick Share or Windows nearby sharing. Do not tell users there is an audit log to consult.

Common mistakes

• Leaving AirDrop on Everyone on a Mac. The 10 minute revert is documented for iPhone and iPad. Check the Mac after use.
• Assuming Contacts Only means invisible. It means you do not answer strangers. Your device still broadcasts your hashed identifiers when you open the share sheet, and still answers people who have you in their contacts.
• Assuming AirDrop is Wi-Fi Direct. Apple calls its link Apple-created peer-to-peer Wi-Fi. A control that blocks Wi-Fi Direct on Android does nothing for an iPhone.
• Staying in Quick Share's Receive mode. It makes your device visible to anyone nearby while the screen is open.
• Turning on Everyone nearby on a work laptop and forgetting it. Microsoft says it exposes the PC's Bluetooth MAC address and name.
• Trying to disable AirDrop on personal iPhones with MDM. allowAirDrop needs a supervised device and is not available under User Enrollment. Use managed open-in controls instead.
• Treating a first fix as final. QuickShell showed a fix that addressed a symptom and was then bypassed. Keep the sharing app updated after the headline patch.
• Trusting a familiar device name. Owners set their own device names. Decline transfers you did not expect.

FAQ

Is AirDrop safe to leave on?

Yes, on Contacts Only, for most people. In that mode your device does not answer strangers, and every transfer needs your approval. Turn on Everyone for 10 Minutes only when you need it, and remember that opening the share sheet broadcasts a hash of your contact details.

Can strangers see my phone number through AirDrop?

The PrivateDrop researchers showed in 2021 that a nearby stranger could recover a sender's phone number and email from the hashes AirDrop exchanges. Apple's current Platform Security page still describes hash-based identity checks. The safest step is to avoid opening the AirDrop share sheet in crowded places when this matters to you.

What does "Everyone for 10 Minutes" do on iPhone?

It lets any nearby Apple device see you and request a transfer for 10 minutes. Then it switches back to Contacts Only if you are signed in to an Apple Account, or to Receiving Off if you are not. On iOS 26.2 and later, strangers also need an AirDrop code that your device shows.

Can I AirDrop to an Android phone?

Yes, on supported devices. Google says Quick Share can exchange files with AirDrop on the Pixel 10 family and, per its help page, on other recent Pixel, Samsung, Oppo, OnePlus, Vivo, Xiaomi, Honor, Transsion and Motorola models. The Apple device must use Everyone for 10 Minutes; Contacts Only is not supported across platforms.

Is Quick Share the same as Nearby Share?

Yes. Google's help page says Quick Share was previously known as Nearby Share, and devices that still show Nearby Share keep working. The researchers' write-up dates the merger with Samsung's Quick Share to Google's January 2024 announcement.

Were the Quick Share vulnerabilities fixed?

Yes. Google fixed all ten flaws the researchers reported in January 2024 and issued CVE-2024-38271 and CVE-2024-38272. A later bypass of one fix was fixed as CVE-2024-10668, and the researchers recommend Quick Share for Windows 1.0.2002.2 or later.

What is Wi-Fi Direct used for?

Wi-Fi Direct lets devices form their own Wi-Fi network without an access point, for file transfers, screen casting, printing and games. On Android, apps use it through the Wi-Fi P2P APIs, which from Android 13 require the Nearby Wi-Fi devices permission.

How do I turn off nearby sharing in Windows 11?

Open Settings, System, Nearby sharing and choose Off. If you only share between your own PCs, choose the option for your own devices instead of Everyone nearby, which exposes your PC's Bluetooth MAC address and name.

Can my company block AirDrop on my phone?

On a company owned, supervised iPhone, yes, through the allowAirDrop restriction. On a personal iPhone enrolled with User Enrollment, that restriction is not available, but the company can stop managed work data from being AirDropped with the unmanaged destination setting.

Does AirDrop leave a record of who sent me a file?

Yes, in device logs. The PrivateDrop researchers verified in 2024 that logs collected through sysdiagnose on an unlocked Apple device hold partial hashes of senders' contact identifiers. The received file also stays where it was saved.

Where Safeguard fits

The fit here is weak. Safeguard does not manage phones or laptops, change sharing settings or monitor Bluetooth or Wi-Fi, and nothing in the routine above depends on it. The honest connection is for teams that build software. The QuickShell research targeted a native app whose code is largely in an open source repository, and Google rebuilt its AirDrop interoperability layer in Rust precisely because parsers that read data from nearby strangers are a common source of severe bugs. If your mobile or desktop app implements its own sharing, uses a networking or file transfer library, or bundles a component like a Wi-Fi P2P helper, Safeguard can scan that repository and its SBOM, match components against vulnerability databases, rank findings by reachability and show which of your projects contain a given component and version. That is dependency hygiene for the apps around these features, not protection for the features themselves.

Fix it without waiting for upstream

Wireless sharing fixes reach you as software updates, and the sharing code on both sides of a transfer, from protocol parsers to file handling libraries, is often built from open source components. If your team ships a mobile or desktop app that sends or receives files, those components sit in your builds next to every other dependency, so the same patch discipline applies, while fixes to AirDrop, Quick Share or Windows itself still have to come from Apple, Google or Microsoft.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency and approval workflows, not phone or wireless settings. You can download Safeguard and follow the CLI docs to try them on your own projects. Related reading: Wi-Fi generations and their security, how attackers intercept network traffic, iPhone vs Samsung Galaxy security, detecting a keylogger on your phone and what iPhone Stolen Device Protection changes.

This demo is a real Android session: you send work to a computer running the Safeguard CLI, then approve the command on the phone with Allow once, Allow for turn or Deny. It is the same accept or decline habit that keeps AirDrop and Quick Share safe, applied to commands that change your code: nothing runs until you say so on the device in your hand.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. If your app bundles a file transfer or networking library with a published fix, the same approve each step flow applies to bumping it in your Gradle or CocoaPods manifest.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. For a team that ships an app with its own sharing feature, that is a quick way to scan the repository and its dependencies locally before a release.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NVD: CVE-2024-38271

• NVD: CVE-2024-38272

• NVD: CVE-2024-10668

• Apple Support: How to use AirDrop on iPhone and iPad

• Apple iPhone User Guide: Use AirDrop to send items to nearby Apple devices

• Apple Mac User Guide: Use AirDrop to send items to nearby Apple devices

• Apple Platform Security: AirDrop security

• Apple Newsroom: Mac OS X Lion Available Today From the Mac App Store (20 July 2011)

• Apple device management schema: restrictions payload (com.apple.applicationaccess)

• Google Android Help: Use Quick Share on your Android device

• Google Security Blog: Android Quick Share Support for AirDrop (20 November 2025)

• Android Developers: Wi-Fi Direct (peer-to-peer or P2P) overview

• Android Developers: UserManager reference

• Microsoft Support: Share things with nearby devices in Windows

• Microsoft Learn: Manage connections from Windows operating system components to Microsoft services

• Wi-Fi Alliance: Alternative topologies (Wi-Fi Direct, Wi-Fi Aware, TDLS)

• PrivateDrop project: Breaking and Fixing Apple AirDrop

• USENIX Security 2021: PrivateDrop, Practical Privacy-Preserving Authentication for Apple AirDrop

Last reviewed: 23 October 2026. Vendor settings, supported devices and cross-platform support change with each OS release; check the linked Apple, Google and Microsoft pages for the current behaviour.