GDPR and speech recognition of text spoken into an App&#39;s microphone
<p>In one of our Apps we use a Java-Class called &quot;SpeechRecognizer&quot; for doing some speech control. Technically, it is up to the settings of the smartphone (operating system) if the speech from the microphone, which is processed by the SpeechRecognizer class, is processed locally without ever leaving the phone, or if it is sent to some Cloud Service operated e.g. by Google or a third party.</p>
<ul>
<li>Generally, is in such a scenario the smart phone user, who defines the settings of the operating system, responsible for such data (text spoken into the microphone)? Is the smartphone user the controller for this data?</li>
<li>Has this to be mentioned in the privacy policy?</li>
</ul>

<p>This is a really involved question about the role of the data controller. It cannot have a general answer, but it is possible to clarify some aspects.
In general: the app developer is responsible for what the app does, but not for how their app is used. GDPR compliance will not be overly cumbersome if all features of the app are fairly obvious.</p>
<p>First, let's discuss: who is the data controller? Trick question!</p>
<p>On one hand, the app developer can be a data controller even if the processing is performed entirely on the users' device. This was e.g. discussed in the Fashion ID case, albeit for data processing by a website in the user's browser – no real difference though, since both are <em>information society services</em>.</p>
<p>On the other hand, it is the user or maybe the phone OS developer who controls how the speech recognition is actually performed.</p>
<p>In any case, the user might be a data controller regarding how they use the app. For example, an employer requiring its employees to use the app would be a data controller. If the user uses the app for purely personal or household purposes they are not a data controller, but this doesn't change that provider of the service they are using would still be a data controller (i.e. you, as the app developer) – see Recital 18 GDPR.</p>
<p>The path to resolve these ambiguities is to consider that a task like “providing an app” or “using speech recognition” can consist of multiple distinct processing activities. An involved person/entity might be data controller for only some of them, but possibly jointly together with others. Someone can only be <em>a</em> data controller (not necessarily the sole data controller) for processing activities where they participate in the determination of purposes and means of processing.</p>
<ul>
<li><p>Here, I think that the app provider is definitely a data controller for part of this speech recognition since they cause the audio recording and speech recognition to occur.
The app developer is definitely a data controller regarding how the output of the speech recognition processing is used by the app.</p>
</li>
<li><p>If the developer were to use a third party speech recognition service, that service should be the developer's data processor, or the developer would need an additional legal basis for sharing the audio with a third party.</p>
</li>
<li><p>Here, the developer uses the phone's built-in speech recognition capabilities. The app developer cannot influence how and why the phone operating system performs speech recognition and uses the data subsequently. Thus, the app developer cannot be a data controller for OS-level speech recognition features, but the OS provider might be another data controller.</p>
</li>
<li><p>The user may or may not be another data controller involved here, depending on the purposes for which they are using the app.</p>
</li>
</ul>
<p>Should the use of speech recognition be mentioned in the privacy policy?
Yes, that would be sensible though it might not be strictly required.
The privacy policy must mention all purposes of processing (<em>why</em> are you causing speech recognition to occur?)
and must explain with which third parties data is shared.
It would also be a best practice to explain any non-obvious collection of data, e.g. under which circumstances the app will record audio and what will be done with any recorded audio.
See Art 13 and Art 15 GDPR for the precise list of items that must be included in a privacy policy, though in many cases it can be helpful to develop that document together with the Records of Processing Activities from Art 30.</p>
<p>A mobile app that processes personal data only locally is also in the nice position that it's feasible to use consent as a legal basis for a lot of these processing activities. When requesting consent, it's best to use a layered information approach (<a href="https://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=622227" rel="nofollow noreferrer">WP260</a>): the first layer can be an interstitial screen or dialogue that summarizes why consent is being requested (purpose) and how the data will be used. The second layer would typically be the full privacy policy that explains these matters in detail, and would be linked from the first layer. Since consent must be easy to withdraw (Art 7 GDPR), the app settings should have a toggle to disable processing for individual purposes to which consent has been given.</p>

gdpr