Is a website OK with GDPR if it is not permitting the users to delete their posts? 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. Is it against the right to erasure mentioned here as a part of GDPR?
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
No, it is not legal. Regardless of their location, the only legal options for companies serving to EU residents are to either deny access altogether or to make consent truly optional1 Recital 42 states (emphasis mine): Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement[...] Recital 43 states: Consent is presumed not to be freely given [...] 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. 1 Of course, remember that consent is only one of several means that allow them to process data. For example, if you were getting a trial account for a limited time, it would be considered a legitimate business need to ensure that you are not just opening new trial accounts when the old ones expire. So, if they wanted some data from you to ensure that you are not a previous user and you refused to provide it, then they could deny giving you that trial account without breaking the GDPR.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
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
Update: On 1 October 2019 the CJEU ruled in Case C‑673/17 (Verbraucherzentrale Bundesverband vs. Planet49 GmbH) that cookies require explicit consent regardless of personal data is being processed. (Where the exceptions don't apply). (paragraphs 68-70 of the ruling). That does probably invalidate my answer below. However, because I have based my answer on information provided by the Dutch DPA, I will not update my answer until that DPA has responded on this. Basically, your thoughts are all correct. The Dutch DPA (Autoriteit Persoonsgegevens) has written a manual how to use Google Analytics compliant with the GDPR without having to ask for consent. But unfortunately it is not available in English. Based on Art. 28 GDPR, you need a Data Processing Amendment with google. Open the settings menu from Google Analytics Go to Admin Choose Account Settings Scroll down to the data processing amendment Open it Accept it Click Save Anonymize your visitors IP Address. A full IP address is considered personal data. It is possible to remove the last octet before it is processed by google. Add { ‘anonymize_ip’: true } to the tracking code on your website Create a screenshot of the change, so you can prove later at which date you made this change. Disable Data Sharing with google. By default Google uses the data for 5 different purposes. Each of them would require consent from the visitor of your website. So you need to switch that off. Open the settings menu from Google Analytics Go to Admin Choose Account Settings Scroll down to the data sharing settings Uncheck all checkboxes (Google producs &amp; services, Benchmarking, Technical support, Account specialists and access for sales experts) Click Save Disable Data Collection for Advertising. This has to be disabled at a different location, for the same reason as the previous step. Open the settings menu from Google Analytics Choose Property settings Choose Tracking info Choose Data collection Turn off these two options (remarketing and advertising reporting) Click Save Disable the User-ID feature. This is probably turned off by default. But it is important to keep it turned off. So you need to verify this. Open the settings menu from Google Analytics Choose Property settings Choose Trackinginfo Choose User-ID Disable it Click Save Even though you don't need consent to use Google Analytics, you still need to inform your users, for example by adding a few lines to your privacy policy explaining: You are using Google Analytics cookies. You have a data processing agreement with google. You have enabled IP anonymization/masking. You have disabled data sharing. You are not using any other google services in combination with Google Analytics. The Autoriteit Persoonsgegevens still recommends to offer an opt-out for Google Analytics, but it would not be required. As the Autoriteit Persoonsgegevens is a DPA as defined in chapter 6 of the GDPR, you have to assume their advice really is GDPR complaint. In the past they also had performed other investigations to the privacy policies of google.
Note that the answer to most of your questions has nothing to do with the GDPR specifically, but has to do with the legal force that an EU Regulation has. Here's a related answer on EU Regulations vs. Directives. That said, here are my answers to your specific questions: So member states can define a different age, even though the GDPR says that it should be 16. But is this an exception? Yes. Are there any other exceptions? Yes. Scanning the Regulation for instances of "Member State" is a good way to find them. In my opinion, the biggest area of the GDPR where Member States have influence is Article 6, "Lawfulness of Processing". In some circumstances, it allows Member States to specify what could be considered a lawful basis for processing. Must these exceptions be explicitly stated in the GDPR? Yes. As a Regulation, exceptions must be explicitly stated in order to be permissible because Member States have no authority to overrule EU law*. I'd like to understand to what extent the GDPR must be followed by member states, and to what extent it could be amended in national laws. "Amended" is a fuzzy term. It can mean adding, changing, or removing from the law. Unless otherwise specified, Member States could not change or remove provisions, but there could very well be additions consistent with the GDPR. *Some Member States dispute this statement when it comes to constitutional issues.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).
The Right to Access is pretty absolute. However, there are some limitations: Is the service even the Data Controller for the data in question? Here, you're talking about notes of one user about another. Is the platform the controller for the notes, or would the note-taker be the controller? Or both, jointly? If the platform weren't a controller but merely a data processor for these notes, it would be illegal for them to disclose the information. Trish also correctly points out that the GDPR does not apply to processing for purely personal or household purposes, e.g. personal social media use. So GDPR would not provide a basis to compel a user to disclose their notes to the data subject, assuming that the note-taker is covered by this exception. Of course, this exception wouldn't apply if the notes are taken for other purposes, e.g. professional networking. Also, this exception doesn't affect the platform. There is an explicit limitation to the right of access in Art 15(4): The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others. Disclosing user A's notes about user B to user B would likely violate the privacy rights of A. The notes are both A's and B's personal data. However, the correct balance depends on context. E.g. an employer probably can't refuse to provide access to a performance assessment merely because it was written by an identifiable manager. The UK ICO has provided detailed guidance on this aspect to the right of access. They propose a three-step test: Step one – Does the request require disclosing information that identifies another individual? For example, it might be possible to redact other people's information (but not in your Mastodon notes example). Step two – Has the other individual provided consent? Step three – Is it reasonable to disclose without consent? What is reasonable is highly context-dependent, but UK data protection law gives some concrete criteria to consider. The EU EDPB has draft guidance on the Right to Access. They note that the Art 15(4) can cover a wide range of rights, not just other people's privacy rights. But as in all things, the data controller is required to strike an appropriate balance between user A and B's conflicting rights. In the Mastodon user notes scenario, I think that the note author's rights to privacy should be considered more important than the data subject's right to access those notes, thus making it possible to reject that part of a DSAR under Art 15(4) GDPR. If we assume that the note-taker A is a (joint) controller for these notes, then it would also be necessary to consult them before making a decision about the access request.