Mobile app use continues to climb in enterprises worldwide, and it won’t be long before almost all employee/contractor communications take place over mobile devices. That’s why it’s such a threat to security and compliance that mobile apps have extensive access to everything on a device -- and few limitations on what those apps can share.
Apple argues that it’s already doing something about this in iOS with its app tracking transparency push. But a report in The Washington Post last week undermines the company’s promises. Why? Because Apple has been trusting app vendors to actually do what they agree to do. No one could have foreseen that blowing up.
Before we dig into the latest Apple app-data-sharing developments, there’s a bit of potentially good news coming for Google Android users. In a blog post this month, Android pledged to roll out new rules starting in December that would, by default, lock out any permissions for apps that haven’t been used in a while.
This would basically protect users from old apps they’ve forgotten, making sure that app access to sensitive device information is limited. This differs from Apple’s tack in that it doesn’t appear to rely on vendor cooperation.
“In order to work, apps often need to request certain permissions, but with dozens of apps on any given device, it can be tough to keep up with the permissions you’ve previously granted -- especially if you haven’t used an app for an extended period of time,” the blog post said.
“In Android 11, we introduced the permission auto-reset feature. This feature helps protect user privacy by automatically resetting an app’s runtime permissions – which are permissions that display a prompt to the user when requested -- if the app isn’t used for a few months.
“Starting in December 2021, we are expanding this to billions more devices,” the post continued. “This feature will automatically be enabled on devices with Google Play services that are running Android 6.0 (API level 23) or higher. The feature will be enabled by default for apps targeting Android 11 (API level 30) or higher. However, users can enable permission auto-reset manually for apps targeting API levels 23 to 29.”
The blog also went into a bit more detail on timing.
In December, “the permission auto-reset feature will begin a gradual rollout across devices powered by Google Play Services that run a version between Android 6.0 and Android 10. On these devices, users can now go to the auto-reset settings page and enable/disable auto-reset for specific apps. The system will start to automatically reset the permissions of unused apps a few weeks after the feature launches on a device.”
By sometime in the first quarter of 2022, “the permission auto-reset feature will reach all devices running a version between Android 6.0 and Android 10.”
The bad news: Android is offering no protection right away, which means app developers are rushing to download as much personal data as they can before the crackdown.
In this context, “personal data” is sort of a misnomer. Don’t get me wrong: those apps are absolutely grabbing lots of personal data. But from an IT perspective, it’s important to focus on the fact that the apps are also potentially accessing pallets of sensitive enterprise data as well.
And as long as your employees/contractors continue to communicate with clients and partners and others with unencrypted communication methods, you have problems both with cybersecurity and with compliance.
Still, mobile security advocate Ilia Kolochenko, founder of ImmuniWeb, argued that the Android move really is a positive step.
“This is a game-changer for many unwitting Android users who erroneously granted excessive permissions to mobile apps that don’t need them or even to malware,” Kolochenko said. “Many millions of non-technical users are tricked to grant dangerous permissions to adware apps or even installing malicious applications and then grant all existing permissions that may lead to a full compromise of the device.”
The first line of defense for any mobile apps should be the OS vendor checking for problems. Of course, neither Google nor Apple have been willing to spend the money needed for the staff necessary to do that. Both companies believe a lack of app security is not a deal-killer for its customers, meaning they won’t lose a lot of sales by doing the bare minimum.
They may be right. And as long as iOS and Android overwhelmingly control the mobile space, there are pragmatically no options for enterprises other than to support one or both.
Now, let’s look at the latest in the Apple world of app protection, courtesy of The Washington Post. The headline nicely sums things up: “When you ‘Ask app not to track,’ some iPhone apps keep snooping anyway.”
Here’s how the Post explains what’s going on: “…Something curious happens after you ask not to be tracked, according to an investigation by researchers at privacy software maker Lockdown and The Washington Post.
"Subway Surfers starts sending an outside ad company called Chartboost 29 very specific data points about your iPhone, including your Internet address, your free storage, your current volume level (to 3 decimal points) and even your battery level (to 15 decimal points.
"It’s the kind of unique data that could be used by advertisers to identify your iPhone, possibly letting them know what other apps you use or how to target you. In other words, it’s sidestepping your request to be left alone. You can’t stop it.”
This is phone fingerprinting, which can be alarmingly effective. It enables vendors to recognise your device when it appears on their radar. What happens when your CEO is conducting supposedly secret negotiations with a potential takeover target, or if someone is testing a device that has yet to be released?
Apple seems to fully appreciate and demand privacy for its product launches, and very much talks up its devotion to privacy. And yet it’s deeply cavalier about any other company’s secrets.
Apple told the Post it would look into the issue and work with app developers to make sure everything’s on the up and up. But after several weeks, nothing changed.