Security and Privacy Overview

As pointed out at the beginning of Chapter 1, we use documents to store and organize the data that we use in apps. There are two fundamental types of data that we organize into documents: data that is distributed with the app, and data that users create and modify. The second type, which is data that users create and modify, may include data distributed with the app.

No matter what type of data is involved, if you are building or designing an app, you need to be aware of data issues that may arise. Until fairly recently, data issues were fairly modest in apps. Some data was clearly sensitive, but most data in apps required no special handling. Users and developers took frequent refuge behind the notion that “no one will care about our data.” Data such as personal identification numbers was clearly sensitive; developers and users often handled security for such data by adding a disclaimer or note in the documentation.

All of this started changing as massive data breaches were reported in a variety of systems. Best practices for the handling of sensitive data (or data that might be or become sensitive) were formulated.

In response to media reports and general awareness of data security, laws and regulations have begun to be implemented. For example, in the European Union (EU), the General Data Protection Regulation (GDPR) came into effect on May 25, 2018.

As new laws, regulations, and best practices take effect and become part of everyday operations, it behooves people who deal with data to understand how to implement these new practices in the modern data environment. This chapter provides a case study of a very simple use of private data and how it can be accidentally destroyed by simple or careless use. You can use this case study to guide you in your use of private data and privacy implementation.

Case Study: Using Cocoa Location Services

One of the most important privacy issues has to do with the location of mobile devices. Before mobile devices were so widespread, data privacy was mostly a matter of protecting information that was relatively static even if it was shared over the Internet. With mobile devices, however, the device itself can create confidential location data. This is a part of the necessary functioning of any device that needs to be able to locate itself and the infrastructure that it needs to use to make phone calls or otherwise do what it needs to do.

It is possible to disable some or all of the location services on a mobile device (for example, by using airplane mode) but this limits or degrades performance. Apple has made location services a feature that can be turned on and off directly rather than disabling all communications. To do so, you use the Cocoa Location Services Framework.

Users need to allow the use of location services on their device. Often this happens during installation of the operating system or setup of the device, but users can do it using Settings. Figure 4-1 shows how a user can set up the privacy location settings for an app using Settings.

Once you have located your app in the Location Services section, you can choose the privacy settings you want. An app can ask for your permission on an as-needed basis, as you can see in Figure 4-2. (The text at the top of the alert is explained later in this chapter.)

When using Settings, as shown in Figure 4-1, you can set the same options using the interface shown in Figure 4-3.

In addition to the text in Settings and an app alert, you must adjust your property list to support these interfaces. As you can see in Figure 4-4, your property list has places where you describe how the user’s location data will be used.

It is very important to let the user know how you will use the location data you collect. Note that Apple reviewers ask developers to be specific in their description of how data will be used. It’s no longer sufficient to explain your use of location data with a phrase such as “Get the user’s location.” Figure 4-5 shows an example of a description that is not specific enough.

If you do not provide any description, your app will write a message to the console, as shown in Figure 4-6.

Location services provide a great example of a common problem with privacy and security. If a description for the use of the location data is not provided, a runtime message is displayed in the console, but no error is thrown, as you can see in Figure 4-6. You can argue whether this should be an error or not (as the engineers at Apple most likely have done), but the argument is convincing that it is not an error even though it might be a programming mistake.

It is a common and usually good design to build this type of warning into an app. However, Figure 4-5 shows a common error. Note that the description is “This is a test.” Because no error is thrown, it is remarkably easy for this description of how the location data will be used to show up in a shipping product. If you look at media reviews and articles about security, you’ll see that one of the biggest complaints is that when an app does provide information about how data will be used, it may well be wrong. It is often a placeholder (“This is a test”) or a description from another app that has been brought forward by copy-and-paste.

Summary

Because the explanations of what data is collected and how it will be used are written in simple language and not code that a compiler or build process can flag, these descriptions are very often wrong. Now that they are required by regulations such as GDPR, these errors are more important than ever.

The moral is that you should make certain that descriptions of security for users are correct so that users can rely on them, understand them, and use them.