Desktop and laptop computers are a huge mess of lax security. A program that you install on one of these devices is allowed by its operating systems to have virtually unlimited access to everything.  Our mobile operating systems are a little more refined and most tell you, the end user, what access an application is requesting before you install it. Unfortunately, most of us don’t read those pesky permissions prompts and just say “yes” to everything. We are, however, given the chance to say “no”. Until somewhat recently that was our only option: either we accepted everything an app asked for, or we simply didn’t install the app. Then Google sneaked a new feature into Android: App Ops. And then, suddenly yanked it away.

App Permissions

When you load up Google (the search page) on your mobile device for the first time you might notice that it typically asks you to share your location. This, according to Google, lets search results be tailored better for where you are. Searching for someplace to eat, for example, will yield much more relevant results if Google can weed out restaurants more than an hour or so away from you.

Traditional applications are no different. An app that provides restaurant reviews and reservations will need access to the Internet to get the listings and reviews, and will perform much better if it knows generally where you are. It may even be able to send a text to the bistro, requesting a table for your party of four at 7:30 — if the app has been given permission to do so.

Continuing with the restaurant example, you can submit your own review, complete with photos of the place settings and to show the atmosphere of the establishment — as long as you’ve given the app permission to access your camera so you can take pictures through it.

Maybe this app even gives you the ability to call the eatery right from the app, or invite your friends to meet you there — if you’ve given it access to your dialer and address book.

As you can see, some apps have legitimate reasons to access various parts of your smartphone or tablet.

A flashlight app needing access to your exact GPS location? That’s crossing the line.

User Control

Let’s switch over to that flashlight app, shall we? If you wanted to use your camera’s LED as a makeshift flashlight (or fall back to a bright-white screen if your device lacks a sufficient LED flash), you’d image that you might need to give such an app permission to your camera (to turn the LED flash on and off again), but not much else, right? In this case, that’s not all you were giving it. You were also giving it Internet access and the ability to identify you and where you were. With these components, the app could report this information to a web server, then sell the information to whoever wanted to buy it. Which is exactly what they were doing.

In today’s Android ecosystem, the only recourse you had was to uninstall the app (or to have not installed it in the first place). That’s a disappointment, because all you really wanted to do was turn off its location awareness and disable its ability to report that back to who-knows-where.

Ultimately, the amount of information a person gives an application should be entirely within that person’s control, right? Hold that thought, we’ll come back to it in just a moment.

App Ops

Thankfully, Google started including an app that would allow you to do just that in Android 4.3. (Whether or not your OEM kept that feature around or removed it is another topic entirely.) Just as people were starting to understand what this app was, Google removed it via a “security update” called “Android 4.4.2”.

Most probably won’t even notice that it’s missing, but a certain group did: The Electronic Frontier Foundation (EFF).

“The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people’s data is being sucked through. Embarrassingly, it is also one that Apple managed to fix in iOS years ago.”

When the EFF went to Google, they were told the feature had only ever been released by accident — that it was experimental, and that it could break some of the apps policed by it. The sky, it would seem, is falling, and this is proof-positive that Google is a huge, evil empire that wants to suck the life-force from your immortal soul as payment for all the “free” stuff of theirs you’ve using for all these years.

Hold on! Put down your Holy Water and Crucifix, and let’s get to the bottom of this.

SELinux

Not long ago Google switched Android over to SELinux. In the words of the Android devlopers:

“As part of the Android security model, Android uses Security-Enhanced Linux (SELinux) to apply access control policies. SELinux enhances Android security, and contributions to it have been made by a number of companies and organizations; all Android code and contributors are publicly available for review on android.googlesource.com. With SELinux, Android can better control access to application data and system logs, reduce the effects of malicious software, and protect users from potential flaws in code on mobile devices.

“Android includes SELinux in enforcing mode and a corresponding security policy that works by default across the Android Open Source Project. In enforcing mode, illegitimate actions are prevented and all potential violations are logged by the kernel to dmesg. Android device manufacturers should gather information about errors so they may refine their software and SELinux policies before enforcing them.”

Switching to SELinux was a huge step in the right direction due to the control it offers. Depending on the implementation, SELinux can use one of three “modes”:

• Enforcing: The default mode which will enable and enforce the SELinux security policy on the system, denying access and logging actions
• Permissive: In Permissive mode, SELinux is enabled but will not enforce the security policy, only warn and log actions. Permissive mode is useful for troubleshooting SELinux issues
• Disabled: SELinux is turned off

Current versions of Android use the “Enforcing” mode of SELinux rather than the Permissive mode, which it used previously.

Why the gradual adoption of SELinux and stair-stepping up its modes? Compatibility, of course. Starting with Permissive and logging any failures or violations of the security policies gave Google and developers time to fix their code. Moving up to Enforcing is the next step in tightening the controls the operating system has over apps.

The last step will be letting the users select which permissions an app can use, and toggle them on and off at will, allowing SELinux in Enforcing mode to handle the enforcement of these policies.

What should an app do?

Therein lies the problem. Apps are developed with a manifest in place that dictates the permissions it needs to operate properly — according to the developer, of course — and operate under the assumption that access to those resources was granted. The developer made those assumptions during the development cycle because the app wouldn’t have been installed if permissions to those resources were denied.

Previously this was correct, but now, in a world where users can turn things on and off at will, well, that introduces a whole bunch of potential problems that the developer didn’t address — they didn’t need to before.

What Now?

Google likely recognized this and withdrew its app accordingly. It was the right decision — for now. Including the app in the first place may have been an innocent mistake, but it was also a shot across the bow, giving developers the time they need to update their apps to handle when permissions are revoked.

What should they do when their app is denied the ability to collect information from your address book, or access the Internet, or send a text message, or access your camera? Should a message be returned to the app that the request was blocked? If so, how should the app handle it? Should it ask you to change the settings before letting you use the app? Should it fail-over gracefully? Should it provide you with an option to buy an in-app upgrade to an “ad-free” version because you’re blocking Internet access or location information which is needed for ad serving?

As you can see, there are a lot of unanswered questions. App developers make a living by “selling” something. Sometimes they sell the app directly to you. Sometimes they sell your information or your “eyeballs” to advertisers. Being able to simply flip a switch to disable these is literally taking food out of their mouths.

Don’t get me wrong. I’m not saying that a flashlight app should have access to your most intimate information and offer it for sale to the highest bidder. I think you, the end user, should have the option to turn that behavior off. However, I also think that developer deserves a chance to “disable” their app if you cut off their revenue stream — or give you another means to purchase it. After all, just because an app is “free”, doesn’t mean you’re not paying for it.

•

What other changes are inside Android 4.4.2? How can you get some of the best features of KitKat on your older phone (without voiding your warranty)? Are you done with stock Android and want to put your faith in CyanogenMod? Luckily, Pocketnow has all that, and more!