The right to be forgotten by the User’s request

There are different ways to remove a user’s personal information at the user’s request to make a product compliant with the CCPA or GDPR. The most basic method is to handle every request received by mail manually. The important thing is to make sure the process is as straightforward as it can be and clear to the user. So a little automation is not such a bad idea.

This article uses the iFunny mobile app to illustrate how a data removal request processing system works. Today, incoming requests are specific from the start, so tech support can spend half as much time processing them.

American lawyers Samuel Warren and Louis Brandeis articulated the concept of “privacy” as a “right to be left alone” as early as 1890. They were alarmed that recent inventions and business methods threatened privacy. Admittedly an issue in their time, this concern has since become something of a self-fulfilling prophecy. The matter of personal data protection is today more relevant than ever.

In grappling with the issue right from square one, the California Consumer Privacy Act (CCPA) and General Data Protection Regulation (GDPR) gave businesses much extra work to do enacting the new rules and making them stick.

We will not be looking at every aspect of the problem but will focus on the fundamental concept: the right to be forgotten. The GDPR stipulates that the personal data controller should erase personal data without undue delay when requested by the data subject and cause its counterparties to do the same.

It follows that where an app offers the option to authorize via social media, via an Apple or Google account, or suchlike, you thereby become their counterparty and, as such, are obliged to allow them to fulfill the law. Now I am going to tell you how we handled this.

Designing a system to delete personal data

It was a basic routine at the start, and ad hoc requests were received and acted upon by tech support without any serious accounting or automation. This kind of approach works for businesses catering to a small audience, but not for iFunny, which boasts over 70 million installations, millions of active users daily, and a bunch of integrations with external platforms. It was a bit of a challenge.

To make our lives easier, we decided to formalize and automate the processing of data erasure requests.

Purposes

The central purpose was to ensure compliance with the law and the Apple guidelines (Google will most likely issue similar guidelines going forward).

The laws and regulations, and in particular the CCPA and GDPR, first and foremost require that:

• It should not be more difficult to erase data than to provide it

• If it takes one push of a button to create an account, it should be commensurately easy to erase one

Tasks

1. Design a system that permits the user to request data deletion automatically.

2. Learn to delete all personal data the user may have left across the service platform at any time. That includes emails, social media accounts, geopositioning data, age, gender, and everything else.

3. Learn to delete and inactivate a user account entirely. But leave at least the email option open for the user if they wish to send a request. Where the user decides to change their email and restore access to their account, they should have the option to do so via tech support.

Requirements

We developed the system requirements ourselves using our model’s regulations and guidelines of service platforms such as Facebook and IAB. We ended up with the following list:

1. The user can submit a request on the website, the app, or from Facebook (and in the future, via any other channel). There are interfaces in place to create requests via any of these channels.

2. The handling process is as transparent to the user as it can be. There are explicit request processing statuses and a page to verify the status.

3. Requests are saved for further reference and security purposes. They are stored at the back-end, and the user gets notified of status highlights while request processing is in progress.

4. The system is safe. Without authorization, no malicious actor can erase another user’s data (delete an account).

5. It is apparent to the user how their data and their account will be used. A letter is to be sent with a worded process description.

6. Tech support has a fast and easy way to handle the requests. Detailed request processing procedures are in place, as well as a dedicated page on our administrative portal with a list of all requests, status filters, and request action buttons, such as “delete personal data.”

Results

Long story short: the requirements were met, and we got the system up and running. The system includes:

— Request creation page (website and app)

— Request status tracking page (website only)

— Administrative portal with a list of all requests, filtered by status, and a processing page

— And this back-end:

• Request creation and status tracking API

• Administrative portal API

• Request storage

• Business logic for request status automation

• Automatic user verification by mail

• Request status messaging to the user

• Deletion of user data

Now let us tell you some more about the personal data deletion process, from sending a user’s removal request through processing to status check.

Receiving data removal requests

The life cycle of a request may be presented as a finite state machine with a sequence of states that change apace with the progress of processing, namely:

• Waiting for Email Confirmation — request awaiting user’s confirmation.

• Received — booked into the accounting system and ready to be processed.

• In progress — taken for processing by a hands-on implementer.

• Waiting for User Response — additional information is required and requested from the user.

• Done — completed.

• Rejected — declined.

The process is triggered by a user request, which may come via various channels. We currently support request filing via Facebook, the app, and the website form.

Receiving requests via Facebook

• Facebook started phasing in its data removal request system in 2018. In 2020, it was made mandatory for all applications utilizing the platform.

• It works like this: every time a user logs in or links their Facebook account to an outside app or website, the user grants access to their data (by default, it’s the given/last names and email address; additionally: gender, age, geolocation, employment, and so on).

• You will find a list of services that has obtained access to your information on this page. You are at liberty to revoke the data usage rights, after which the app will erase the data and discontinue any use thereof. Facebook is supposed to notify the user, and it will do so by one of these two methods:

1. Where the app does not support automatic removal requests, Facebook will link the page with data removal instructions and a contact email.

2. Where the app supports automatic data removal requesting:

• The app will provide a Callback URL supporting a specified interface.

• When the user has deleted the app from their settings, Facebook will pull out the Callback.

• The app will generate a request and reply with its number and page URL for request status verification.

Sending a data removal request

In the final analysis, this is what Facebook has to have to keep the system running: Callback URL for integration, automatic request reception, generation of request numbers, and a status verification page.

We have the second variant. Accordingly, we will see if the user exists in our system, then transmit to Facebook either a rejection stating “user not found” or technical data with the request ID and a link to track the request status.

In the meantime, the request’s status changes to Received.

Receiving requests via app or website

The user submits the request from their account. The user is asked to provide an email for further dialogue with tech support and confirm that they understand and accept that their decision is irrevocable.

A review is also conducted to ensure the request is not a second copy. If an identical request were previously filed, processed, or completed, the new request would be automatically declined.

A request is created in iFunny on Android

After this, a message is sent to the specified email with a link for confirmation, and the request status is changed to Waiting for Email Confirmation.

Message with confirmation of a data deletion request

When the user clicks through on the link, the request status changes to Received, and the user gets a message explaining how to track the request status. The request will close automatically if no confirmation arrives within 30 days.

Request creation page on ifunny.co

Request processing

When the user has filled out the form on the website or in the app, the request with a Received status arrives at our administrative portal. Next, our support team is notified by email and on Slack.

Most request processing happens on this portal or, more precisely, on its two designated pages:

• Page with the list of all requests, including primary data on each one (user ID, email, request ID, date created, and current status with filters)

• Page assigned to the specific request

A screen of the portal page with requests list

Request processing walkthrough

Step 1. The request is awarded the status of In Progress and undergoes a necessary manual check to make sure the request confirmation email matches the user’s email in question. This way, we safeguard ourselves against deleting someone else’s data. This same check happens automatically when the request is created and when the email is confirmed.

Step 2. After this, all data will be verified automatically. If something is missing, the request status will change to Waiting for User Response, and a message with the pertinent questions will go out to the user:

• When the user replies with the information requested, the request status will change back to In Progress.
• If the user fails to respond within 30 days, the request will close with a Rejected status.

Request processing page

Step 3. If the request is valid, its further processing will depend on its origin. This is a manual step.

– If the request came from Facebook

We send the user a message asking for additional confirmation of their intention to delete their data. To a person trying to delete their iFunny account via the Facebook interface, it may not be evident that this action will cause a data deletion request.

On the one hand, we add an extra manual processing step and an extra action from the user. On the other hand, this may be a way to avoid specific unpleasant implications the user may not be aware of (for example, the user may not realize they will no longer be able to access their iFunny account via Facebook).

– If the request came from the app or the website

We will delete the user’s data and deactivate their account. We deactivate the account rather than erase it because the user may want to restore their account, which can be done within the next 30 days.

This was a point of contention during system development. We will delete the user’s data in its entirety but keep their uploaded content intact (not visible to anyone). The law has no provisions on this. Therefore, having no intention to abuse our right to use the content, we have decided to leave the user some leeway to change their mind. However, all content will be deleted upon the lapse of 30 days following the date of account inactivation.

Step 4. The request status automatically changes to Done, and the user gets messaged accordingly. A message will also be sent if the request status changes to Rejected at some point.

The user can check their request status on our website at any time: we add the relevant link to every message and display it following request submission from the app or website.

Benefits of a working system for personal data deletion

1. It’s quicker and more accessible for the user to click the button in the app than to write a message.

2. The user gets to check their request status at any time.

3. A common interface for all process parties. The user no longer has to articulate their request and tech support — to rack their brains over its correct interpretation

4. Tech support spends two to three times less time for the entire request processing cycle.

5. Full compliance with the law and Apple requirements.

The system is in action and works like a charm. No glitches or surprises: we keep monitoring the system to get further improvement ideas.

Lastly, we emphasize the importance of receiving user requests, streamlining the process, and understanding timeliness in user privacy data requests.