Permissions for installable apps: a governance issue

I’ve had some feedback on my recent mention of OutSystems Now concerning its potential security/privacy impact. As I understand it, Mobile users expect to know what an installable app can do, by reviewing its permissions and allowing or disallowing an App’s access to the hardware/software on the mobile device. The governance-related question is, does OutSystems Now drive a coach and horses through this, because it can hold and run lots of apps and will, in affect have to have a superset of the permissions needed by all of them, and any that might be added, making it rather over-powerful?

The situation seems to be that I won’t know what any particular app inside of the OutSystems Now single signon environment can do, because, for example if one app has a justifiable use for, say the camera, the app I’m installing into OutSystems Now will have too, whether it needs it for its declared function or not. OutSystems doesn’t think this will be any more of a problem than for any other Enterprise application set. A spokesperson told me: “One of the main use cases we see here is the “enterprise app store”, where employees are encouraged to download this single app as a presentation and container mechanism for all trusted enterprise apps—the list of apps presented is easily controlled by IT”. This does seem reasonable to me, with some caveats (see later).

Then there’s a related question around the customisable OSS (Open Source Software) OutSystems Now app. According to OutSystems, the major consumer use case will be to tie the OutSystems Now container to a specific app (the benefits are re-use of the rebranding and low-level and seamless device access). You can change OutSystems Now, apply your own branding and do any other customization you might want to but, at that point, it is a brand new app from the app store perspective and will need to be re-listed and validated by the target app store. Nevertheless, you can allow for multiple apps inside your new container and the same trust issues arise as with the corporate use case: do you trust the source of this app or not? If not, either do not install it, or do not grant the specific privileges that are being requested. This is the same as for any app in the app stores.

When I first met OutSystems Now I did ask whether Apple, say, was OK about having some of its its validations, in effect, bypassed, and was told “yes”.

My own view is that there is a potential governance issue here, but that it isn’t really an OutSystems Now issue. Any native/hybrid apps can be programmed to use anything on the device, but the defence against them misbehaving is that any new permissions must be agreed by the user during the upgrade. But how many device owners just say “yes” as long as the permission asked for is faintly plausible?

As installable native apps become richer in features and more powerful, won’t they all want permission to use just about “everything” in our increasingly feature-rich smartphones? I find myself being asked to allow use of location services almost every time (it seems) when I install a new app on my iPad, for example, and I usually say “yes” because I can usually see how this could be useful to me. But that “yes” isn’t very granular; it could allow all sorts of things I’d never explicitly agree to if I knew about them. There’s a huge issue around what your smartphone (or Apple) knows about you and how your privacy is protected – OutSystems’ wrapper may make the issues more obvious (and being “obvious” may even add safety), but I think they are still there without it.

I’m also not sure that having all-powerful employers’ apps on one’s phone will ever be seen as a huge issue in practice – if the alternative is having to carry a separate “employer’s phone”. Perhaps it should be an issue, and it certainly could be misused by employers, but I doubt if many employees will worry much about it, even if properly security-aware employees might (and there aren’t many of those – another governance issue). It is necessary for an employee to trust their employer, if the employer is going to ask said employee to install apps on their phone – but if you can’t trust your employer, perhaps you should find a different one.

As for the OSS customisable version of the OutSystems Now wrapper, I don’t really see it as being for multiple applets, although it could be; more as a way of reducing the work involved in getting a range of single apps accepted for the relevant AppStore. But the devil is in the detail and perhaps I’ll dig a bit deeper when I have time. If you do use it for multiple apps, you have similar trust issues as with the Enterprise use case, above, of course.

We do need more security awareness training for mobile users and perhaps we also need new easy-to-use audit tools on mobile devices, to tell us what the implications of any permissions we’ve given are and what exactly they were used for. I think that even when the user has the ability to check for themselves, during upgrade, what the app is now capable of doing, the user’s control is largely illusory in practice – and perhaps that is something that should/will be addressed as Mobile matures. After all, it only takes one valid use case to persuade a user to say “yes” to allowing the use of sound or camera recording, say, and that “yes” also allows dozens of potentially dysfunctional use cases through.