To be fair I wouldn’t necessarily expect those actions to send out a hash of my phone number, but the threat indicated by the title is definitely overblown.
I'm not sure why WiFi has to send a hash of your phone number, I thought it just prompted nearby devices to ask if they wanted to share it. Maybe there is some functionality there relating to determining if the sender is in your address book, I'm not sure.
AirDrop operates on both Bluetooth and WiFi
Try opening an ad-monetized app that requires network connection to load the ads. Make sure cellular date for that app is off. You'll get ads. Unless something has changed in the past few weeks, you should see ads load despite the fact that they should not in this scenario.
This means the Wi-Fi isn't off, isn't even in a respectful hibernate state, it's on but telling you it's off. It's your child telling you "yes mommy/daddy I'll do it right" and then cuts corners knowing you're going to trust them.
In the past few weeks my iPhone X has been having a strange Wi-Fi bug where it says it's on in the top corner of the screen, but in settings it says it's off. I didn't turn it off. When I go to turn it off, it's frozen and I have to restart settings. I'm highly suspicious it's related to Apple's Wi-Fi and Bluetooth default hibernate code or implementation of that code.
Apple screwed the pooch on this one. They should allow us to toggle the hibernate mode or long press to choose whether to go into hibernate or actually turn off, not force us to use it in a misleading way.
I've trained myself to always turn it off in settings, it's annoying, but it fits apple's product motto:
It just works.
It's fixing the annoying issue of today's AirPods failing because of something I did yesterday afternoon which I forgot.
Your phone will locate and report bluetooth ibeacons, and allow apple to update their crowdsourced location databases.
The same thing with wifi (which has the same behavior in control panel)
It would have been SO SIMPLE to have a nicer pattern. short press to disconnect, long press to turn off.
Indeed, this is exactly what I expected would happen when I long pressed and I was disappointed when it didn’t. There are definitely times like this when Apple’s UX gets more credit than it deserves.
Which is one of the reasons why I'd always leave Bluetooth/WiFi off by default, and only turned them on when I actually need them: Cut way down on the battery draw.
That option is now gone, instead the default has become "everything is always on", drawing on the battery, thus forcing you to recharge more often, cutting down on the lifespan of your battery.
Not saying that was Apple's plan all along, but it's one of the outcomes of this pointless change. When the solution to this could be as simple as "double-tapping the icon will turn it off permanently, tapping once temporary".
....No, it's really not.
You can still turn WiFi and Bluetooth off (really off) from the Settings app, and they will stay off until you turn them back on.
You can even turn them back on from Control Center.
My family loves their iPhones but I don't think anyone knows how to swipe up from the bottom to check the control panel, much less what the bluetooth symbol is and how they should reenable it if their fat-finger disabled it one day. Or how to even troubleshoot that as a possibility.
Calling it a "dark pattern" is a bit silly and dramatic. This simple feature saves users a bunch of headache.
If you want to perma-disable bluetooth, you can toggle it off from the phone options instead of the quick menu. It's a great UI trade-off.
It's not really a great UI trade-off.
It made the usability for a whole lot of users worse, all on the basis of other users forgetting what hardware they previously disabled/enabled.
Now you are forcing everybody who doesn't want BT to be always on, to always deep-dive into the options if they still want to use it for a moment. Which is something that the quick menu originally was supposed to be there for. So overall it's pretty much a step back.
Which is kinda sad, because there are more than one solutions to that which could have made everybody happy. Like giving a setting that defines the quick menu icons behavior (temporary vs permanent disable), or the ability to press to icons several times to at least toggle between temp/permanent disabled and on.
Furthermore, each AirDrop session is a TLS session, where the users exchange iCloud certificates to authenticate each other.
See: https://www.apple.com/business/site/docs/iOS_Security_Guide.... (p. 45)
The phone is only as secure as the user makes it.
You iCloud account is your identity. When you choose to share things directly from your phone, you are choosing to share that identity. How else can another iPhone verify you?
There is no information leak. This is a clickbait title combined with a 'Well, duh' moment.
With that said I agree with you that it’s an intuitive and non-serious disclosure, but it appears some disagree.
Which it to say, it sounds like you only get partial information about the sender prior to identifying yourself and establishing a direct connection. So you cannot passively identify the exact phone number of an unknown sender.
The "short identity hash" itself it says is "created based on the email addresses and phone numbers associated with the user’s Apple ID", though I have to assume that it's independently hashing each piece of info because if you hash the whole set, then the receiver would have to know the whole set, which would be a problem (my device knows more email addresses for me than any of my friends do).
If visibility is set to everyone then your phone will identify itself using its phone number so people know which device is yours and can click to share with it.
I just tested it, and with Contacts Only on both phone and laptop I'm still able to share things with myself.
How do you allow two mutually untrusted client devices to determine that they share a common 9-digit number, without disclosing the secret? And for bonus points, how do you allow this to happen without two-way communication or access to a central authority?
When an iCloud user is created, a keypair is generated. The private key is stored in the user's keychain; the public key is pushed to iCloud's server and placed in a central directory. Public keys of all of the user's contacts are cached locally on the device.
When Alice opens her phone to share something via AirDrop, it polls available devices over BTLE. The polling message contains a nonce.
Bob's device responds with a message containing two values: a nonce of his own, and a hashed+signed payload:
This approach defeats a precomputed attack by including a nonce from both parties - a rainbow can't be generated for all transactions, only this one in particular. It does not expose Bob's identity, because all that is transferred is a (random) nonce and a signed message.
The main drawback I see here is that when adding a contact, you have to download their public key from iCloud before you can share with them - so two devices cannot use AirDrop if they are not online, if they have not been online since the contact was added. As a workaround, you could set a flag when unsynced contacts are present and show a dialog if an AirDrop poll is detected before syncing occurs. In that case, you could fall back to something more closely resembling the currently implemented protocol, which would at least limit the data leakage present today to an edge case that requires explicit approval by the user.
> your phone sends out SHA256 your phone number hash to all the devices around you every time you hit Share.
In theory, this should be enough to protect your number (although it's still a fingerprinting vector). The reason it's a problem isn't because other people can see the hash -- is because it's trivial to iterate over the list of possible phone numbers and figure out which one corresponds to each hash.
So... don't use 9 digit phone numbers. I'm sure I'm missing something, but this does not seem like a hard problem, at all.
Everyone using an Apple device has an Apple account. AirDrop is not compatible with Android; so this isn't a compatibility thing. I can't think of any reason why this needs to be a hash of a phone number instead of a randomized string that's attached to your account. Airdrop is fundamentally a way for you to share files across Apple devices -- so just give them new IDs.
Yes, this means that there's a tiny amount of coordination with Apple servers that would need to happen when you add a new contact or share with a brand new phone number you've never seen before, but is anyone on here seriously going to argue that's worse for privacy than essentially transmitting your phone number in the open every time you use AirDrop?
From later in the article:
> How does your friend know that the person requesting a password is you? Broadband BLE requests contain your data, namely, SHA256 hashes of your phone number, AppleID, and email.
There's a device with a screen, right in front of you, and the screen has to be visible for you to click the share button. Your friend also needs to be right next to you so that your phone's are close enough to connect over Bluetooth.
So pick one to two randomized dictionary words, display them on the screen, and just read that out loud to your friend as confirmation.
Is there something I'm misunderstanding about how these features work? The developers at Apple aren't dumb, so I'm assuming there's some good reason for needing to use a mobile number as a device ID for a proximity-based sharing service on a tightly-controlled device.
I would just have hashes of all the numbers of all your contacts on both phones and if your hash sent over matches you have a contact. No need to phone home.
That’s what came to mind to me when I read this article. iMessage already uses per-device public key encryption, it seems like per-device UUIDs hashed with the user<->user connection could be used to make the sniffed hashes non-reversible without knowing the UUIDs of the sharing phone and one of his contacts
OR send (handshake) message encrypted with recipients phone number (put through KDF). Anyone knowing the recipient probably could be able to get your phone number, but that seems like an improvement?
The second approach isn’t how AirDrop works as a product: when you open the Share dialog, you see a list of eligible recipients (either people with open permissions OR you in their contacts list). The recipient is the one doing the identity check, so their phone number isn’t known upfront.
One downside is that it may be make targeted attacks easier (if you can guess the approximate form of someone's email address, you can easily confirm it), but that doesn't seem like much of a leak if you can already guess sufficiently closely. Sending hash(nonce+AppleID+phone number) might be an option, but that feels more limiting.
I would suggest it's because phone number is (should be) device specific, while AppleID's can be shared across devices. But now that I think about it, does anyone know if AirDrop works with iDevices that don't have a SIM? Such as the iPod Touch?
Sitting in a train or plane full of people means there’s usually 3-4 at least in range to randomly annoy with shared pictures or to force open a link in safari
works as intended I guess
sidenote: anyone know what limits there are on all things short range wireless? How many AirPods can reasonably work in a small area? How many Apple watches can unlock a mac wirelessly? How much AirDrop/short range device discovery can happen simultaneously?
Checking the status of your phone or collecting your phone number is much different of collecting information for “what happens on your iPhone”. I am downvoting this.
Worth knowing about if you're somebody important, or manage security for someone who is, but pretty far from "Everyone Knows What Happens on Your iPhone".
In addition, one (hypothetically) could use iOS state awareness in conjunction with other attack vectors to gain access: i.e., we have an attack vector to gain remote access, but it only works if the target device is unlocked.
The scope of this issue is that an unsalted SHA256 of your phone number is broadcast when you open the Share dialog with AirDrop and Bluetooth active. Your phone number is broadcast to determine whether the sending device is in the receiving device's contacts list.
The feature that causes this information leak (AirDrop) has no equivalent on stock Android, but hundreds of horrifyingly insecure apps exist to replicate it.
Google are introducing a similar feature (Fast Share) soon and we will see how it fares security wise.
This is an interesting cryptography question: how do you allow two mutually untrusted client devices to determine that they share a common secret, without disclosing the secret? And for bonus points, how do you allow this to happen without two-way communication?
Use a PAKE. Although I think they all require two-way communication.
Is that a solved problem?
How would that work? As far as I'm aware an app either needs explicit permissions (READ_PHONE_STATE) or the user gets prompted when the app requests the phone number (as shown in https://android-developers.googleblog.com/2017/10/effective-...).
Few hours later after flagging an admin has changed the title to the current one and un-flagged it. I just copy-pasted the title from the original one in the submisison without thinking much about it. In retrospect, the new title is much better.
Also as another commenter hinted, Apple has some very loyal fans.
In my experience, anti-Apple sentiment tends to get either downvoted/flagged to oblivion or upvoted through the stratosphere. I suspect it's due to Apple being a particularly polarising firm: those who like it, love it, while those who dislike it, loathe it.
In some cases, it can be possible to use E2E encryption to create a secret that is functionally impossible to discover. But even in cases where digital security is flawed, vulnerable, or outsourced to a third party, it's still valuable to us from a legal standpoint to maintain social expectations of privacy.