When Apple unveiled iOS 13 back in June, one of the promises it made is that it would be cracking down even more tightly on privacy.
While a lot of the discussion on this centered on Sign in with Apple, which really is a great feature by itself, there were other changes under the hood, such as preventing apps from sneaking in their own location tracking features that worked independently of the security and privacy restrictions that Apple had put into iOS.
You see, it turns out that one of the more nefarious things that developers have apparently been doing for some time is directly accessing the Bluetooth and Wi-Fi radios in users’ devices to try and collect their own location data, bypassing the controls that Apple has put in place. Prior to iOS 13, apps could directly read the Wi-Fi and Bluetooth systems to locate other devices and access points nearby, letting the developer get a sense of your location — for instance, an app from a popular retailer might use Bluetooth to determine when you’re near or inside one of their stores, regardless of whether you have location services enabled or not.
Apple clearly caught some of these apps misbehaving, and decided that it was time to put a stop to it, since it wants to ensure its users can trust the privacy controls that have been put in place with iOS. Apple reworked the internals to tighten direct access to the Wi-Fi radio, which apps almost never have a legitimate need for, and ensure that users know when an app wants to get chatty over Bluetooth.
Asking for Bluetooth Permission
If you’ve installed iOS 13, you’ve probably already noticed that many of the apps you’ve opened since updating have asked for your permission to use Bluetooth.
You may think this is perfectly logical for apps that let you play audio — after all, you want to use Bluetooth headphones, right? Unfortunately, that’s not at all what this warning about. Bluetooth audio is handled through the iOS “Core Audio” system, and it’s a system-wide setting, meaning apps don’t need to access Bluetooth directly to play audio — they just send it to iOS and the system takes care of sending it out, whether it’s via the speaker, wired headphones, Bluetooth, or AirPlay.
The permission that these apps are requesting is for direct use of Bluetooth, which could be for any number of reasons, but should never have anything to do with simply listening to audio.
The trick, however, is trying to figure out why an app wants to access Bluetooth directly. Developers are allowed to provide custom text here to help explain the request to users, but from what we’ve seen thus far, very few have done so, in which case a generic message is shown
This will allow [app name] to find and connect to Bluetooth accessories. This app may also use Bluetooth to know when you’re nearby.
In the absence of a more specific description of what the Bluetooth access is being requested for, you may be tempted to simply hit “Don’t Allow.” This is probably the safest option if you’re at all unsure, but don’t worry, it’s not a permanent choice; if you find things aren’t working the way you’d expect, you can always toggle access on later from the Privacy section in the main iOS Settings app.
That said, even if the app isn’t telling you why it wants Bluetooth access, you might be able to figure it out just from the nature of the app.
Accessory Companion Apps
If you’re running an app that comes with a hardware accessory, it’s a safe bet that it simply needs Bluetooth access to communicate with that accessory. For example, an app for a fitness tracker, scale, digital camera, home control accessory, or even some speakers and Bluetooth headphones. Some of these apps only need Bluetooth for the initial setup — for example detecting a device so it can be paired to your Wi-Fi — while others may need it to transfer data on a regular basis.
Despite the fact that you don’t need to grant Bluetooth access to simply play audio through a Bluetooth device, apps that are designed to control settings or update firmware on speakers and headphones would need Bluetooth access in order to perform those tasks, so it’s a fairly safe bet that if you’re using an app that came with your headphones or speakers, it’s going to have a legitimate need for Bluetooth access.
Apps for retailers such as department stores, clothing stores, and even fast food chains may use Bluetooth to show promotions when you’re in their stores, or in some cases even direct you to the right aisle to find what you’re looking for.
These features are certainly useful if you want to use them, but previously if you installed the app you had no choice, and few apps really told you that they were doing this in the first place, and it seems like a pretty safe bet that most retailers were also collecting data on how often you visited their stores too. Now with iOS 13, you can deny Bluetooth access to these apps to prevent this sort of tracking.
While the first two categories are sort of obvious, there’s a third one that may have left you scratching your head, and that’s apps that use Google’s Chromecast for audio or video streaming.
Although Chromecast normally streams over Wi-Fi, there’s a “guest mode” feature that’s use to let you play content on someone else’s Chromecast when you’re visiting their house without having to join their Wi-Fi network and pair up with their Chromecast.
This feature requires Bluetooth to find nearby Chromecast devices, and it turns out that any app that includes Chromecast support uses a standard set of libraries provided by Google that triggers a Bluetooth permissions request.
Until recently, developers had no choice about this; if they wanted to offer Chromecast support in their apps, they had to use the libraries, which included mandatory guest mode support, and will therefore now trigger the Bluetooth permissions request, whether the developer likes it or not. The good news, however, is that Google has released an update to its libraries that let developers choose to disable guest mode, in which case there will be no need to request Bluetooth permissions.
Of course, guest mode is still a useful feature, and apps can simply be clear about why they need these permissions in the first place, making it more likely that users will understand what’s going on and allow the app to proceed.