Archived content

Archive date: 2024-11-08

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.

For more complete information about GDPR requirements, be sure to review the EU GDPR compliance requirements. And, to understand how the GDPR impacts developers, read this developer’s guide to GDPR.

Most of us outside the European Union's GDPR regulations feel that our personal data is not in our control -- especially in the world of mobile apps! As a mobile app developer or owner, you still want to collect PII (personally identifiable information), but why risk trouble with government agencies when it’s a simple addition to protect users’ data. With great data collection power, comes great responsibility!

As I discussed in my earlier article, my Android app, Appvestr®, which you can find on Google Play, demonstrates some of these mobile security best practices. In this article, I’ll show you how you can easily present the following data privacy options to your users:

Opt in
Withdraw permission
Data Subject Requests (DSR)

I implemented each of these data privacy options with IBM Cloud using basic Cloudant database elements and a serverless monitoring agent.

I’m not going to focus on Android UI code, but rather I’ll show the UI and focus on the pieces of the experience that interact with the common database service. This is an opinionated approach to this solution and clearly, UI and implementations will vary, but the scope of this article is simply focusing on one database implementation to support the above three user experiences for data privacy.

Data design

To implement these data privacy capabilities, I decided on a running log of time-stamped verbs to have an audit trail of all the user actions taken. For the corporate developer who is governed by regulations, this log allows you to keep a running history of the user actions in case any data forensics need to be applied for any user or sets of users.

User Action	Consent Type Field Contents
Opt in	consent
Withdraw permission	withdraw
Data Subject Requests (DSR)	request

For each record captured, I simply chose three different fields:

Database Fields:	Email	consenttype	Date
Sample Data:	noname@youremail.net	Consent	01/23/2022

I chose to implement this in a Cloudant noSQL database, as the service tier is free for simple usage, and the Android mobile libraries were readily available.

I included this reference in my Android build.gradle, but newer versions might be available since the time this article was published:

implementation group: "com.ibm.cloud", name: "cloudant", version: '0.0.32'

Enterprise data design

For enterprises, larger scale Cloudant usage service tiers are available:

Screen capture of IBM Cloud Cloudant service tiers

IBM Cloud also has High Availability (HA) database services in each Multi-Zone Region (MZR) such as MongoDB, also a noSQL format, and PostgreSQL. MZR databases features also include automated backup orchestration, autoscaling, and decoupled allocation of storage, RAM, and vCPUs. For additional protection, developers can also choose a Hyper Protect DBaaS solution, also available in noSQL and SQL variants which provide workload isolation, restricted administrator access, and tamper protection for data at rest and in flight. IBM Cloud contains over 40 different enterprise database options (check out the catalog of choices for yourself):

Screen capture of enterprise database options for IBM Cloud

To create the Cloudant database, I used a simple csv-import Python importer, which also creates the indices using the sample record data elements outlined above. Once established, I created the following Java method to post the JSON “document” to the database with the aforementioned data fields of email, consent type, and date:

public void saveUserPrivacy(String email, String consenttype) {
  DocumentResult response;

  Document registryDocument = new Document();
  registryDocument.put("email", email);
  registryDocument.put("consenttype", consenttype);
  String currentDate = new SimpleDateFormat("yyyy-MM-dd:HH:mm:ss", Locale.getDefault()).format(new Date());
  registryDocument.put("date", currentDate);

  PostDocumentOptions documentOptions =
      new PostDocumentOptions.Builder()
          .db(getUserPrivacyDatabase())
          .document(registryDocument)
          .build();
  if (isDoDebuglog())
    Log.e(BlueListApplication.CLASS_NAME, "Adding " + registryDocument.toString());

  try {
    response = service.postDocument(documentOptions).execute().getResult();
  } catch (Exception e) {
    if (isDoDebuglog())
      Log.e(BlueListApplication.CLASS_NAME, "Could not save user privacy preference. ", e);
  }
}

Opt in

Users must be presented with this option unchecked as the default so as not to have users unwittingly bypass this important checkpoint. This must be a conscious decision by the user, and per Play Store guidelines, you must also publish your policies on a publicly available location.

Developers must decide in our apps if this completely disqualifies the user data as personal information (PI), and if it is fundamental to the app's operation, then exit the app. If the user declines to have PI collected and used, your app might have to use a data obfuscation approach to user identification.

For my mobile app, I chose to limit entry into the app unless the user opts in. As shown below, I enable the “Proceed” button only if the checkbox is checked, indicating an “Opt In” condition for the user:

Screen capture of Opt in condition

To complete the “Opt In” scenario, I simply use the aforementioned “Consent Type Field Contents” which requires only a simple method call: saveUserPrivacy(email, "consent");.

Withdraw permission

Let me assert a key reminder: Users have the right, after opting in, to withdraw permission. Therefore, all the PI data for that user must then be removed, because even if you're no longer collecting it, it is stored somewhere, which falls under "processed" data.

Read this blog from it governance about whether you need to delete backups to remain in GDPR compliance.

So, technically, you’ll also need to remove all the data backups too, but in some EU countries, organizations don’t have to delete backups to remain in compliance.

I’ll repeat some key definitions from my earlier article on data privacy roles: controllers and processors:

"Controllers" control the why and how of data processing activity. That is, controllers set the rules, and you must explicitly show those rules in your app. This transparency allows users to decide to opt in or out based on how you'll use the data, now or in the future.
"Processors" process personal information (PI) in the way that is determined by the controller. If you plan on providing data to a processor, the processor must inherit the controller's rules and actions.

Developers need their users to be able to oversee their data, so as a “Data Controller”, we must offer a “Withdrawal request” to remove the ability for us and our “Data Processors” to handle that user data because the Processor inherits our policy.

I implemented the UI in both an Android Settings Activity and an AlertDialog to present choices to confirm the Withdraw permission request:

Screen capture of Withdraw permission settings

As with the Consent, we can simply log a withdrawal request with this call: saveUserPrivacy(email, "withdraw");.

Data Subject Request (DSR)

Users also have the right to ask for their data. As mobile developers, we must build this into our mobile app security.

I implemented the UI in both an Android Settings Activity and an AlertDialog to present choices to confirm the Data Subject Request:

Screen captures of Data Subject Request settings

As with the Consent and Withdraw requests, we can simply log a DSR with this call: saveUserPrivacy(email, "request");.

Notifications of withdrawals and DSRs

Now that we’ve implemented all the compliance data logging in Cloudant, how can we easily monitor the database to notify us of any changes? Fortunately, this exact scenario is covered in the IBM Cloud documentation.

Important: IBM Cloud Functions has been deprecated. Instead, you can use IBM Cloud Code Engine as the serverless compute platform.

Monitoring is a wonderful use case for serverless computing and IBM Cloud Functions, which is an OpenWhisk open-source implementation of serverless computing, makes this easy with preinstalled Cloudant support! You must have an existing Cloudant database before using these tutorials, which I already created above through the CSV import.

Continuing to follow the IBM Cloud Functions docs, let’s create a trigger on database changes, which will point to some code that we’ll show later that will send an email notification:

ibmcloud fn trigger create privacyTrigger --feed appvestrCloudant/changes --param dbname userprivacy

Once the trigger was created, I can see it in the IBM Cloud Functions console. From there I can use the UI to add an action:

Screen capture of privacyTrigger Cloud Function

I chose to implement the action in Node.js:

Screen capture of Node.js code for the action

I also chose to leverage the nodemailer package to send an email as a notification, but this isn’t the only option available.

Now, with just this small amount of code, I'll get an email notification whenever database changes occur.

/**
  *
  * main() will be run when you invoke this action
  *
  * @param Cloud Functions actions accept a single parameter, which must be a JSON object.
  *
  * @return The output of this action, which must be a JSON object.
  *
  */

async function main(params) {

    var nodemailer = require("nodemailer");

  console.log(params);

  // use email from https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-runtimes#openwhisk_ref_javascript_environments
  // from https://nodemailer.com/about/
  // create reusable transporter object using the default SMTP transport
  let transporter = nodemailer.createTransport({
          host: "smtp.yourmaildomain.net",
          port: 465,
          secure: true, // true for 465, false for other ports
          auth: {
          user: "USERNAME", 
          pass: "PASSWORD", 
          },
  });

      var htmlmsg = "<b>" + JSON.stringify(params.id) + "</b>";

  let info = await transporter.sendMail({
          from: '"YOURNAME" <youremailaddress>', // sender address
          to: "yourdestinationemail", // list of receivers
          subject: "ACTION: Appvestr User Privacy Change", // Subject 
          html: htmlmsg // html body
  });

  console.log("Message sent: %s", info.messageId);

  return { message: 'Hello World' };
    }

    main().catch(console.error);

Summary

While regulations in certain countries aren't always there to protect consumers, developers can do the right thing now, and build trust in their user base by easily implementing a simple set of data privacy rights using some basic Cloudant database elements and a serverless monitoring agent using IBM Cloud.

In this article, I demonstrated a simple and low-cost approach to log and monitor user's privacy rights in a mobile application. Mobile applications have gained in popularity to simplify tasks that were previously on more complex web or other front-end systems. Clearly, user privacy issues exist in any system that collects your data, and this article's approach can be applied to any number of systems because the Cloudant database is accessible through several different languages and applications.

Implementing data privacy rights with mobile apps and databases

Implementing data privacy rights with mobile apps and databases