Are users&#39; personal notes about other users subjected to the GDPR right of access? Some applications, like Discord or Mastodon, allow a user A to put private notes (only accessible to A) next to the profile of another user B. This data is very probably Personal Identifiable Information (PII) according to GDPR: it is linked to a specific profile of B, but also to the profile of A. If user B wants to access to their data per GDPR, can / must you give user B the content of the notes entered by A about B? It seems a kind of breach of privacy because before a data-access request, the information in the note was information only known to A. To me, it seems that A is responsible for the data entered, but it seems the operator of the service still has PII about B and should probably give the data to B if B asks about it.
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.
See Art. 17(2) GDPR: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. So the controller must tell all other controllers (like google) to delete the data. The privacy policy must include the fact that data is made public.
Either approach can be GDPR-compliant. An issue to consider is that you as a data controller relying on consent “shall be able to demonstrate that the data subject has consented to processing of his or her personal data” (Art 7(1)). This might be simpler if a record of the consent is linked to a user account. On the other hand, the GDPR's data minimization principle would suggest that decentral, offline approaches are preferable. So you do have some flexibility here, as long as you feel comfortable demonstrating that your approach is compliant when investigated by a supervisory authority. In many cases, consent is not an appropriate legal basis to start with. It is one of several options in Art 6(1) GDPR. If a data processing activity is necessary for fulfilling a contract with the data subject, then Art 6(1)(b) is more appropriate. If the processing is necessary for a legitimate interest, then Art 6(1)(f) would work – after conducting a balancing test. Art 6(1)(a) consent is appropriate when the processing activity is not necessary, or when a legitimate interest balancing test doesn't go in your favor, or in some cases when required by law. For example, consent is required when processing special categories of data (such as biometrics), or when accessing or storing information on the end user's device, beyond what is necessary for a service explicitly requested by the user (the “cookie law”, but much more general than cookies). Consent also has heightened compliance requirements compared to other legal bases. The data subject must be able to make a free decision, without any coercion. You must not use dark patterns. You must leave the data subject a real choice. You must not make access to your app conditional on giving unrelated consent (like providing access to a game only when the user gives consent for personalized ads). The data subject must be able to easily withdraw consent later, without suffering detriment for this. The EDPB has issued relevant guidelines that might be helpful here: EDPB guidelines 05/2020 on consent EDPB guidelines 2/2019 on Article 6(1)(b) in the context of online services (also relevant for apps) TL;DR: what is “necessary” for performance of a contract is an objective question, and should generally be considered from the data subject's perspective. It is not possible to circumvent consent requirements by putting unrelated processing purposes like “analytics” into a services' terms of service. The main purpose of this document is to serve as a rebuttal of Facebook's GDPR compliance strategy. But it's perfectly fine to avoid asking for consent for those processing purposes that are actually necessary for the user. I've noticed that you mentioned various Google services like Analytics and Firebase. To the degree that your use of these services implies an international transfer of personal data into the US, it might be impossible to be GDPR-compliant. Be wary of claims that you're only transferring “anonymous” data, as the GDPR has a fairly broad concept of identifiability.
If the data controller has “reasonable doubts concerning the identity of the natural person making the request”, then “the controller may request the provision of additional information necessary to confirm the identity of the data subject” (Art 12(6) GDPR). Until the data subject provides this information, the request is paused. But what are reasonable doubts, and what additional information can the controller request? The GDPR itself provides no clear guidelines, though general principles apply – the additional information must be necessary, adequate, and proportionate for the identity conformation purpose. The controller's obligation to comply with access requests must be balanced with the controller's obligation to ensure the security of data by rejecting invalid requests. Just accepting any request without any verification would also be a breach of the GDPR. For example: If the company identifies data subjects by email address, then demonstrating control over the email address would be an appropriate verification step. But just mentioning the email address would not be enough since it could be someone else's email address. If the company provides a website where data subjects have created user accounts, then being able to log in to the account would be an appropriate verification step. In these examples, asking e.g. for government photo ID would not be appropriate because that doesn't help strengthen the link between the person making the request and the personal data being processed. Such data collection would be disproportionate and unnecessary. In contrast, if you walk into a bank and ask for a copy of your data, it would be entirely appropriate for them to ask for government ID because (a) the higher general risks warrant stronger checks, and (b) such ID will help confirm that the person making the request is indeed the proper account holder. The bank will also have been legally required to request ID when the account was originally opened, so that asking for ID as an identity verification measure during this later request won't involve collection of more data than they already have. (These examples were made up by me and are not official, but read on.) The EDPB has issued draft guidelines on the right of access 01/2022, which also discuss the issue of additional information for identity verification in sections 3.2 and 3.3. In particular, paragraphs 73-78 talk about IDs: 73. It should be emphasised that using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law. […] it is also important to note that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) […]. 75. In any case, information on the ID that is not necessary for confirming the identity of the data subject, […] may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card (see para. 77 below). […] 76. […] Example: The user Ms. Y has created an account in the online store, providing her e-mail and username. Subsequently, the account owner asks the controller for information whether it processes their personal data, and if so, asks for access to them within the scope indicated in Art. 15. The controller requests the ID of the person making request to confirm her identity. The controller's action in this case is disproportionate and leads to unnecessary data collection. […] Example: A bank customer, Mr. Y,, plans to get a consumer credit. For this purpose, Mr. Y goes to a bank branch to obtain information, including his personal data, necessary for the assessment of his creditworthiness. To verify the data subject’s identity, the consultant asks for notarised certification of his identity to be able to provide him with the required information. The controller should not require notarised confirmation of identity, unless it is strictly necessary, suitable and in line with the national law […]. Such practice exposes the requesting persons to additional costs and imposes an excessive burden on the data subjects, hampering the exercise of their right of access. 77. Without prejudice to the above general principles, under certain circumstances, verification on the basis of an ID may be a justified and proportionate measure, for example for entities processing special categories of personal data or undertaking data processing which may pose a risk for data subject (e.g. medical or health information). However, at the same time, it should be borne in mind that certain national provisions provide for restrictions on the processing of data contained in public documents, including documents confirming the identity of a person (also on the basis of Art. 87 GDPR). Restrictions on the processing of data from these documents may relate in particular to the scanning or photocopying of ID cards or processing of official personal identification numbers. To summarize: controllers can request IDs only in comparatively niche scenarios, and must then take additional safeguards to protect the sensitive document (e.g. instructing the data subject to redact parts of the ID, not making copies, and immediately deleting the ID after successful verification). A lot here comes down to national laws, which may explicitly require or forbid use of the ID in this context. The EDPB guidelines are not binding or normative, especially since this guidance is still in the public consultation phase. However, the guidelines present an overall consensus of the national data protection authorities in the EU, and the guidelines are regularly cited by courts. In practice, many controllers do ask for disproportionate amounts of data. Sometimes this seems to be an attempt to discourage data subject requests, which would clearly be non-compliant. In some cases, this is due to a narrow interpretation of “reasonable doubts” in which they try to eliminate any doubt about the identity. If the data subject and data controller cannot agree on a suitable identity verification process, then the data subject can: Art 77: lodge a complaint with a data protection authority, and/or Art 79: sue the data controller in court, both for compliance (fulfilling the request) and for compensation (if damages were suffered). It is worth noting that the data controller is responsible for being able to demonstrate compliance (Art 5(2) accountability principle), such as demonstrating the apparent reasonable doubts to a supervisory authority or to a court. When the controller requests ID, the controller has the burden of proof to show that this is compliant.
If you publish a website, you are the data controller for this website. Serving a website necessarily implies processing (but not collection) of personal data. You have chosen to host your website on GitHub Pages. Is GitHub then a joint controller with you, or is GitHub your processor with which you sign a DPA? In 2019, I asked GH customer support about this. Their response: Our Privacy Statement, combined with our Terms of Service, is intended to serve as a data protection agreement for individual accounts — we specifically wrote our Privacy Statement to provide the information required by Article 28 of the GDPR, including a list of our subprocessors. Our Privacy Statement and our Terms of Service serve as our agreements with you, as the controller, instructing us as the processor, and you can always contact us to provide additional instruction. Should we receive a data subject request that relates to data we process on your behalf, we'll always let you know promptly and work with you to comply. — Github, 2019-04-10, private communication At the time, their Privacy Policy described GH Pages as follows: If you create a GitHub Pages website, it is your responsibility to post a privacy statement that accurately describes how you collect, use, and share personal information and other visitor information, and how you comply with applicable data privacy laws, rules, and regulations. Please note that GitHub may collect Technical Information from visitors to your GitHub Pages website, including logs of visitor IP addresses, to maintain the security and integrity of the website and service. (Update 2022: the privacy notice has since changed, and the quoted part is no longer part of the privacy notice.) Under this theory: you are the controller, and GH is your processor the terms of service incl. GH privacy policy form an effective Data Processing Agreement you have instructed GH to collect Technical Information in the sense of the privacy policy, for the purpose of maintaining security and integrity of the website, which can be covered by legitimate interest you have not instructed/allowed GH to process any other data from your site It is your call whether you subscribe to that theory. Note that GH organizations can opt-in to their corporate terms and sign an explicit DPA which will mostly contain the same provisions. Does it matter that you don't have access to the Technical Information? No. Being a controller means that you decide the purposes and means of processing, not that you store data. You as a controller can always decide to point your domain name to a different server if you no longer want to use GH as a processor.
I know that I have to provide detailed information which data I save and how I use it. Yes, you should, if you are getting access to users' Dropbox accounts, which will contain all sorts of private data, copyrighted (and illegally copied copyrighted files), etc. You provide the detailed information to your users through a click-through Privacy Policy - TOS (Terms of Service) in your App, like any other App out there. Click wrap (Wikipedia) user agreements are legally binding in many jurisdictions. Even if you don't access files and information - such as personal information or files - you still need a clear TOS for your App, for both your users' and your own legal protection. But I am a poor student who don't want invest money into a lawyer to write me a privacy policy ... I do not plan to get paid for (this app)... Being a free or paid App doesn't make a difference when it comes to the TOS, if you need one, and if you need to pay for one to be drafted. But not investing money in a lawyer can be a critical mistake if your App will be distributed on the popular App directories like Google Play and iTunes and your TOS does not clearly and legally outline all possible usage and data polices. Lawyers have experience in covering all the bases. Is there any way I can do this privacy policy on my own? Sure, you can: https://www.google.com/search?q=privacy+policy+generator But you run considerable legal liability not having a TOS that correctly and legally addresses all users' privacy concerns and clearly outlines what you do to insure security. That's what lawyers are for. Is it possible to just create some “I save all your data“ policy which would of course be to much but it would include all data I save and so I would not miss anything in my policy? Sure, you can simply say I save all your data. But how can you be sure that you've haven't missed important policy details and scenarios that could result in legal action against you? Like how long do you save data? When will you delete it? How secure is it? Can the user ask for deletion? What happens if you get hacked? What about users in countries other than the US? Users under 18 years old? You must use arbitration for any disputes? And on and on. The considerable legal liability of using a non-professionally drafted TOS means you run the risk of getting sued. You have to decide if it is worth the risk.
“From your perspective you should not worry about asking permission to use reCaptcha as it is not you who is processing the data it is google and any GDPR compliance falls on them.“ This is plain wrong. If a user visits your website you are the controller of data collected on your website. Regardless of what entity collects that data. However in my non-legal opinion reCAPTCHA falls under Article 6 section 1d and 1f. Also Recital 49. 1d: “processing is necessary in order to protect the vital interests of the data subject or of another natural person;” While you could argue in some cases (most probably) reCAPTCHA is used to reduce spam to a business entity thus not a “natural person”. 1f: “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.” Here is where the real ruling applies “Legitimate interests”. You as a business have a legitimate interest in reducing spam into your business. Not only does spam take up your time but it also takes up your resources. As to the extent in which spam takes up is dependent on the usage in question. But nearly everyone can safely assume reducing spam (one of the cornerstones of the GDPR) is a legitimate interest. Recital 49 (excerpt): The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, […] by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems.
IANAL, But the information commissioners office (UK) describe personal data as: (bolding mine) The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people. https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/ So I would say that in your case it is personal information. In principle, regardless of if you can identify an individual, personal data is that which can be used to potentially identify an individual. For an extreme example of why this is important: Lets say your app sells AIDs medication. Can a hacker who got in and stole your database, be able to use that with information they stole elsewhere to identify people with AIDs and blackmail them, in a way that they wouldn't if you had not stored this identifier? Plus, if you want to err on the side of caution, there's no legal penalty for telling the user about non-personal information you store.