get current WiFi ssid

I understand the security concern. Please consider addressing it using a user consent dialog box and leaving the CNCopyCurrentNetworkInfo API unchanged. I think even using the existing "Allow ... to access your location while you use the app" message, while perhaps unnessarily alarming, would be fine.

Minimal effort all around?

"I strongly disagree with this. The collection of SSIDs that the user’s device associates with is a fairly accurate fingerprint of that user. Moreover, that fingerprint is persistent, correlatable between apps, and can’t be reset by the user. Those are all Bad Things™ from a privacy perspective.

I totally agree that there’s a balance to be struck between privacy and utility here, but arguing that there’s no privacy case to answer is naïve."

How is this a "fingerprint" of the user? That data contains no information about the location of that connection, only

the connection name, IP address assigned by that location and the outside IP address assigned by the host while connected. The passcode/pin

isn't readable and without some serious back tracking, only the ISP knows the actual physical location of the AP which can

be easily spoofed anyway.

Or are you telling us, that Apple is recording a lot more data than we can currently read?

Well it seems obvious that there must have been some kind of abuse of this feature, while apps collecting and combining data without user’s knowledge. Apple wants/needs to lock that door asap, we understand.

On the other hand this apparently causes considerable “collateral damage”, since in many situations it makes perfectly sense, and the user would definitely agree, that an app knows (and can display) the current Wi-Fi SSID.

The common user is very familiar with the concept of Wi-Fi SSIDs, since there are so many hotspots and the user often has to choose the right one manually.

So it’s actually very convenient, that an app can automatically detect whether or not the iDevice is connected to the right Wi-Fi, and present a proper message. In fact, the user expects that the app is smart enough to do so.

Dialog box: "This app wants access to your hotspot SSID" + privacy concerns explained in smaller text. Actions: Allow OR Reject (maybe Allow Temporarely as well). Exactly as location, calendar, photos, etc.

Yes, sure. But I would consider this to be a rather large change (entitlement, localization, …) and really don’t believe this could make it into the iOS 9 release, that the users expect to go live at the end of September.

So let‘s rather hope that Apple changes his mind and shifts this change to iOS 9.1, until an appropriate alternative is available.

Appropriate alternative? To what? Knowing the SSID of the connected wifi network is no different from knowing

the IP address or outside IP address. This is about 1 thing only, control.

Internal or external IPs aren’t directly associated to a fixed physical location unless your provider gives access to your contract and address. SSIDs, on the other hand, are directly associated with fixed physical locations unless they’re mobile wifi modems. Never mind the white vans sniffing everything they can.

I guess that’s Apple concern and reason, and they’re understandable. What’s not understandable or acceptable is simply removing the functionality and making apps suddenly crash. Allowing users to still rate the app after upgrading to iOS9 god knows how, isn’t acceptable either.

Just to add another voice to this issue, being able to get the currnet WiFi's SSID is fundamental our app.

If Apple are looking to resolve this issue before the GM, could we at least be told whether CNCopySupportedInterfaces or NEHotspotHelper is going to be the correct API for us to call, please? We need to start preparing our app now.

"How is this a "fingerprint" of the user? That data contains no information about the location of that connection ..."

Many companies (pretty much anyone who offers mapping service) own and actively maintain huge databases of BSSIDs cross referenced with GPS location: one component of every smart phone location subsystem is triangulation of BSSID that are within range. The effect being that even if a user were to opt-out of allowing an application access to Location Services they could still go around your back and access BSSID info and triangulation on their own. That's almost certainly why Apple has marked access to BSSID as a privacy risk.

Just wanted to add my concerns to the list.

I have sunk over a year into my app which relies on SSID/BSSID pairs to track access points in use by the consumer. SSID/BSSID are really all you have to differentiate networks you app works with versus any old hotspot which the iDevice decides to jump to without asking permission.

I find it somewhat ironic having spent ages adding Reachability handlers to meet usability requirements, that now when a WiFi changes I have no way of telling what I have disconnected from or randomly latched onto. Unless this is fixed I am going to have to start mapping network gateway addresses and their MACs as a possible means to identify a network. Even with that, I still lose all resolution of which access points are being used and have no label the user recognizes to display.

A workaround for Apple would be to provide a new unique identifier for a given access point which they generate from the BSSID. This would need to be the same on any device running an app with a given App or Group Id. This would replace BSSID. Not totally ideal as you can not determine the vendor (unless the first 3 bytes of the BSSID were exposed), but at least you can identify a given network access point consistently. To replace SSID, when the code tries to retrieve the BSSID replacement, iOS could ask the user for a label or let them allow the use of the SSID itself. This would offer a solution without allowing code access to either SSID or BSSID directly. They could provide these via the existing CN deprecated interface as PSEUDOSSID and PSEUDOBSSID.

I just filled in the application for NE access in case this does not get resolved. However not holding out high hopes of approval given some of the comments. "Its not the API you're looking for: move on!" seems likely.

Please Apple sort this one out and soon. At a minimum at least say ASAP what will and will not be in GM.

Just adding my concerns as well.

My application checks that the connected SSID matches a known string. If the SSID is matched then the application assumes it is connected to a Wi-Fi enabled sensor and will open a specfic TCP port for communication.

The application needs to know the SSID of the connected Wi-Fi network.

I want to add my concerns, too. We have an app that is used to control some kind of hardware, and we need to check if the user is connected to the matching WiFi network. If the ssid is not matching, we used to present an error message so that the user could change the network.

This is not working any longer and leads to a reduced user experience. Please bring back the possibility to get the SSID for the currently connected network!

Just expressing my thoughts..

This API is used in a clients app of mine to cache locally discovered products previously found via NSNetServiceBrowser (for purposes like using WOL to wake devices when they're in a deep standby mode). Obvously, without this we would lose a great feature what is quite dissapointing.

However, I am also developing a watchOS2 app for them and I wanted to use this API to give the user a little more context about why they might not be seeing products on their watch app (while discovery is taking place on the iPhone via WCSession). Without it, the user would have to waste time getting their iPhone out and heading into settings to check that they are connected to the right WiFi network (when the reason that products wern't showing up could have just been because the NSNetServiceBrowser was being slow).

While its dissapointing that the API has now been deprecated i'd like to mention that if Apple engineers do look at providing an alternative solution, it might also be good to think about including it in the watchOS2 system libraries... Because in my app for example, when the Watch isn't paired with the iPhone, we use NSNetServiceBrowser directly on the Watch but have no way to tell what WiFi network the Watch is connected to (if any!).

Thanks

[This is essentially a restatement of things I’ve said earlier but I want to make sure that it’s visible to folks just joining the thread.]

To reiterate, I think the behaviour exhibited by the current iOS 9 beta is unacceptable, and I’m hopeful that things will improve before GM. Alas, I’m not in a position to discuss The Future™, even the near future, so I can’t post specifics right now.

I realise this represents a serious level of uncertainty for you guys and I apologise that I can’t clear that up immediately.

I will continue to update this thread as things evolve.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We just applied for access to NEHotspotHelper yesterday. Hopefully we will be approved. But we will see. We used the old API to help with onboarding our IoT device - a baby health monitor.

For those that have applied for access to NEHotspotHelper, how long was the turn around before you received a response from Apple?