|
|
|||||
Mobile apps and the quiet handling of dataThere's considerable difference in how PC software and mobile apps handle data.
Fifteen years later, the European Union has leapt into action and is now keen to enforce legislation in this area (despite a last-minute reprieve for the UK). As cookies are clearly defined and limited in scope, they make a good attack surface for legislators. The Internet, and mobile in particular, have moved on a bit in the last 15 years, however. Mobile apps, scattering dataI would happily predict that even in 20 years there will not be a 100% reliable, always-on, cheap wireless broadband option. So unless you reside in Mountain View, Calif., luxuriating in virtually unlimited mobile data connectivity, I think you're going to find living 100% on the mobile web to be a pretty miserable experience. Conversely, it will be harder and harder to find examples of apps on mobile devices that do not benefit from connection to data networks. So, unfortunately for the legislators, the once-clear boundary between device and service continues to blur and morph. Software and data on iPhones and other devices are going to remain smeared across devices, the open web, and various other data services. Let's look at how this currently works. Unique Device Identifiers (UDIDs)To track a user across multiple apps you'd need some way of putting a unique tag on each device so that no matter which app read it, you'd know you had the same person. This is precisely what the Unique Device Identifier (UDID) number on iOS devices can do. It's easily available to the writer of an app, and it cannot practically be changed or deleted. These UDIDs allow developers to link data collected by different apps. (Interestingly, as the UDID acronym gets bandied about it will probably become irrationally feared.) Apple forbids the sharing of this data between companies, but within a company there is no effective means of preventing this. The Shared Keychain in iOS allows apps published by a single developer to share data if they find themselves installed on the same iOS device — no network required. Here's a theoretical example of how this might apply to apps from an insurance company:
Data access to the Internet, with local storage on the deviceThe elephant in the room when talking about data protection is the fact that any app can silently connect to the Internet and send and receive data to its heart's content. Developers are encouraged to show a spinner to indicate that the network is being accessed, but this is a guideline rather than an enforced requirement. This is not all about tracking users, of course. These capabilities allow things like remote throttling of app usage, enabling of new features, binding of sponsor data to parts of the app, updating media in the app, syncing with other services, etc. As there is no clear way to identify personal or tracking data within the app's local storage, any focused privacy legislation will be tricky. The bottom line is that your iPhone apps are increasingly likely to be using a full set of web services without you ever setting up accounts, accepting terms and conditions, logging in or even being aware of it. Apple Push Notification Service (APNS)One of my personal favorites in terms of potential unexpected consequences is the Apple Push Notification Service (APNS), which allows developers to remotely pop up messages on iOS devices, or add badges with numbers to the icons of their apps.
When you installed "Angry Birds," Rovio explicitly asked for your permission to play sounds from Angry Birds on your phone whenever they like. As an aside — If you're looking for true Internet notoriety, then gaining control of Rovio's servers would allow you to remotely command all iOS devices with Angry Birds installed to "tweet" (audibly, not via Twitter) in unison. Data handling on PCs vs. data handling on mobile appsGiven all that's happening right now, how are we doing on transparency and consent? Let's compare some of the warnings and alerts you might get from three different use cases: Case 1: Installing software on your PC that uses data on the Internet
And when you run your new PC-based software:
Case 2: Accessing a website through a PC
Case 3: Installing an Internet-enabled app on your iPhone
Some final thoughtsThe comparison between PC-based software and smartphone software shown above is stark, with many implications. There's a lot to work out, and there's a lot to debate. With that in mind, here's a few discussion points I think are worth exploring:
Related:
|
|||||
© 2012, O'Reilly Media, Inc. (707) 827-7019(800) 889-8969 All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. |
|||||
The web was never designed to be personal. Until 
That's all relatively straightforward, but there is also the ability to make the iPhone play any audio file included in your app, whether the app is open at the time or not. Check the push permissions for "Angry Birds" for an example (Settings > Notifications).
Comments: 10
Richard [26 May 2011 08:54 AM]
You're glossing over a lot of the details here. To install the app I have to authorize it by entering my password. If the app tries to use alerts, or use the camera, or use my location, it has to ask for my permission. I can view which apps have used my location. I can view which sites have set databases. I can't view cookies, but I can clear them. If I'm using an app for a site that requires a login, I have to set up the account first, which would likely have the same steps you've listed.
I'll agree with you that there's some potential for harm here, but ignoring the finer details to meet your theory doesn't help anyone.
Peter [26 May 2011 09:03 AM]
Hi Richard,
Thanks for the comment.
You're right that there are more details to this. There are clearly things that the iPhone can do that do require specific authorisation (e.g. location services), but there's a lot that doesn't require this.
I found it interesting that with the Apple notifications there is explicit consent required, but as this is collected once usually when the app first opens it can be a while before it is finally used (e.g. the very simplistic Angry Birds example in the article), and often the user won't really be aware of what giving their consent allows the app to do.
It's also the case then when you trust a company you tend to just accept whatever comes up - this is particularly true if you look at EULAs when you install software. Most people don't read them or worry too much about them.
It's not all about the harm, either, as there are great things you can do with the relative lack of restrictions.
I do agree with you about the fine details, but I was aiming at 1000 words with a view to being able to pick up the details in the comments below ;-)
Best wishes
Peter
p.s. yes - you do need to type your password in to download from the app store, but even there there are finer details, like only having to type it in once to download updates to 10 apps, each of which could have completely changed their functionality since the last version... but that's yet another story.....
Peter [26 May 2011 09:13 AM]
Hi Richard,
Forgot one thing in my reply above. When you say:
"If I'm using an app for a site that requires a login, I have to set up the account first, which would likely have the same steps you've listed."
It often works that way, but it doesn't have to work that way. With a web browser you need to create a username and login to define a unique user - you can't rely on a cookie not being deleted.
With an app on an iPhone (for exampel), if the only way of accessing that service is through the app, and your iPhone uniquely identifies its user through the UDID and other more subtle methods, then you don't need to go through setting up a username and password.
With an app you only need to ask for the email address if you actually care what the email address is, not to make the personal functionality work.
I think there really is a difference here.
Cheers
Peter
Sam Penrose [26 May 2011 09:41 AM]
Excellent work, thank you!
Baylink [26 May 2011 10:08 AM]
Well, in fact, my Android Market warns me first as to what permissions an App is going to require... and while it won't let me deny specific ones at my own peril, the way my Blackberry would, that capability is being added to the software ecosystem on Android... by third parties, something only possible because of the way Android came to be in the first place.
Peter [26 May 2011 04:14 PM]
Hi @Baylink,
Interesting about Android. Do you think that there is an Android way of approaching permissions that is distinct from both the PC and the iPhone way?
In particular, does Android allow an app two-way IP communication without an explicit acceptance?
My gut feeling is that there are a lot of apps that are possible that would surprise users in terms of data security. Once they have been built and published there might be a more informed debate about security.
Perhaps now is the time for both Android and iOS to push the privacy boundaries and find out what the current generation of users is happy with....?
Peter
doug [27 May 2011 02:02 PM]
I think that going for PC type security on mobile devices is the wrong way to approach the growing privacy issues. It has more to do with the user’s lack of knowledge and companies exploiting that lack knowledge. The average end users that I deal with do not understand internet privacy. When I get asked from average users which phone I would recommend iPhone or Android. I tell them iPhone; not that I think that it’s a better option, but because they will not understand and/or care to understand what permissions they are approving during an install on android.
In case 1 for data handling most end users don't go through that process.
What they see is:
"Accept", "I Agree", "Next", "Next", "Next", "Finish" even though there is a lot more there.
Usually the AV and firewall is either not configured right or just not on. In the case of AV usually expired.
They don't realize that they just installed Bing, Google, etc. toolbars and at the same time agreed to send them "anonymous” data. (Which probably has a UID of some kind) They don't see those two check boxes. This is the same reason the "Fake AV" or "Mac Defender" malware is so effective
It seems to me that users still don't understand why Apple storing geo location data or Google making everyones wireless routers location public ( http://samy.pl/androidmap/ ) is such a big deal.
Until users understand the permissions that they are giving to apps, they are not going to question what the app or cell phone is doing in the background or how it impacts their privacy.
Peter [28 May 2011 02:26 AM]
Hi Doug,
I think that you're absolutely right about this.
It looks to me like you have a small number of people who engage deeply with the subject and try and work out the possibilities.
Then you have a large market which is largely indifferent, making decisions in this area based on fear / desire etc. - the usual way that mass market purchasing is done.
Security messages penetrate the mass market in soundbite forms, e.g. The Internet will corrupt your children, cellphones cause cancer, the iPhone's a spyPhone etc.
In the article when I said that trust in a company might dictate willingness to accept security risks, I think it's more like political or religious allegiance. Mac vs PC, Democrat vs Republican, US technology vs Korean (cheers Steve Jobs for that one).
Convincing people to take a rational approach to online security is like trying to win a political argument using statistics.
But that could be a whole article on its own :-)
Peter
Thomas Sabo uk [31 May 2011 12:05 AM]
Thank you for sharing,I benefit a lot from it.It has more to do with the user’s lack of knowledge and companies exploiting that lack knowledge. It looks to me like you have a small number of people who engage deeply with the subject and try and work out the possibilities.Convincing people to take a rational approach to online security is like trying to win a political argument using statistics.
Thomas sabo [ 1 September 2011 10:24 PM]
It looks to me like you have a small number of people who engage deeply with the subject and try and work out the possibilities.