GDPR which practice is compliant? I have seen many ways of requiring user acceptance of their data usage on the internet. Which conform to GDPR? Keep in mind I am talking just about the consent acquiring mechanism. In order from the least options offered to the user to the most options offered: not allowing to use the site until the user clicks Accept. No options, just an &quot;Accept&quot; button. A banner stating that &quot;By browsing the site you accept the conditions&quot;. Just an &quot;x&quot; to close the banner. Using the site is allowed while the banner is displayed. A banner with an &quot;Accept&quot; (and possibly &quot;Reject&quot;) button. No other options. Site navigation is allowed while the banner is displaying. A banner with an &quot;Accept&quot;, &quot;Reject&quot; and also a &quot;Settings&quot; options where the user can fine tune the way his data is being used by the site. I have heard from developers who have studied the GDPR that the law requires options for fine tuning settings (something like data required for basic functionality, data required for site analytics, data required for personalized ads, etc.). Which if true would make only the last variant above compliant. However I have personally observed only a handful of sites implementing this. Are all others non-conforming?
Overview As described, only the last of these seems to be compliant ways of obtaining consent, and indeed even that is not fully compliant, although features not described might make it so. However, if there is a lawful basis for processing PI other than consent, under GDPR article 6, then there is no need to obtain consent at all, and doing so in an improper way is irrelevant. However storage of or access to local information (such as cookies) requires consent unless such storage or access is &quot;strictly necessary&quot; for providing a service which the user has requested. Relevant GDPR Provisions GDPR article 6 lists six possible lawful bases for processing personal data. These are, in summery: (a) consent; (b) processing is necessary for the performance of a contract or to takwe steps requested by the Data Subject; (c) necessary for compliance with a legal obligation; (d) to protect the vital interests of the data subject or another person (e) or the performance of a task carried out in the public interest (f) legitimate interests of the Controller The other provisions cited here apply only to PI for which the lawful basis is consent. GDPR article 7 reads: (2) If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. (3) The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent. 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. GDPR Recital 32 reads: 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. 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. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided. GDPR Recital 42 reads: ... in particular in the context of a written declaration on another matter, safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given. In accordance with Council Directive 93/13/EEC a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended. Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. GDPR Recital 43 reads: ... Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. Analysis I will review each of the scenarios in the question in turn. Scenario 1: not allowing [a user] to use the site until the user clicks Accept. No options, just an &quot;Accept&quot; button. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). It appears that the provision of a service (use of the site) is conditional on consent not needed for that service (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 2: A banner stating that &quot;By browsing the site you accept the conditions&quot;. Just an &quot;x&quot; to close the banner. Using the site is allowed while the banner is displayed. This does not constitute freely given consent, because: Consent was not &quot;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&quot; (Art 7(2)). The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). the data subject has no genuine or free choice (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 3: A banner with an &quot;Accept&quot; (and possibly &quot;Reject&quot;) button. No other options. Site navigation is allowed while the banner is displaying. This does not constitute freely given consent, because: The giving of consent is not &quot;clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language&quot; (Art 7(2)). There appears to be no way to withdraw consent (Art 7(3)). Consent is not informed and unambiguous (Recital 32). The use has not been informed of the extent to which consent is given (Recital 42). The subject has not been made aware of purposes of the processing (Recital 42). There is no provision for separate consent to be given to different personal data processing operations. (Recital 43). Scenario 4: A banner with an &quot;Accept&quot;, &quot;Reject&quot; and also a &quot;Settings&quot; options where the user can fine tune the way his data is being used by the site. This might constitute freely given consent, provided that: a document is displayed or linked to that describes the kinds of PI that will be processed, and the purposes of the processing; There is some easy and obvious manner to withdraw consent, and to change the individual choices on what to consent to, after the banner has closed, or on any subsequent visit to the site; The consent section of the settings dialog must be clearly distinguished from other sections that do not deal with consent; Just where the lines must be drawn between &quot;different personal data processing operations&quot; which each requires the possibility of separate consent is not yet fully clear. And again, if the site or service does not store or otherwise process PI, or has a lawful basis for doing so other than consent, and does not store or access local information, it need not obtain consent at all, and the question of what constitutes freely given consent becomes irrelevant. Of course many sites do depend on consent as the lawful basis for much of their activity.
A data controller is whoever determines the means and purposes of processing. It is possible that multiple controllers jointly determine the means and purposes. However, someone can only be controller over processing activities where they actually have the ability to influence these decisions (see e.g. the Fashion ID case). The provider of an app does not have any control over what Google does on its servers with the collected data, unless Google were a data processor for that particular processing activity. Thus, the app provider is not a data controller for Google's subsequent processing, and is not responsible for Google's GDPR compliance. HOWEVER, the app provider is a data controller regarding what happens within the app (including any SDKs, libraries, or frameworks). The app provider is data controller for processing activities such as “collecting data” and “sending data to Google”. These processing activities must comply with the GDPR (if GDPR applies), for example they need a legal basis. Under some circumstances there might be a legitimate interest for sending data to another data controller. But in the context of behavioural advertising, such a legitimate interest would be very weak and would not pass the required balancing test. Instead, the app provider would likely have to collect consent. This is very similar to the question of whether a website can embed content from Google services such as YouTube videos, which would necessarily share data with Google. I have written related answers here and there. You are correct that many apps do not collect valid consent before showing ads. GDPR/ePrivacy enforcement in this space is rather lacking, especially since many offenders are outside of the EU. However, this doesn't mean such illegal data processing by apps would be OK.
In short, no. Article 20 of the GDPR covers the “Right to data portability”, which essentially says two main things: The data subject had the right to an exported copy of their personal data in a common format And The data subject has the right to have this data transmitted directly from one controller to another where technically feasible. Neither of these rights as stated in the GDPR require the data controller to provide a button to initiate either a data export or a transfer to another controller.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/
Think of a website that has gives no option for the users to delete what they have posted -but still the users can delete their account completely. That's easy - this is exactly how all StackExchange sites (including this one) work :-). See for example: How does deleting work? on meta.SE. Is it against the right to erasure mentioned here as a part of GDPR? No, it is not (otherwise StackExchange would be in rather big trouble). The "right to be forgotten" is subject to limitations. Most importantly, it only applies to personal data. Personal data is defined as (GDPR, art.4): any information relating to an identified or identifiable natural person (‘data subject’) If what you posted contains no personal information about you, it is not "relating to" you. The details are complicated (as usual, see e.g. The GDPR: What exactly is personal data?), but "personal data" is things about you (your name, your address, your sexual history, maybe even your IP address). On the other hand, if someone asks how to solve a programming problem, and you write an answer explaining what API to call, that answer is not personal data. In addition to that, even personal data may be retained if the data controller has a need to retain that information. This is also covered in article 4. For example, the controller may retain information "for the establishment, exercise or defence of legal claims" - otherwise you could buy something online without paying, and then ask the seller to forget about your purchases so they cannot collect the outstanding payment. So, in summary: A website will need to allow users to delete or hide personal data that they posted - such as their user profile information, or personal information in their posts. That does not mean they are allowed to delete entire posts - it is enough if personal information is redacted or anonymized. The website may be allowed to retain that information (hidden) if they can show legitimate interest - for example billing information, or posts that are the subject of a lawsuit. The StackExchange network, for example, covers this by allowing users to: disassociate posts from their account delete their account entirely (thus effectively disassociating all posts from personal information) asking a moderator for redaction of personal data
GDPR will continue to apply to UK customers directly until the end of the transition period (31 December 2020): So, while the UK will no longer have any voting rights, it will need to follow EU rules. The European Court of Justice will also continue to have the final say over any legal disputes. Thereafter, the Data Protection Act 2018 will continue to apply (which itself applies "GDPR standards"). Six of one, half a dozen of the other.
What would be the legal validity of this behaviour? Your changes to the browser source of the website contract or license of Terms of Service (TOS) - essentially a "click-wrap" license - before agreeing to it means nothing in a legal sense, other than to void the contract. The other party (the website) can't possibly agree to those contract changes without them being submitted as contractual changes and agreeing to them, if they did agree to them. That's basic contract law. That website TOS probably has a clause that says that if you don't agree to the TOS in full, as written, without modifications, you can't use the website. And the TOS may also say that they reserve the right to prevent you from using the site by closing your account or even blocking your access. Your "witness" to the contract changes is meaningless, as your witness is not a party to the contract. And any witness to the fact that you have changed the terms of the TOS before agreeing to it would work against you in a civil proceeding as proof of your attempt at modifying the contract.
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.