Push Back on NameDrop Privacy Insinuations

Originally published at: Push Back on NameDrop Privacy Insinuations - TidBITS

If friends or relatives are asking or telling you about how NameDrop is a privacy risk based on Facebook posts from police departments, set them straight by explaining how it’s completely safe.


The scare tactic hype over this is nuts. I’d given up telling people it wasn’t an issue, but now I’ll point them to your article. Many thanks.

1 Like

I like that you were able to use this social media hype non-story to remind people about two excellent pieces worth reading that will actually help improve their security and privacy. :+1:

1 Like

I just came here from reading Shira Ovide’s column in the Post. Since the writer had been engaged in an extensive anti-Apple campaign lately, it was good to see this unalloyed support for this particular Apple feature.

The fears expressed in the sampling of comments I read revolved around not understanding the technology but taking the word of the “authorities” that “bad actors” were about to drain information out of our pockets and purses without our knowledge, and therefore bad Apple!!

There is public hay to be made these days by getting out ahead of legitimate security concerns. Sadly, it’s easy to appear you’re ahead by fabricating some concerns.

1 Like

With the recent revelations on tactics that police are using to spy on citizens without warrants by operating in the gray areas of current laws, it is a bit disingenous of them to be warning the public about security.

1 Like

2 posts were merged into an existing topic: Juice-jacking?

Also one to kill this FUD. Its on by default, which is a different issue I do have a problem with. But it won’t work unless you permit it. If someone is up near your iPhone, and you don’t know it, its not going to allow it. And if you see the notification, you should be skeptical that “why is this? and who is near my iphone?”. Right?
But Apple and other tech companies need to be tasked for this “Update turns features ON by default” policy. Let us, the user, determine if we want it on.


4 posts were split to a new topic: How should Apple alert users to new features

While I don’t view NameDrop as a menacing privacy or security risk, I don’t think Apple made a good decision turning it on by default without notifying users. The permission dialog box is going to confuse a lot of people when it appears for the first time, especially if it’s triggered by an unknown iPhone in a crowded place.

Similarly, I don’t think many people need to worry constantly about juice jacking. But it’s easy enough to take countermeasures to make the threat go away. When I travel I carry both a charger (obviously) and this cable:

Unfortunately, it looks like OWC no longer makes it. But I’m sure there are similar cables from other makers.

BTW, there is a long history of intelligence services doing surveillance on commercial aircraft. A classic example:

1 Like

The phones really need to be nearly touching their NFC ends (the top of the phone). I’ve seen people report confusion, though, when they see the animation on their Apple Watch if they accidentally nearly bring their phone near the watch.

My question is, do you have to authenticate first?

If someone can walk up to your phone, tap their finger on your screen, and get your contact info, that’s bad. The minimum should be that you authenticate first via Face ID or whatever you have set up.

But I haven’t confirmed this yet because everyone I know is already in my Contacts, and I’m not sure if it handles those people differently…

This doesn’t say explicity, but it does say, “To cancel, move the two devices away from each other or lock your iPhone before the NameDrop transfer completes,” which suggests to me that the phone must be unlocked in order to initiate a transfer.


Thanks for that link. And my suspicion was that authentication would be required. And I think the entire answer to whether this is safe or not hinges on that detail that I haven’t seen any press discussing.

I may try this with someone to prove it out…

Verify features the issue in today’s email. It’s discussed here, which has a few details I hadn’t read elsewhere.

1 Like

Okay, I ran some tests with a friend with an iPhone who is not in my Contacts. She seemed concerned, so I didn’t ask her to send her info. (In fact, she thought somehow I’d get her bank passwords! But I helped her pull up her “My Card” and literally all it had was her phone #, not even her name :slight_smile: . Not exactly a power user) But we got most of the way through the test nonetheless.

TLDR: it’s secure.

Here’s the flow: When you put the devices together, and you have not disabled Name Drop, your phone will glow (as the "warmup "to Name Drop) regardless of whether it’s locked.

Receiving: If your phone is locked, you still appear to be ready to accept a name drop that the OTHER PERSON may choose to send you; I cannot confirm that it won’t prompt you to unlock at the point where they actually send you something (because like I said, I didn’t want to make her hit send). But receiving is not the security risk that people are complaining about. If someone wants to send you porno stuff as a contact, then that could be an issue, but no more an issue than some random person texting you today. Either way, it’s nothing like identity theft, the real issue. Perhaps another test will give me the final answer on this, but it’s not a significant concern.

Sending: This is the test that we need the answer to, since it presents an ID theft risk. If your phone is locked, you are never presented with anything on your screen inviting your contact to be sent to the other (possibly rogue) party. There is nothing to “tap”. And in one case (the test where her phone was set up to send), her phone presented the PIN screen to have it unlocked; that’s it.

So, sending any Name Drop info is secured behind the sender’s locked iPhone. Obviously, if your phone is unlocked, there’s a lot at risk in general. But if your phone is locked, your info is safe.

I don’t think there’s anything to see here. These are not the androids you’re looking for. Move along.


That’s good info to have. I’d just add that right now, it seems the major risk of NameDrop is somebody who is confused, distracted, impatient, or careless just hits “Yes” (or whatever the approval dialog says) in response to a transfer request.

Yea, but that means they tap “Yes” when there’s a person face to face with them holding another iPhone. Is this a friend? Then the risk is low. Is it a stranger? Then who would tap “Yes” or instead say “who tf are you?? Get away!”

And for most people, the risk is contact information, which isn’t particularly confidential in most cases. I’m sure there are exceptions, but not with people who you’re going to let within an inch of your iPhone and then agree to send it to them.


… and in the situation people are freaking out over, if a stranger tried to shove his phone in your face (or into your pants) in order to make contact, I think you would notice and probably get quite angry. You wouldn’t unlock the phone and tap a confirmation button.

This reminds me of the fears from years ago claiming that crooks can read all of your contactless credit cards from a long distance away using cheap and easy equipment. People had set up all kinds of proof-of-concept experiments to underscore the danger, but in all of the years since then, I can’t remember a single news article about someone whose cards were actually compromised via that mechanism. (If it actually worked, you can be sure that criminal syndicates would have set up scanning/theft devices in crowded parts of big cities. The fact that there have been no arrests or even reports of this tells me that it doesn’t actually work.)

I agree that most people in most situations wouldn’t approve an unwanted NameDrop request. But I think the longevity and prevalence of offline and online scams that rely on greed, lust, fear, and other powerful emotions–or just simple confusion–to get victims to do things they normally wouldn’t means that NameDrop can be risky, especially with its default setting to “on”.