Who is rightful owner of Gmail personal email account? I had created a Gmail account for office use by providing my credentials (first owner). After quitting job, still I am using this account for my use. My ex boss demanded me to handover said account to company immediately. He called me a hacker. Does my former employer have any right to this Gmail account?
The Google TOS says, applicable to creation of accounts: You may create your own Google Account, or your Google Account may be assigned to you by an administrator, such as your employer or educational institution. If you are using a Google Account assigned to you by an administrator, different or additional terms may apply and your administrator may be able to access or disable your account. To protect your Google Account, keep your password confidential. You are responsible for the activity that happens on or through your Google Account. So the account wasn't created for you by an administrator, and it is your own Google account. The terms say that you are responsible for what happens with your account, thus if you were to turn over the password to someone else and they did illegal things, you would be responsible (at least with respect to your legal relationship to Google). Google does have business email, which your employer apparently did not utilize. In order to have actual ownership of the account, the business would need to set up the account for you and claim initial "ownership". If you create an account for the convenience of a business, that convenience – but not the account – is a gift from you to the business.
When you use other services, the question is whether that service acts as an independent data controller, or as a data processor who only uses the data on your behalf. When engaging a data processor they must be legally bound to only use the data on your behalf, for example with a contract / data processing agreement (DPA). See Art 28 GDPR. Data processor status is attractive because processors are seen as an extension of the controller. In contrast, when sharing data with other controllers you would need a separate legal basis to authorize this sharing. Google offers tons of different services, so this question needs to be considered on a case by case basis. For Google Cloud services or Google Workplace, Google generally acts as a data processor. For other services, Google acts as a controller. Notably, Google Fonts does not offer a DPA so that you cannot claim they're acting as a processor in that context, regardless of what other Google services you use. An equally important problem when using Google services is the data transfer problem. Google is controlled from the US, but the US do not offer an adequate level of data protection (see the Schrems II judgement). Comparatively few Google services allow you to select where the servers are located, as to prevent transfers of personal data to countries where privacy cannot be guaranteed. For example, this is why Google Analytics (GA) is problematic. Google acts as a data processor for basic GA features but makes no promises about the location of servers. Thus, using GA implies a (probably) illegal transfer of personal data to the US.
You ask the wrong question first What do you save in the database? Let's take an example of a door: Do you have a legitimate interest to know/save who passed this door? Do you have a legitimate interest to know/save when the door was opened? Do you have a legitimate interest to know/save both? Only now, once you have established that you have any interest in the door passing at all, you have to start to figure out if it is personal data - if you have no interest in saving it in the first place, there's little reason to figure that out. Let's say you have a legitimate interest to save both, because behind the door is the server room, and physical access is limited to authorized personnel and you want to know when who was in there for figuring out if or who was responsible for changes. Now, which of the data is Personal Identifiable Data for you? You know where the door is. That's in itself Location Data, but if you don't know who or when the door was opened, then it is not PII. It becomes PII if you connect it with a person. A pin-code used by the whole department is not always PII, but can become PII in a very small to medium-sized department. e.g. one of all the 20 000 employees in a facility is just saying &quot;an employee&quot; and is not identifiable, but one of 20 is much more likely is, as you can correlate that with other data to possibly identify a smaller group. The Employee ID or Card would be most definitely PII if saved. Similar, if the login date is saved to the account list on some server. The timestamp on itself is not a PII, if only the timestamp is recorded and no other information exists. Like, if the front door only logs &quot;The door was opened/closed&quot; but not who did it, to count customers or schedule maintenance. However, together with other information - such as the door being access restricted and the paystubs from timekeeping when all those access carriers were in the building and having a tight access restriction to a decently small group (see above) - that can quickly become PII. It is enough that the information from different information sources compiled can become enough to say &quot;it was one of these few people&quot;, as that is enough to make it identifiable under GDPR Art.4. Once you know it is PII, you need to handle it as PII. As such, you need consent or a legitimate interest. That's why I pulled the other test before figuring out if it is indeed PII: Ic you have already figured out that this data is required for some legitimate reason, such as that you need to know the door operation log to ensure some other compliance, then you can proceed through the other parts of the GDPR compliance. Now, OP asked about a login timestamp. That is by necessity bound to an identifier, such as a login name. As such, it is the Keycard or Employee ID example and automatically PII because it is tied to a PII. Definitions The GDPR defines PII in Article 4 ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; The US Department of labor defines quite similar PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification.
Both of your question are creatures of contract. Their disclosures when you set up the account (or potentially amended disclosures or terms they've mailed to you subsequently) control both of these questions. They don't have to share the results of their internal investigation against you (they do have to give you proof that the deposit/transfer was fraudulent), but that does not give you access to their internal investigative process or its findings. They cannot shut down your account based on protected reasons (race, class, gender, religion, etc.), but the can certainly close an account pursuant to their operating procedures, their rules, terms and conditions or disclosures - all of which you agreed to (implicitly or explicitly) when opening the account. There is likely nothing you can do about either of these issues, unless the contract you formed with them by opening the account gives you that right, which would appear in their terms of service, disclosures, etc., and these almost always protect their right to do most anything when it comes to protecting the overall best interest of the corporate entity.
The Apache 2.0 license purports to be irrevocable, but it also presupposes that the supposed licensor has the right to grant permission to copy. In this case, that is untrue, so there never was a proper license and nothing to revoke (the copyright owner grants permission in the form of "a license" which is a legal abstraction, that normally is specified in the license document). An end-user snared by this illegal license might attempt to sue the author because of the legal screw-up but paragraph 9 says that the supposed licensor cannot be held liable. In this case, though, "licensor" is defined not as the person who hands you the license document, but as the copyright owner. So it's the employer who would be not liable under the terms of the document (but since the employer had nothing to do with the license, it's as though the license never existed). The end-user is a secondary infringer (the employee is the primary infringer, in illegally distributing the material). Under US law, that doesn't matter, the user is still liable. Under UK law, secondary infringement includes the element that you have to have reason to know that the copy is infringing, which in the scenario that you describe is not the case.
a few quick notes that come to mind. As the commenters point out: DSGVO is indeed the German equivalent name to the GDPR (English term) "Imprint" isn't a privacy related topic that much, as such it's not really changed by the upcoming GDPR The GDPR changes many things, but the requirement for up front information isn't one of them - so it would've already been a rule to follow Sometimes the question who is responsible for privacy information might not be that easy to decide when you're on platforms. I take this situation as being pretty clear though. You are basically given a blank slate, you can do with that page whatever you want, and the visitor has no clue whatsoever that it might be hosted by Github. In addition to this, Github would be classified as a data processor (providing the tool) and you as the data controller who is in charge of practically everything except for the provision of the page. I hope this helps. Btw. it's not that hard anymore to write a privacy policy these days.
Defamation requires communication to a third-party I can say (or write) anything I want about a person directly to that person and, unless it is a threat, they have no recourse at all. I can call them a liar, a thief, a Nazi, or a goat fornicator. Of course, I have to be careful – calling them a “bastard” might be a slur on their mother communicated to a third-party (them) which would give her a right to sue although that would require a literal and largely archaic use of the term. That said, you do need to check with your lawyer if you can redact names in the face of a subpoena - complying with a legal obligations is a legitimate use of personal data under GDPR.
I think this shows a misunderstanding of the meaning of the GDPR. A data subject has the right to demand information, correction, deletion etc. about some of their data held by some institutions, depending on the legal basis for the data processing. One John Smith does not have the right to see the data of any other data subject named John Smith, and he cannot even demand to know if there are other John Smiths in the database. The data controller has to make reasonable steps to ensure that an individual who seeks account information is in fact the individual who is the data subject. In the case of an email, that's usually easy -- if John Smith can access the mail account jsmith@sample.org, one can assume that he is the John Smith who opened the account. If not, then not. If the data controller has the birthplace and birthdate in their records, they can possibly match that against some government-issue identity document, too, but why would they have that data?