A general question under Personal Data Privacy Suppose X is a student body that holds a database of comments made by its members about the lecturers of ABC University. Professor Y from ABC requests X to send him a copy of all comments about him. Should X comply, and if so, how?Additionally, Suppose there is a comment that says "Y is the worst lecturer in ABC University".Suppose the head of the History Department requests X for comments on all the lecturers of the History Department at ABC University, should he comply? My understanding is he doesn't need to comply in any of the three cases as other data users, i.e respective members who posted the comment controls the use of the data. Would that be right?
Art. 15(4) GDPR says: (4) The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others. If I was the controller in this situation, and I believed that this would endanger the students that have criticised the professor, I would base my argument for not complying on this. In addition, Art. 85 GDPR requires member states to: [...] reconcile the right to the protection of personal data pursuant to this Regulation with the right to freedom of expression and information [...] So you may be able to argue that the students posting messages are engaging in "processing for journalistic purposes and the purposes of academic, artistic or literary expression", depending on the laws of the particular member state. (edit: this could be difficult since you mention it is a private database). The second case seems just like the first in terms of GDPR, but may constitute defamation. Defamation (or libel) laws differ wildly in each country; he Wikipedia article on Defamation explains the situation in each member state in more detail. In the third case: if the professor submits a request based on the rights of a data subject other than himself, they don't need to comply. These requests need to come from the data subjects themselves, not just a random person assuming authority. (although I suppose it's possible for them to give power of attorney to the department head if they wanted to) Personal data and the rights that GDPR provides to data subjects always relate to a natural person, not an institution or a company.
Neither the GDPR, nor the CCPA, nor any other data protection law that I am aware of, requires that when information is deleted on request, that similar information not be collected and stored in future. Under the GDPR Article 6 there would have to be a lawful basis for any processing, including storage, assuming that the GDPR applies to the directory in question. There could be a claim that such processing was lawful under article 6(e) &quot;performance of a task carried out in the public interest&quot;. I do not know if any such claim has been adjudicated. Thus there is no need to hold a database of previously erased records to determine if a new record should be blocked as &quot;previously deleted&quot;. The Wikimedia Foundation, which runs Wikipedia, I believe takes the position that the GDPR does not apply to Wikipedia, I am not sure of their detailed arguments. But surely articles on well-known people, such as a former US president, would be covered under the same provisions as would cover news reports and historical books about such a person. Perhaps that would also come under article 6(e)
TL;DR In theory there's nothing wrong with your method, it's just a way to authenticate the user, and without authentication a user has no right to request anything anyway. But in practice it looks like your method doesn't have a way to deal with situations where users lose or forget their authentication data and want to be able to recover their account. Failing to deal with that in a modern system might be considered an unacceptable bad practice and so be against the GDPR principles of security and privacy by design. EXTENDED VERSION I might be wrong or not understand the question correctly, but I don't see how this is different from many other common cases where encryption is not involved. Think about it, you aren't able to give the user their own personal data unless they provide the ID and encryption keys. How is this significantly different from the fact you aren't able to (or rather you should not) show a user their own data unless they provide their own username and password, or they convincingly authenticate themselves in any way? Just like you can't ask Facebook to show you all the data collected about Donald Trump only by claiming you are Donald Trump, you can't be required to give a user their own data unless they provide the encryption key. It can be seen as your way to authenticate users (among other things). Edited: multiple IDs/keys I didn't understand your method involved multiple IDs and keys. In theory, the situation is still the same, only with multiple pieces of data for authentication, like the user had to remember multiple usernames and passwords. Failing to provide all IDs and all keys will result in a partial authentication. But with such an approach a potential problem becomes more evident: your authentication scheme might be against the GDPR principles of "security and privacy by design and by default". Basically, your methods might be considered bad practice because they fail to deal with the common issue of lost or forgotten passwords. If a user tells you they have lost a USB drive containing all their IDs and keys and they don't have them anymore, what do you do? You can't delete their data because you aren't able to know what their data is, without another way of authenticating. And their data is now at risk, because somebody else might have their IDs and keys. If you had an email address associated with all the user's IDs and data, then you might be able to confirm their identity (for example sending an email with a link) and delete all their data. As you see, things can get pretty complicated, it all depends on the details of your implementation, and just adding or removing one detail might change the whole scenario.
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
The data you cite as PII are simply facts that are public information; your name, photo, your school, track meets, race times, track records, and you have little recourse against the publishing and dissemination of public information, either on a site like Athletic.net that collects and scrapes public information, or against the original sources, such as news outlets and school officials. Collecting and publishing public information is clearly allowed under press freedoms and the 1st Amendment. And, concerning photos: news outlets have the clear right to photograph people in public spaces and identify them. A possible exception regarding athletic.net is the Children's Online Privacy Protection Rule ("COPPA") for children under the age of 13. But they cover that in their Privacy Policy and offer a removal policy. One other possible exception is FERPA, the federal student record law, as pointed out by user6726 in their answer; see eCFR — Code of Federal Regulations. But your parents may have signed a release to allow the information to be made public. In the event neither of those exceptions is the remedy, you would need a court order to force Athletic.net to remove information, and you would need to show very compelling evidence that such data is harmful to you in order for the court to risk violating the First Amendment. Also see Cyberstalking and RateMyProfessors.com
Yes such a username would be personal data. It is information that relates to an identifiable person. In this context,a person isn't identifiable only if you can infer their real-world identity, but already if you can single out one person's records. Thus, your random IDs and any linked information would be personal data as well. Just because something is personal data doesn't mean that processing it is illegal. It just means you need a legal basis. That could be necessity for performing a contract with the data subject (like saving game progress), a legitimate interest, or consent. Taking into account GDPR principles like &quot;data protection by design and by default&quot;, it could be sensible to hide a players stats from the leaderboard until they give consent. On the other hand, you may have a legitimate interest to provide leaderboard data for ranking/comparison, especially if the leaderboard entries are pseudonymized. In any case, it should be clear to the users which information is visible to others.
Just at the offset this does not constitute legal advice, just some opinions I have on this point. Technically, you would not be prohibited to generate speech and use it however you like. Under normal circumstances any output generated by the system that does not contravene the service agreement would be your intellectual property. This would include the text and speech generated. Once you go about the request limit you would naturally be required to pay, but until that time you can use the service as a paying customer. Just to clarify this point I would like to make reference to the service license agreement, clause 3, which make reference to the following prohibitions: (a) copy, modify, create a derivative work of, reverse engineer, decompile, translate, disassemble, or otherwise attempt to extract any or all of the source code of the Services (subject to Section 3.4 below and except to the extent such restriction is expressly prohibited by applicable law); (b) use the Services for High Risk Activities; (c) sublicense, resell, or distribute any or all of the Services separate from any integrated Application; (d) create multiple Applications, Accounts, or Projects to simulate or act as a single Application, Account, or Project (respectively) or otherwise access the Services in a manner intended to avoid incurring Fees or exceed usage limits or quotas; (e) unless otherwise set forth in the Service Specific Terms, use the Services to operate or enable any telecommunications service or in connection with any Application that allows Customer End Users to place calls or to receive calls from any public switched telephone network; or (f) process or store any Customer Data that is subject to the International Traffic in Arms Regulations maintained by the Department of State. Unless otherwise specified in writing by Google, Google does not intend uses of the Services to create obligations under HIPAA, and makes no representations that the Services satisfy HIPAA requirements. If Customer is (or becomes) a Covered Entity or Business Associate, as defined in HIPAA, Customer will not use the Services for any purpose or in any manner involving Protected Health Information (as defined in HIPAA) unless Customer has received prior written consent to such use from Google. Similarly, as specified here: Customer will not, and will not allow third parties to: (i) use these Services to create, train, or improve (directly or indirectly) a similar or competing product or service or (ii) integrate these Services with any applications for any embedded devices such as cars, TVs, appliances, or speakers​ without Google's prior written permission. These Services can only be integrated with applications for the following personal computing devices: smartphones, tablets, laptops, and desktops. In addition to any other available remedies, Google may immediately suspend or terminate Customer's use of these Services based on any suspected violation of these terms, and violation of these terms is deemed violation of Google's Intellectual Property Rights. Customer will provide Google with any assistance Google requests to reasonably confirm compliance with these terms (including interviews with Customer employees and inspection of Customer source code, model training data, and engineering documentation). These terms will survive termination or expiration of the Agreement. You should also take a look at this and this. However, as per the terms of the agreement the speech generated would be your intellectual property, unless otherwise specified. Good luck!
Great question - I work for a London based company who use a large amount of location data. The process for deletion of data is not as simple as it first sounds. We recently had a deep dive with our legal team and as a result actually created a product to process deletions. Personal data from users/customer is carried for lots of reasons, not just marketing. What if you're asked to delete data that is needed to bill customers, information that may be relevant to a legal case or information that needs by law to be retained for the purposes of audit? GDPR does not make it illegal to carry personal information, it simply needs you to justify why you are keeping the information - inform the named person about this and provide them with a timescale for deletion. For example if you are required by law to store a record of emails to document the work done, but the user asks you to delete that information. You would be entitled to keep that information but only for the purposes of maintaining that audit trail. You would delete all associated customer data that was unnecessary such as CRM info, payment details etc.. but could keep the audit trail. The proper way to respond to the user's deletion request would be "your data will be kept in a secure server for the purposes of maintaining an audit trail for x amount of time. Once this time has elapsed it will be deleted. If you are unhappy with our use of this data please contact our data officer". GDPR isn't designed to catch you out - if you have a legitimate reason to keep that information then you are entitled to. The law was designed to stop marketers and advertisers hoarding huge amounts of information, as well as undermine Google/Facebook's duopoly on our personal information.