Is this a valid approach to ask consent under GDPR? I'm trying to figure out the best way to gather user consent to use third-party services in a mobile app for users under the GDPR. Let's say that I have an app that uses third party services (analytics, ads...) which collects personal identifiable information. In the first app launch a dialog would be presented to the user: This app uses tracking identifiers We use tracking identifiers to collect information about how you interact with our app. We use this information in order to improve your experience, for analytics purposes and advertising. You can find out more about our use of cookies in our Privacy Policy and change your preferences below. BUTTON: Accept BUTTON: Change preferences I offer a link to my Privacy Policy here. If the user accepts, everything is set up normally. If the user clicks on the change preferences button, it is directed to a privacy preferences screen: Preferences screen I don't have the exact texts, but here I would basically present a list of each third party service I work with, their privacy policy, how do they use the user's data, and a checkbox to enable/disable the data collection For the ads, here I state that if the user does not consent, the app will continue to show ads but no personalization will be done on them. The app would also allow the user to change their preferences at any time in the future. My questions regarding this implementation are: Is this overall approach correct, and fully compliant with the law? It is OK if I set all of the options to enabled the first time that the user goes to the preference screen (enabled by default) ?
How to properly ask for consent is an evolving issue. Your general consent flow is very common, but I don't think it's entirely compliant. Legal background on consent Consent is one of the Art 6 GDPR legal bases for processing. The ePrivacy directive (ePD) also mandates consent for accessing information on a user's device, where such access is not strictly necessary for a service explicitly requested by the user. For example, this means that analytics cookies require consent. Consent is defined in Art 4(11) as: any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her Further conditions for consent are given in Art 7, such as that “It shall be as easy to withdraw as to give consent”. The EDPB guidelines 05/2020 on consent provide extensive interpretation of the GDPR that should be considered as effectively binding. First layer: accept / change preferences The first consent layer provides general information about the purposes that consent is being sought for. This seems to be mostly compliant, but I have some doubts. Consent must be freely given, and withdrawing consent must be as easy as giving it. I would therefore recommend having a “continue without consenting” option that is given roughly equal prominence to the alternatives. Consent must be informed. Even in the first layer, you must give basic information. In the EDPB guidelines, the following items are identified: controller's identity purposes of processing what type of data will be collected existence of the right to withdraw consent if relevant: that the data will be used for profiling/automated decision making if relevant: possible risks if international data transfers are made under Art 49(1)(a) I think this makes it difficult to collected an “agree to all” style consent that covers all purposes. It would be better to clearly distinguish between the analytics and advertising purposes even in your first layer. Consent must be specific to a purpose. You try to make this possible via a second layer where granular choices can be made. This isn't entirely bad, since you also need to make the consent flow simple enough as to avoid click fatigue. But since you only have two processing purposes, it would be better to show them separately on the first layer. You cannot generally make access to the app conditional on unrelated consent. The statement “This app uses tracking identifiers” suggests that there is no choice. It would be better to make it clear that the user can voluntarily consent to such processing. Together, this would mean that a design like the following could be more compliant. Text in [brackets] indicates buttons or links. Your privacy choices To support and improve this app, you can choose to give us access for the following purposes: Analytics: understanding how you use this app We would like to collect information on how you interact with the app, and store cookies on your device for this purpose. [more information] [decline / agree] More relevant advertising We will always show ads, but if you want we can build an interest profile to show you more relevant ads. [more information] [decline / agree] You can always change your choices in the app settings, but past use of your data remains legal after withdrawing consent. ExampleApp is provided by ExampleDeveloper Ltd. [full privacy notice] [continue] Second layer: detailed information about all services Your second layer sounds good, as it provides granular controls and more detailed information. As already mentioned, I would move some of this to the first layer. But one of your questions pertains to the defaults on this screen: It is OK if I set all of the options to enabled the first time that the user goes to the preference screen (enabled by default) ? No, this is not OK. Consent means opt-in, and requires an affirmative action by the user. You cannot have pre-checked checkboxes. The default is that no consent was given. If you have an “enable all” button, I would also expect a “disable all” button. Else, consent might not have been given freely. You also cannot rely on the consent until consent has been actually given. So you must not start collecting analytics in the background while the user is still on the consent choice screen. In addition to being non-compliant by itself, loading pre-ticked checkboxes increases the risk that your application accidentally considers the consent as already being given, which could easily lead to illegal processing if there's a bug in your app. You might have processing purposes that are based on a legitimate interest instead of consent. These can be enabled by default, but you generally have to make it possible for the user to object. Your relationship with third parties When using third party services, it is crucial to understand if they are a processor who is contractually bound to only use the data on your behalf, or a separate processor. You must disclose processors (or at least categories of processors) in your privacy notice, but not really during the consent flow. The GDPR does not distinguishing between doing processing activities yourself versus outsourcing them to a processor. In both cases, you are the controller, and only you are asking for consent. Thus, it's also superfluous to show third party privacy notices. It's your obligation as the controller to provide all necessary information. If you are collecting consent for other controllers with whom you have joint processing activities, you must make this much more prominently. You would have to disclose in the first layer that you are sharing the data with other controllers who can use the data for their own purposes. This sharing is part of the processing purpose. This is quite tricky to do correctly when it comes to ad networks, since ad networks generally won't be your data processor and can have many intransparent members. Demonstrating consent As the data controller, it is your obligation to be able to demonstrate that valid consent has been given. This implies process-level obligations such as being able to show that your consent flow is non-coercive and makes it possible to decline consent. This also implies individual-level obligations such as being able to show when a given user has given or withdrawn consent for which purpose. If you have a backend anyway, it could be sensible to store information there about consent/withdraw events. When the user returns to the consent management screen through the app settings, you could show a timestamp like “you consented to this purpose on 2021-08-22 17:14:23”. I have recently written a more detailed discussion about demonstrating consent.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
These kinds of cookie banners are typically noncompliant and useless since they are not clear and provide too little information to users. Careful: blocking a user who declines consent is usually a GDPR violation! Instead, only those aspects of the site that rely on this consent should be disabled. When cookie consent is needed Per the EU ePrivacy directive (PECR in the UK), information society services (websites, apps, …) are only allowed to store or access information on the end user's device if one of the following holds: the access or storage is strictly necessary for performing a service that was explicitly requested by the user; or the user has given consent Note: there is no “legitimate interest” exception for cookies. When is access/storage strictly necessary? For example, it is strictly necessary for a photography app to store photos on a device. It is strictly necessary for a website to store session cookies so that you can log in to the site. It is strictly necessary for an ecommerce site to store the contents of your shopping cart. It is strictly necessary to remember cookie consent status. And so on. It is not strictly necessary from the perspective of the user to have analytics cookies, ad personalization cookies, or cookies for features that the user doesn't actually use. Many websites that just provide the service the user expects will therefore not have to ask for cookie consent, even if they use cookies. It is worth noting that the ePrivacy definition is entirely technology-neutral. It doesn't relate specifically to cookies, but to any kinds of storage, including LocalStorage. Regulatory guidance considers any access or storage of information on the device to be in scope, even JavaScript APIs in a browser (for example to read the screen dimensions), and considers techniques like fingerprinting to be functionally equivalent and therefore subject to the same rules. It is also worth noting that these rules apply regardless of whether the information being accessed/stored qualifies as “personal data”. What consent is Consent is defined in Art 4(11) and Art 7 GDPR, and further explained in EDPB guidelines 05/2020. A defining feature of consent is that it must be freely given. The user must not suffer “detriment” for revoking or declining consent. And per Art 7(4): When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. This disallows making access to a service conditional on unrelated consent. For example, it would not be permissible for a website to exclude users who decline consent for advertising cookies. But: The EDPB guidelines discuss that there can be “permissible incentive” for consent. For example, courts and some DPAs seem to be of the opinion that a subscription website can offer free access to users that consented to personalized ads: consent-or-pay-walls can be compliant, whereas consent-walls alone would not. Sometimes consent is really needed for a processing activity, in which case it is OK to block that service until consent is given. For example, websites should not load third party content like YouTube videos or embedded maps until consent is given to share personal data with the third party. The rest of the website should still work, though. If consent was not freely given, if the user didn't have an actual choice, then the consent is invalid. What should the data controller in your scenario do? The data controller should reassess the role of the cookies for which they are trying to ask for consent. If these cookies are strictly necessary from the user's perspective, then it is proper to inform the user about them – but this should not be confused with consent. It is my personal opinion that purely informational cookie banners are confusing/misleading and should be avoided, but this could also be argued differently. If these cookies are not strictly necessary, then the phrasing “We need to use cookies to provide you with our service” is quite misleading. It should be made clearer to the user that they can opt-in to additional services/improvements if they want to. The user should be able to configure this on a per-purpose basis. Thus, more compliant cookie consent flows will typically give the user three options: continue with only strictly necessary cookies/purposes (must be default behaviour if none is selected) consent to all purposes configure purposes For example, I'm fairly happy with the current Reddit cookie notice: Why this is a good notice: it explains the data controllers (Reddit and partners) it summarizes the purposes for which consent is sought it links to more detailed information the presented options “accept all” an “reject non-essential” are less ambiguous that “accept/decline” Comparing this with the list of minimum required information for informed consent in section 3.3.1 of the EDPB guidelines linked above, the following information is missing though: the identity of the “partners” what (type of) data will be collected and used the existence of the right to withdraw consent
Keeping logs of chats would not necessarily be against the GDPR as you have suggested. For the IRC service provider/operator: these chats/logs would be within scope if EU-based users are involved and this means the data controller/processors would have legal obligations to comply with GDPR. The IRC service provider/operator would be the data controller and would be held ultimately responsible for the data stored/processed through the IRC service, including backups and logs kept etc, and this would mean any sub-processors they select (such as hosting provider) would also have to be GDPR compliant. Due to the nature of IRC chats being entirely public in the same way forum board posts and comments are public, the contract terms between the IRC service provider and the IRC users would need to be very clear that this is the case, and the IRC users would need to give consent for this processing (this is more complicated for children, see Article 8 regarding consent from the holder of parental responsibility). For IRC users (personal use): If you wish to keep the chat records for personal use only (i.e. not in connection with a business or your employment at a business), then an exemption applies: This Regulation does not apply to the processing of personal data: ... (c) by a natural person in the course of a purely personal or household activity; ... (GDPR, Article 2: Material Scope, Paragraph 2(c), p.32) For IRC users (commercial/business use): In this case I don't think you would have any legal basis to store/process these chats/logs if they contain personal data without a legal agreement with the data controller which would require you to put in place the same protections they have to under GDPR but then allow your business to access the data for specific purposes. While the information may be published or considered to be in the 'public domain', for you to take a copy of it without permission and use it for a purpose they haven't consented to would not be allowed under GDPR. Additionally, to go through the process of removing personal data from the chats/logs would in itself be considered 'processing' under GDPR and therefore would be unauthorised without a legal agreement with the data controller. Practically therefore, your best options under this circumstance would be if: The IRC service provider implemented a 'favourites' feature to save within their own system the chat conversations you wish to retain and refer back to in future. Since they hold the data and you already have a user agreement with them there is no further complications (this is probably the best option); The IRC service provider implemented a feature to download an anonymized copy of a chat conversation (not ideal as there are no guaruntees a user will not include personal data in their messages, though the user agreement could state that message content will be considered to exclude personal data, in a similar way to how StackExchange do for this website, see the paragraph titled "Information You Choose to Display Publicly on the Network" on the StackExchange Privacy Policy). Your business considered an alternative communications solution, such as hosting its own real-time chat system or forum boards system, in which case your business would be the data controller, and while subject to GDPR you could then define the purposes for which the data will be used in your own user agreement.
It is neither legal nor illegal, but would depend on the circumstances. For example, such use of a smart assistant might be perfectly fine if the childcare provider could demonstrate a legitimate interest for using the smart assistant, and gave reasonable notice about audio being recorded. Parental permission is likely not necessary. In practice, doing this right would be far too much effort. For example: Has the necessary information per GDPR Art 13 been provided, taking into account the EDPB guidelines on transparency? Under what legal basis are conversations sent to Amazon, an US-based provider, taking into account the Schrems II ruling? How will data subject rights be satisfied, in particular the right to access to these recordings, the right to erasure, and the right to object to further processing? Having discovered such processing of personal data that isn't necessarily kosher, a parent/guardian might start by objecting (GDPR Art 21) to further processing. This could be satisfied by powering off the Alexa devices in all rooms where the child is expected to be. The childcare should respond within one month. If no satisfactory response has been received, one option would be to lodge a complain with the supervisory authority, which would be the ICO in the UK.
Article 4(11) says: ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; Recital 32 says (my emphasis): Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement.2 This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data.3 Silence, pre-ticked boxes or inactivity should not therefore constitute consent. ... At the time of writing, the most recent guidance on consent from the European Data Board says: The use of pre-ticked opt-in boxes is invalid under the GDPR
IANAL, and as @GeorgeBailey suggests, you should ask one. That said, some aspects of your question are directly addressable with what we know. Does US law states anything about this? Yes. Federally this falls under the Wiretap Act, 18 U.S.C. §2511. Workplace monitoring generally falls under either the "System Administrator Exception" or under Consent. In general, continuing past a banner constitutes consent. Does company policy enforcement with such a warning over ride the right to not be subject to surveillance? In general, yes. You don't need to use the companies network if you don't want to consent - and they don't need to hire you if you don't want to use their network. But it's their network, and their rules apply. There are some nuances, and courts have found that the wording of the notice has made a difference in some cases, but overall, if the systems are properly posted with banners, then the employer may capture communications. See the "Bannering and Consent" section of this article from cybertelecom.org, e.g.: Even if no clicking is required, a user who sees the banner before logging on to the network has received notice of the monitoring. By using the network in light of the notice, the user impliedly consents to monitoring pursuant to 18 U.S.C. § 2511(2)(c)-(d). Note that stored data is covered by different laws than communications. It's a nuance. Is it ethical to sniff all the data without giving any other warning than the logon banner? "Ethical" is a very different question than "Legal", and largely more subjective. Most employers require signed consent for monitoring as a condition of employment, and use banners thereafter. That is ethical by my definition, in that it meets or exceeds the requirements of the law, and does not mislead or use subterfuge. The tone of your question suggests you find it distasteful, and therefore probably it violates your personal code of ethics.
The scope of the GDPR is entered when personal data is being processed in a structured manner. Personal data is any information relating to identifiable data subjects (definition in Art 4(1)). &quot;Peter attended the meeting on the 14th&quot; is personal data. &quot;That woman with the blue handbag said she wanted to return on the 25th&quot; is personal data. However, aggregate statistics do not relate to individuals, and are typically not personal data. &quot;On the 14th, we had 25 attendees&quot; is not personal data. Not all use of personal data is within the scope of the GDPR. For example, the GDPR would not apply if two organizers talk about who attended the meeting. However, Art 2(1) says the GDPR applies when personal data is processed wholly or partially with automated means (e.g. computers, smartphones), or forms a filing system or is intended for a filing system (e.g. keeping notes on attendees, keeping attendance lists) If GDPR applies, the organization would be responsible for ensuring compliance with its rules and principles, summarized in Art 5. Primarily, this means: having a clear purpose for processing selecting a suitable Art 6 legal basis for that purpose (e.g. consent or a legitimate interest) only processing the minimum data necessary for achieving that purpose determining and implementing appropriate technical and organizational measures to ensure compliance and security of the processing activities preparing for data subject rights, in particular by providing an Art 13 privacy notice when collecting data from the data subjects There are of course some complexities in the details. When the legal basis is &quot;consent&quot; (opt-in), the organization would have to ensure that this consent was freely given and sufficiently informed. Per Art 7(4), consent would not be freely given if that consent was a condition for access to the meeting. Using &quot;legitimate interest&quot; (opt-out) can be more flexible, but it requires performing a balancing test to show that the legitimate interest isn't outweighed by the data subjects' interests, rights, and freedoms. Roughly, relying on a legitimate interest is appropriate when the data subjects can reasonably expect the processing activity to occur. Regarding point 1, keeping general counts and aggregate statistics about attendees is probably OK since it wouldn't be personal data. If you are very conscientious about this, you could round all counts and use categories like &quot;0-4 attendees, 5-9 attendees&quot; for each facet, which makes it more difficult to make inferences about individuals. But the fundamental point is that all your data should relate to attendees as a whole, never to individuals. Regarding point 2 and 3, this is a question of legal basis. Since you gather names through informal conversations, I think that attendees would be weirded out if they learned that you kept detailed records on their attendance. So I think that you probably wouldn't have a legitimate interest here. However, being upfront with this and offering an opt-out could change this. On the aspect of keeping detailed notes on data from informal conversations, I'd like to point out H&amp;M's EUR 35 million fine back in 2020 (summary on GDPRHub.eu). In a callcenter, managers used to have conversations with employees. These conversations touched on anything from vacation experiences to health problems, marriage problems, and religious beliefs. All of that is fine. What was not fine is that the managers went full Stasi and kept detailed notes about all of this on a shared drive and used that information for management decisions. This went on until a configuration error made those files accessible to all employees. This violated all the points in the basic compliance process outlined above: the records had no clear purpose, no suitable legal basis, contained way more data than necessary (and even Art 9 special categories of data like information on health or religious beliefs which have extra protection), did not have appropriate measures to prevent unauthorized access, and did not fulfill data subject rights like the Art 13 right to be informed. In case this non-profit is a church or religious organization that had its own comprehensive data protection rules before the GDPR came into force in 2018, those can continue to apply per Art 91. This could probably address some issues of legal basis, but cannot circumvent the GDPR's general principles.