Internet users have grown used to the idea that they can be tracked and profiled as they browse the web, but what about the specific risks of smartphones?
With an array of sensors, GPS, cameras, and microphones, if any device could be used to monitor a person’s life, surely it would be the smartphone.
According to a study conducted by researchers at Northeastern University in Boston – titled Panoptispy just to make its readers feel uneasy as they’re reading it – the truth of smartphone surveillance turns out to be a little more complicated.
The report looked at data from 17,260 Android apps from Google Play (plus Chinese app stores Ap-pChina, Mi.com, and Anzh). The researchers then used an automated tool to identify a subset of at least 9,100 that might leak data after doing things like accessing the camera or microphone.
One cause for confusion is that even when an app developer has no interest in monitoring its users through media APIs, that doesn’t mean that third-party libraries embedded in those apps for advertising or other purposes don’t set out to do that. Plus, confusingly, apps can also request media permissions when they’re installed without ever using them, possibly because they needed this in older app versions, but developers never changed that setting.
Not to mention that:
The mapping between Android permissions and their associated API is surprisingly poorly documented, potentially leading to developer confusion.
From this you start to get some idea as to why this sort of detailed study into what our apps get up is tough to carry out – if the developers don’t even know what they’re asking for, working out how permissions and APIs are being abused becomes trickier.
The good news is that of the more than 17,000 apps analysed, in only “a few instances” were apps found to be recording video, images or sound covertly (that is unexpectedly and without the user being aware) and sending them back to the app’s maker or a third party.
Even apps that do this appear to do so out of a misplaced understanding of privacy rather than any maliciousness – for example a delivery app called GoPuff was discovered to be sending screen recordings in order to better understand how users were interacting with it.
Another included an API, TestFairy, that took 45 screenshots without permission, supposedly to aid beta testing not disclosed to anyone installing it.
Less positive: the analysis uncovered the chaotic nature of what app and API developers can get away with if they want to, and how poorly regulated this is via Android’s permissions architecture:
We also find that there is poor correlation between the permissions that an app requests and the permissions that an app needs to successfully run its code.
Google might argue that it’s working on the issue, but we’re now nearly a decade into Android’s commercial existence and the issue remains unresolved (the analysis didn’t look at iOS, which will be analysed in a separate study).
In conclusion, it’s all a bit of a mess. Arguably one of the platform maker’s own making – a legacy of the ‘build it quickly and they will come’ philosophy that for too long has seen privacy as a retrospective bolt on that could come later.
Are apps secretly watching you for nefarious purposes? On the basis of this study, no. Are they watching you in lots of other ways that are incredibly hard in some cases even for them to track? Yes.
Just adding more permissions and controls won’t solve the problem as it’s incredibly hard for any user to keep up across dozens of smartphone apps. Not that this is the answer of course – rather than passing the problem to the smartphone user to grapple with, more accountability is needed at the developer and API level.
Dan Gammon
The article talks extensively about “API’s,” but, unless I missed it, nowhere does it tell me what an API is, and why they are in my phone.
Paul Ducklin
API is short for “application programming interface” and it refers to the set of coding functions that an app uses to access feature X. In the jargon, an app that accessed the microphone might be said to “use the audio API”. Checking whether an app makes some use of an API or not (that’s usually pretty easy to do, technically speaking) is a quick way of judging what it *might* do, but not exactly what it *does* do. So if I don’t use the audio API I probably can’t listen to your microphone; if I do use it I *might* be listening in, but you would need to analyse my app in much more detail to see whether I actually did so or not.
(Here’s an analogy. If you’re buying a used car and you want to estimate how hard it’s been worked, you might check to see if it has ever had a towbar fitted. If not, you can assume it’s never been used to pull trailers or tow caravans. You have evidence of absence. OTOH, if there is a towbar fitted, it *might* have been used to drag heavy loads up steep hills, with all the concomitant wear and tear that implies…or not, but this might help you decide what to look for next. “Absence of evidence.”)