Learning iCloud Data Management (2014)
Part II: Using the APIs
6. Protecting the Privacy of User Data
This chapter is unlike any other in this book, and in some ways, it’s the most important chapter of all. iCloud lets people share data across all their devices. The data can also be synchronized with CalDAV and Exchange servers. This is all remarkably convenient for users because their data is wherever they want it to be.
It also brings up a host of privacy and security issues. This chapter provides an overview of the issues and the steps that you can take to implement the privacy that users expect for their data—privacy that in some cases is even required by law.
The Need for Privacy
With the newest operating systems from Apple (as well as from other vendors), the wide-open access that developers had in the past to resources, such as the local file system on a computer, is being constrained. Sandboxes for apps are such constraints, as are the limits on apps that can be installed on devices. Thus, what previously was often relegated to a footnote in a reference to developers now needs to be part of your planning from the very beginning.
As more and more people are becoming increasingly dependent on technology and more used to dealing with it on a daily basis, privacy has become a major concern. Every week brings headlines about privacy issues from somewhere in the world, and there also are headlines about proposed new legislation somewhere in the world. Yes, privacy can make it more difficult for legitimate users to use your app, but locks on doors make it more difficult for you to get into your home, yet you probably wouldn’t leave your door unlocked.
People, governments, and organizations are aware that privacy can be a key to physical safety as well as security for objects, information, and money. Wishing that it were not so and that everyone in the world respected everyone else equally is wonderful, but that is not the world we live in.
Looking at Apple’s Rules and Guidelines
Both the App Store and the Mac App Store have guidelines regarding privacy (they are described here as well as on developer.apple.com if you search for “store guidelines”). Violating these guidelines gets you a speedy rejection from the store.
The privacy sections of the App Store Review Guidelines and Mac App Store Review Guidelines (on developer.apple.com) are identical at the time of this writing. They are simple and far from unusual. Here is how Apple expresses the three key points:
Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used.
Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected.
Apps that target minors for data collection will be rejected.
If you are distributing your app through ad hoc distribution or another method that does not involve one of the stores, the rules and guidelines may not apply to you. However, that doesn’t mean that you don’t have to be concerned about privacy: laws may govern your app’s use of data, either directly or as they affect the organization for which you’re building your app.
Best Practices in App Privacy
The best practices in app privacy are not complicated. If they are not part of your standard procedures, you should start to implement them. Many of the best practices listed here are scarcely unique to Apple, but others deal specifically with issues regarding the App Store and Mac App Store.
An important point to keep in mind is that these best practices, along with specific privacy policies, change from time to time. Apple notifies developers of changes as they happen, but it is easy to miss them. The most important policy changes in all areas of the developer programs are usually highlighted at the right side of the landing page at developer.apple.com. These updates typically appear there for several months, so periodically look at them for updates.
Know What Should Be Private
As Apple uses the term privacy, they are generally referring to personal information that the user provides. However, privacy comes into play in other areas of the guidelines. The devices can collect data automatically (location data is one good example). The use of location data is governed not by the privacy section of the guidelines but by a section specifically devoted to location. However, the policy is the same: you must notify the user and obtain consent before “collecting, transmitting, or using” location data.
Device identifiers, IP addresses, and anything that can identify the user or the data has to be treated with care. And to be a responsible citizen in today’s cyber world, you need to bend over backwards. For example, we know that most people reuse passwords. Knowing that, if you ask people to choose a password, recognize that, even if you provide a warning, you may wind up with the password to their online bank account, so treat it accordingly and, if you store it, make certain that it is encrypted.
If you watch or read thrillers, you often see that it is a combination of events and data that provides the clue to the murderer or some other solution to a puzzle. That is why any data that the user enters could wind up being part of a puzzle that reveals something that should not be revealed.
Use Good Programming Style to Enforce Privacy
Objective-C 2.0 introduced properties to the language. Xcode has added sophisticated support for properties (particularly in Xcode 4.3 and 4.4) so that it is no longer necessary for you to declare instance or backing variables. Xcode can create them automatically from the property (the backing variable is the property name preceded by an underscore, which previously was merely a recommendation of style).
Properties provide strict encapsulation because you never touch the backing variable directly from outside the implementation file for a class. The accessors that are created for the property handle the variable. You can create your own accessors that do directly interact with the variable, and there are examples where a nil value of the variable is replaced by the accessor with a specific default value or even a newly created object. It is this level of indirection that helps keep your code clean, and this design carries over to many of the accessors to data in frameworks. The accessor can manage security, and that’s where privacy can be enforced.
If you are used to handling instance variables directly, make sure you adopt the modern style so that you will be able to insert your privacy-respecting code in accessors as necessary. As the various Cocoa frameworks are revised, this design pattern is consistently implemented.
Be Careful When Debugging
One common cause of privacy violations is the inclusion of debugging code in a shipping product. If you do not already do so, bracket debugging code with defines so that you can turn it on or off automatically. Xcode projects define DEBUG. Some developers add a separate define (perhaps with your initials—JFDEBUG) so that you can turn your debugging code on or off independently of the general debugging code.
Ask Permission and Explain What You’ll Do with the Data
The first part of this guideline is the simplest: ask the user for permission whenever you want to access personal data or pass it along. As you saw in Chapters 4 and 5, this is built into the syntax for connecting to AddressBook or EventKit, so you don’t have to do anything special: your app’s attempt to use those frameworks handles the permission. If it isn’t granted, you’re blocked from accessing the data.
A particular issue of concern to many people is scrubbed or anonymized data. To improve its search services, Google has stored queries without the identification of who posted the query. Researchers were able to prove that with the right analysis (and some luck with regard to the queries in question), they could discover the identity of the person who posed the query.
The iCloud data you have accessed in this part of the book (AddressBook and Events) is among the most critical data that people enter. Users trust that their data on their Mac or iOS device belongs to them and is safe. It may fly back and forth across the Internet as it is synchronized, and it may be transferred to and from servers such as Exchange, but people trust that it is safe.
Look at privacy policies on the web and read media reports on this subject. Ideally, you should explain why your app wants certain data, but you should then go one step further to say what will happen if it is stored. If you want the email address of someone to whom to send a message from your app (as shown in Chapter 4), that’s a simple request, and it makes sense. However, if you ask for that email address in order to send the message and if you then proceed to store that address, you’re in trouble. Ideally, you should ask for the address to send the message and, in most cases, ask the user if the address should be stored for future use. You can even go further in asking if the address should be stored in the address book or in local app storage because some people like to have multiple address books.
Many experts in the privacy field suggest that the burden should be on the app that is storing data: don’t store data unless it is absolutely necessary. Many people and apps collect data because it “might be useful in the future,” but that’s not going to get too many people agreeing to give you their data.
The cautions about data collection apply to apps that you build for the public. Apps that are used in the course of work play by different rules—particularly if the apps (and even the devices in some cases) are owned by a business or other organization. Somewhere along the line the users should know quite clearly what is their data and what is the organization’s data. An argument can be made (if supported by documentation) that the addresses of websites an employee visits at work from company-owned devices is corporate data and not personal information.
Do Not Require Personal Data to Unlock Your App
The App Store and the Mac App Store both work with Apple IDs, and through them, the stores can identify the individual. Your app should not duplicate that process by forcing users to give you their email or other personal information before running. This has been a matter of much discussion, particularly with subscriptions to magazines. The ownership of the subscriber data is (at the moment) given to the relevant app store. Apple has approved some subscriptions that ask the user to provide that information to the app developer, but in the cases where this has been done, it is not required: the user can say no and still use the app.
Add Extra Measures to Protect Minors
Read the App Store Review Guidelines. This sentence from the introduction brings up a point that applies far beyond the App Store:
We have lots of kids downloading lots of Apps, and parental controls don’t work unless the parents set them up (many don’t). So know that we’re keeping an eye out for the kids.
It’s not just about kids: we know that many (perhaps most) people leave the security settings on the routers and computers set to their defaults (sometimes even including “Password” as a password). Some adults actively bypass the security of minors by purchasing alcohol and cigarettes for them, but more often, they passively bypass their security by not adjusting privacy and security settings.
Relying solely on privacy and security settings may be within the letter of the law, but it is not always a responsible policy. If your app is targeted to kids or is particularly attractive to kids, many people would advise that you take extra steps to manage security.
A particularly valuable resource is onguardonline.gov. It consolidates the US government’s online resources from a number of federal agencies; it is managed by the Federal Trade Commission. It is primarily geared to consumers, but the information is also relevant to developers. Geared directly to businesses and developers, “Children’s Online Privacy Protection Rule: A Six-Step Compliance Plan for Your Business” at http://www.business.ftc.gov/documents/bus84-childrens-online-privacy-protection-rule-six-step-compliance-plan-your-business has more information.
Provide Privacy for Support Materials
In common with everything from refrigerators to vitamins and TV shows, apps are frequently part of a communications network. If you have a question about any of those items, you may well turn to the web, expecting to find a web page. Sometimes, the web page you find is an official page, and sometimes it isn’t. If you are supporting your app with a web page, make certain that it adheres to privacy standards just as much as your app does. Separate standards and best practices exist for websites and apps, but they often overlap.
One area that has been problematic with apps, support materials, and privacy is the use and sharing of personal information. If you collect personal data on your website and then allow your app to access it (possibly with an account name or number), make certain that the sharing is revealed and explained on both ends of the transaction. This is particularly important when you allow users to fine-tune their settings.
Users often leave their privacy settings set to the defaults. The defaults often are a middle-range setting that balances risks and benefits. Many privacy advocates recommend that the default setting be total privacy; other people advise total openness. Obviously, the content in question helps determine the appropriate setting. If you do allow more than just on/off settings, make certain that the mid-range settings are consistent on your app and on your support materials, such as a website.
Consider User Issues
Finally, remember that users will be using your app and adjusting privacy settings. One of the easiest ways to destroy any semblance of privacy is to force users to adhere to security settings that are impossible to manage. Many users use password managers (on OS X, Keychain Access provides this feature, and it’s implemented on iOS behind the scenes). However, not everyone uses a password manager. As soon as you make security and password settings too difficult, most reasonable users resort to writing down their passwords and even posting them on an easy-to-find location. (If you want to discover someone’s passwords, look at the bottom of his laptop: you may find passwords taped there.)
For security to be effective, it needs to be unobtrusive and automatic if at all possible. The engineers at Apple now provide two such tools. Beginning with the iPhone 5S in fall of 2013, Touch ID uses your finger’s touch on the Home button to match your fingerprint to a stored fingerprint you have set up. (It’s a touch for the fingerprint scan rather than a tap—a button press—to use the Home button, as you have always done.) You can set up multiple fingerprints to allow multiple users. The encoded fingerprints are compared inside the processor so that all the processor reveals is that a given fingerprint does or doesn’t match whatever is stored. Touch ID promises to make security almost effortless to implement and that, in turn, may encourage more people to lock their phones.
Furthermore, beginning in iOS 7 and Mavericks, iCloud Keychain can store passwords and credit card information and synchronize it through iCloud to all your devices. (It also can generate and fill in passwords for websites.) Between Touch ID and iCloud Keychain, security is moving to an increasingly automatic and behind-the-scenes feature. As a developer, you should use these features whenever you have a choice.
This chapter addressed issues of privacy and security about which you need to be aware. From the start, iOS has enforced a degree of app-level security that was not enforced on OS X (and, to be fair, many other operating systems). As time goes on, app-level security is being more tightly controlled on more environments. In addition, legislation, best practice, and media reports are addressing privacy issues more aggressively.
The basic rules are quite simple:
Make certain users know what your app is doing with regard to their privacy and personal data.
Ask permission to do it, and if permission is declined, don’t do it.
Publish and abide by your policies.
In many ways, privacy and security don’t pose new issues for developers. They are just further examples of how we must design and implement software in which the user is in control.
1. Make an aggressive effort to follow issues of security and privacy. Follow proposed legislation and court cases in your country. Media outlets typically respond to current events, and after some well-publicized data breach or cyber attack, there may be a lot of information published. As is the case with all news, sometimes details are missing. Make a point to read about security and privacy issues in the lulls between the headlines.
2. If you haven’t already, read the App Store guidelines and other documents on the app stores you work with. Check for updates regularly. (Apple typically updates them and their developer guidelines and contracts with the release of a new OS version.)
3. Listen to or read nontechnical articles about privacy and security. Try to understand the issues that people care about.
4. Follow organizations like the Electronic Frontier Foundation (www.eff.org) that are active in the privacy and security arenas.