The GDPR applies regardless of where and how data is processed.
But it is necessary to look at what the processing activities in question are,
and who is the controller for these activities by determining their purposes and means.
This argument is supported:
- by the absence of relevant exemptions in the GDPR
- by the GDPR's broad definition of the data controller
- by the ECJ's analysis in the Fashion ID case
For certain constellations
(e.g. controller = natural person, purposes = purely personal or household activities)
that processing is exempt from GDPR compliance
(see GDPR Art 2(2)).
However per GDPR Recital 18, the GDPR would still apply
“to controllers or processors
which provide the means for processing data
for such personal or household activities.”
For example, this means that I am able to use WhatsApp to process my friends' contact information for purely personal purposes because I'm exempt from the GDPR with respect to that processing,
but Facebook is still subject to the GDPR regarding how they process personal data collected via WhatsApp.
Already on the basis of the GDPR providing no exception for processing on someone else's computer, I disagree strongly with the answer you cited (and have already written a competing answer). It seems entirely counterfactual.
How to figure out who the controller is.
Per GDPR Art 4(7), controller is whoever “alone or jointly with others, determines the purposes and means of the processing of personal data”, although other laws might provide more specific criteria for individual purposes or means.
We will return to that definition in the next section.
The ICO has provided a checklist to figure out if you're a data controller or perhaps a joint controller.
Some of the questions are aligned with the above definition, like “We decided what the purpose or outcome of the processing was to be”.
Other questions are there as a contrast to the data processor role, e.g. “We have complete autonomy as to how the personal data is processed”.
Analysis of the Fashion ID case (ECJ C-40/17)
This judgement provides a detailed analysis of who the data controller is, and is therefore relevant to the question.
Fashion ID had embedded a Facebook “Like” button on their website, thus causing the visitor's browser to transmit personal data to Facebook.
Fashion ID asserted that they were not the data controller, since they had no control over what data was collected by the Like button and how it was subsequently used by Facebook.
Fashion ID relied in part of the argument that they weren't the controller because processing happened on the visitor's computer.
This ruling was made on the basis of the Data Protection Directive 95/46 which was repealed by the GDPR.
However, since the DPD and GDPR have effectively identical definitions of “controller” and “processing”, the court's analysis remains highly relevant. In the following I'll “translate” all DPD references to the GDPR, in analogy to GDPR Art 94(2).
The court found that Fashion ID was a data controller for the processing by the Like button, and that it was a joint controller with Facebook for this processing. However, Fashion ID was only a controller for those processing activities in which they played a part, not for subsequent processing of the data that was controlled by Facebook alone.
Relevant details from the Judgment (ECLI:EU:C:2019:629):
The GDPR tries to achieve a high level of data protection
through a broad definition of “controller”.
- Thus, an overly narrow interpretation that counteracts this goal
is incompatible with the law.
An entity is a controller
when it exerts influence over the processing for its own purposes,
thereby participating in determining the purposes and means of processing.
- Compare the GDPR Art 4(7) definition of “controller”.
- case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 68: “However, a natural or legal person who exerts influence over the processing of personal data, for his own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller”.
Paragraphs 67, 69–70, 82:
It is not necessary to have a single controller,
there can be multiple joint controllers.
The joint controllers can be involved to different degrees.
You can be a joint controller without having access to the personal data.
- case law: C-25/17 Jehovan todistajat, ECLI:EU:C:2018:551, paragraph 69: “Furthermore, the joint responsibility of several actors for the same processing, under that provision, does not require each of them to have access to the personal data concerned”.
- case law: C-210/16 Wirtschaftsakademie Schleswig-Holstein, ECLI:EU:C:2018:388, paragraph: 38: “In any event, [GDPR] does not, where several operators are jointly responsible for the same processing, require each of them to have access to the personal data concerned.”
Processing can consist of many different individual activities.
A controller might only be involved in some of them,
and can only be a controller for those activities
for which they (jointly) determine purposes and means of processing.
Fashion ID was able to determine the purposes and means of processing
regarding data collection and transmission by the Like button.
The act of embedding the button showed that they had decisive influence over the processing:
without the embedding, the data processing would not have occurred.
To summarize the relevant conclusions:
- someone is a data controller when they participate in determining the purposes and means of processing for some processing activity
- for joint controllers, this holds regardless of whether they have access to the data or participate in the processing itself
- one cannot be a controller for a processing activity for which they cannot determine purposes and means.
Conclusion and application to the question
This analysis reaffirms my competing answer to the cited answer that it is important to determine who the data controller is. The Fashion ID case shows that is important to perform this analysis on a fairly granular manner, on the level of individual processing activities.
For processing on a data subject's computer by a program written by another provider, this means:
- some processing activities might be solely under the user's control, then they are the sole data controller (or might be exempt from GDPR)
- for some processing activities, the software developer might decide alone for which purposes and through which means the processing is carried out
- for other activities, the user and data controller might be joint controllers. This does not require explicit agreement but can result implicitly. This does not require that the software developer has access to the personal data undergoing processing.
For example, a spreadsheet application might be used by an end user to process personal data on their own computer (or via a cloud application, with the same conclusions). We can consider different processing activities performed by the software:
- sorting, transforming, and other processing of the data in the spreadsheet is solely under the end users control, so they are the data controller (if they aren't exempt)
- collecting usage analytics (where those analytics signals are personal data for which the end user is the data subject) is solely under the software developers control
- uploading crash reports (where those reports contain personal data from the end user and contain contents from the currently opened spreadsheet) is more complicated. The software developer is definitely a controller. The end user has a dual role here as a data subject and a joint controller (if they aren't exempt) because the crash report processes personal data for which they are the controller.