iOS 13 and Android Q show mobile OSes handle security, privacy issues better than Windows used to
Apple and Google can lock down their operating systems with much more ease than Windows. This makes our lives easier (most of the time!).
In the recent news, we’ve seen different ways various actors can access private data without users being aware. We first saw coverage around the use of Bluetooth beacons to serve targeted ads, and then, how Android apps can still access private data, even if previously denied permission.
Apple and Google are already rolling out OS updates to iOS and Android that should prevent—or at least lessen the chance—companies can do either of the above without the user’s express permission.
The response by both companies shows how mobile and desktop operating systems differ. Apple and Google are in a better position to make needed changes to their respective mobile OSes, while Microsoft has to consider legacy applications.
What have we seen? Here are two examples that got attention
In June, the New York Times published an article about how companies use Bluetooth beacons inside of stores to push targeted ads to users. The Bluetooth beacon sends out a one-way signal, and those with the retail app downloaded get served ads on items in the aisle they’re currently in.
The more worrying issue is that researchers from the University of Calgary, U.C. Berkeley, and AppCensus recently published a paper on how Android apps were using workarounds to still gain access to data users did not give them access to. Users might deny apps permission to access locations and other private data, but those apps would use side channels or covert channels to gain access anyway.
Side channels are methods that some should know about already; for example, using permissions to access your photo library to collect location data in photo metadata, or using Wi-Fi access to gather geolocation. The sneakier method is covert channels, which the researchers defined as when two entities cooperate and share data one has permission to, but the other does not. There are a few different ways to go about this. A couple examples involve using the device’s accelerometer data to fingerprint a device [PDF] or to use the same data to send/receive data between apps.
Another covert channels example involves two apps that use the same SDK. Baidu, a Chinese corporation, has a map SDK that different apps can use to help tourists, such as Disney’s Hong Kong Disneyland park app, traveling around mainland China. The SDK, however, quietly collects the device’s IMEI; this requires the user to have apps with the SDK—so not everyone needs to worry. One Android app with the Baidu SDK and appropriate permissions creates a shared stored file in the SD card that any other apps with the SDK, regardless if any have permission to access the IMEI, can read.
The above might have spurred the upcoming privacy and security tweaks coming to iOS 13, and definitely to Android Q. The only issue here is that Android doesn’t always support older devices very well, potentially leaving some users still exposed to these privacy permission workarounds. (Google is working to address this going forward in Android Q with Project Mainline.) Meanwhile, even the first-generation iPhone can use your Apple ID with 2FA.
Android Q provides:
Thanks to responsible disclosure, Google learned about the workarounds ahead of the researchers going public, but Google said they would wait until Android Q to address the issues. When Jack covered the upcoming enterprise features in the Android Q beta, he mentioned how Android was tightening up permissions. While we appreciated this news when first announced, we now have more context for why Google is addressing it now.
So, what new restrictions come to Android Q, which is slated for a third quarter release? The biggest change is that users can restrict permissions to only allow apps access location data when in the foreground (allow all the time, only when in use, and never and don’t ask again). Apps will still be able to access location data in the background, but the user can revoke this. The updated permissions will make it a little more difficult for apps to wake up and push ads to users.
Other forthcoming Android Q privacy changes:
- Limited background app usage: there’s about 12 conditions for background activity starts (e.g., “the app has an activity that was started very recently”).
- Fine-grained location and camera metadata permissions:g., apps targeting the OS cannot turn on or off the Wi-Fi, only system apps can manually configure list of Wi-Fi networks.
- Reduced access to device information:g., apps can’t see a list of contacts ordered by frequency of interaction, randomized MAC addresses, and access to IMEI and other identifiers require the READ_PRIVILEGED_PHONE_STATE permission.
- Access to files saved in external storage: apps allowed a filtered view of what’s on the SD card (e.g., Exif metadata or other media data redacted from view).
iOS 13 provides:
Similarly, the upcoming iOS 13 features several changes to privacy features, specifically focused around location. Apple highlights five changes in the iOS 13 preview:
- Core location permission changes: fine-grained permissions to let users select when apps access core location (e.g., access to location once or anytime the app is in use).
- Privacy updates for Wi-Fi and Bluetooth: API changes and new controls to prevent apps from accessing location info through Wi-Fi or Bluetooth without permission.
- App location transparency: know when an app uses your location when in the background.
- Safari anti-fingerprinting protection: this involves updates to browser font protections.
- Location controls for social media: Users decide whether location data is shared when posting an image on Twitter and other social media.
Mobile OSes can largely avoid legacy issues
Microsoft must continually consider how their updates affect the usability of legacy applications. Developers need to determine whether changing a feature for improved security could completely break an older app some organization relies on but cannot update any more.
Apple and Google, on the other hand, don’t have to worry as much about that when it comes to their mobile OSes. (Though that’s not to say it’s not something they don’t occasionally have to grapple with—such as when Apple dropped support for 32-bit apps in iOS 11.) They can more easily pivot to address workarounds developers discover to get at the data their company really wants. (One could also argue that the walled gardens of mobile OSes make it easier to address issues.)
This is an extremely simplified way of viewing the legacy situation, I will admit. And, that’s not to say Microsoft hasn’t tried to find ways of bringing apps forward with each update. We know how much effort Microsoft has put into UWP apps, various app conversion projects, and MSIX. They’re also adding the ability to access legacy web applications from one browser with Edge with Chromium.
Microsoft must acknowledge the needs of all, partially due to how long Windows has been around, while mobile OSes are still fairly young, all things considered.
