Legal jurisdiction over cloud storage I work on software that is a project of an encrypted cloud, created to protect users privacy. We use a javascript crypto library called SJCL. Only the user has the decryption key. That means only the user will be able to access his files. Not even our team will be able to see what's going on in the user's space and we can’t get the user's decryption key. Is the legislation of country where servers are located prevail over legislation of country where company is registered? Can we launch our software in Estonia or Lithuania (servers + company)?
The law in every country where your service is available prevails. That means that if your servers are in Estonia, your file storage is in Lithuania, your company is in Switzerland, you are in France, you hold Thai citizenship, your users are in the USA and the signal transits through the U.K., Belgium, Germany, Canada and Poland then you are subject to the laws of each and every one of them. In addition, if China has reason to believe that the stored files contain matters relating to their citizens then they can take an interest. And so on and so forth ... A country has jurisdiction wherever it wants to have jurisdiction subject to the limits of and its ability to actually enforce its laws. What you are proposing is certainly illegal in many countries and you need to seek professional legal advice - not rely on strangers on the internet.
Maybe, but probably not The geographic location of the organisation is immaterial: under Article 3.2: This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: ... (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. Posts anyone (not just EU citizens) make to Reddit (or anywhere else) while they are physically located in the EU or UK engage the GDPR. Pushift.io is therefore captured by the GDPR and any denial of that is just plain wrong. Given the denial, it is likely right out of the gate that they are non-complient. For example, they are unlikely to provided the required information under Article 14. More importantly, it seems that they have not determined the lawful basis for processing the data under Article 6 - they can possibly rely on the public interest basis (preserving deleted publication is arguably a public interest) or a legitimate interest but that requires a balancing of their interest against the data subject's. That said, the right to be forgotten is not absolute, the reasons that might be applicable here are: The data is being used to exercise the right of freedom of expression and information. The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority. The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
You won't be able to get around self-doxxing yourself. § 5 Abs 1 TMG requires tele-media service providers like you to list den Namen und die Anschrift, unter der sie niedergelassen sind the name and the address where they reside or are established Similarly, Art 13(1) GDPR requires you to provide the identity and the contact details of the controller In a German context, it is generally accepted that both of these involve a ladungsfähige Anschrift, i.e. a street address where you could be served with a lawsuit (not a post box). These requirements exist for both natural persons and legal entities, and for both businesses and non-commercial activities. The TMG Impressumspflicht talks about “geschäftsmäßige, in der Regel gegen Entgelt angebotene Telemedien” but in practice this only requires that the service could be paid (not that you're actually making any money), and that the service is offered routinely/business-like (not necessarily commercially). It does not matter where your service is hosted as long as you live in Germany. The TMG and GDPR might not apply if the forum is run purely privately, e.g. if it is only made available to a few close friends or family members.
GDPR definitely applies. Your scenario seems to raise two questions: What is the legal basis for processing? Are the security measures appropriate? Legal basis Every processing activity of personal data requires a legal basis. Most well-known is consent, but there are six categories in Art 6(1) GDPR including legitimate interests and necessity for performing a contract with the data subject. Conditions on consent are laid out in Art 7 GDPR. You say that data subjects “explicitly agree to the website's privacy policy and GDPR”. The GDPR does not generally expect “agreement” to a privacy policy, as information per Art 13 is an unilateral notice. Such general agreement also cannot constitute valid consent. In the context of certifications, the legal basis would likely be necessity for performing a contract with the data subject: You were contracted to provide this validation service to the data subjects. You should however make it clear which information will be displayed on the validation page (other than a valid/not valid) response. For example, I am concerned that showing the email address would not be strictly necessary for providing the validation service. You should also consider whether this validation service is a core component of your certification service, or whether there should be an opt-in or opt-out here. Security Measures The GDPR requires that you implement appropriate security measures, “taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms” of the data subjects (see Art 32 GDPR). This gives you a lot of leeway to determine what measures are appropriate, but also criteria that you must consider in your determination. A number of security measures are explicitly suggested and must also be considered: pseudonymization and encryption ensuring confidentiality, integrity, availability, and resilience of your systems ability to restore the service (e.g. backups) processes for regularly testing and evaluating your measures Aside from generic IT security measures like backups and providing the service over a HTTPS connection, I would be concerned about “insecure direct object reference” style attacks on the database. If I know that certification no 1234 exists, I could try to get the information for other numbers like no 1233 and so on. This would leak personal data. Basic defenses could include requiring additional information such as the data subject's name to be provided, or using anti-bot measures such as captchas and rate limits. However, the real solution is to avoid sequential IDs, and to generate sufficiently large tokens with a cryptographically secure random number generator. Instead of a “certification number”, it would be better to view this as a “validation code”.
The goal of the GDPR is to ensure a single market for personal data processing throughout the EU. Since all EU/EEA member states now have equivalent levels of data protection, it doesn't matter in which member state data is stored or processed. Member states cannot generally limit this single market via national laws. Furthermore, secure processing may be possible outside of the EU/EEA as discussed in Chapter 5 of the GDPR. Some countries such as Japan have been asserted an adequate level of data protection so that no special safety measures are necessary. For other countries, a transfer of personal data may be possible under so-called Standard Contractual Clauses which detail the responsibilities of the data exporter/importer. However, the recent Schrems II ruling has invalidated the (partial) adequacy decision for the United States, and has strongly hinted that SCCs only work if the parties are actually able to honor their responsibilities under the SCC (which is not the case with some surveillance laws). Data protection is likely not ensured for processing in the US or by US-controlled companies (even if the processing usually takes place within the EU). Given the sensitivity of health data, this means you should likely avoid using the typical public cloud providers (regardless of availability region). Depending on where your company is based, you might also be disqualified as a data processor by EU data controllers. So the GDPR has no data residency requirements that limit the processing/storage to Germany, but some data residency requirements to keep the data in the EU. However, there may be non-GDPR obligations that mandate how the data can be processed, but I'm not familiar with those (the German regulatory landscape for tele-health is very uneven, differs between German states, but is also improving a lot recently). Since you're processing health data, you should pay special attention to Art 9(3) GDPR which is expanded in German law by §22 BDSG to list a catalogue of possible safety measures you should consider, but none of them are related to data residency. §78 BDSG has further details on transfers into non-EU countries, such as emphasizing that human rights must be guaranteed in the target country.
The official EU-legislation does not use the word "cookies", except in the recitals. The "Cookie-Law" is part of the Privacy and Electronic Communications Directive 2002/58/EC and is amended by Directive 2009/136/EC, where the relevant text of Article 5(3) is found: Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service. This is a Directive, which is not directly binding, member states must implement it in their own law. But there will not be large differences to the text above. The guidance from the UK's ICO includes useful examples in particular about the exceptions to obtain consent. There is an exception to the requirement to provide information about cookies and obtain consent where the use of the cookie is: (a) for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or (b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user. The best example is a shopping cart: This exception is likely to apply, for example, to a cookie used to ensure that when a user of a site has chosen the goods they wish to buy and clicks the ‘add to basket’ or ‘proceed to checkout’ button, the site ‘remembers’ what they chose on a previous page. This cookie is strictly necessary to provide the service the user requests (taking the purchase they want to make to the checkout) and so the exception would apply and no consent would be required. And there is a negative example which is unlikely to fall within the exception: Cookies used to recognise a user when they return to a website so that the greeting they receive can be tailored In your question you explicitly state localStorage to keep a user logged in. LocalStorage is "storing of information in the terminal equipment of a subscriber". If you want to keep a user logged in, the user has performed a log in step. So you provide a service to keep the user logged in, which is exactly what the user wanted. So the exception would apply and you don't need to obtain consent. For example this stackexchange website also keeps me logged in, so the exception would apply here. However, you must make sure that you don't use the cookie/localStorage in a way which is incompatible with the exception. For example it would probably not be allowed to use the same cookie to count unique visitors to your website. If personal data is processed to store login data, Art. 6(1)(b) GDPR would probably apply; Processing shall be lawful only if and to the extent that at least one of the following applies: (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; So the GDPR would also not require you to ask for permission.
Algorithms can be patented, e.g., https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Patent (and see, e.g., https://en.wikipedia.org/wiki/Software_patent for further discussion). Copyright is only for specific code. So if your Company A has copyrighted the code you wrote, but not patented the algorithms implemented by that code, then you can subsequently go to Company B and legally reprogram those same algorithms.
Apparently, Yes In the ECJ's Breyer decision the final conclusion reads: Article 2(a) of Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. It is true that in this case the decision was actually under Directive 95/46/EC, not the GDPR, but the GDPR took its definition of personal Data directly from Directive 95/46/EC, so that should make no difference. It is also true that in this case the website in question was operated by the German Federal government, an not by a private individual, or by a private business. A government might have "legal means" to link an IP address with an individual that a private actor does not. However in point 23 of the decision, the Court refered to the IP addresses as: ... stored by the Federal Republic of Germany, acting in its capacity as an online media services provider, ... which seems to indicate that the same ruels were being applied to it as would have been to a private entity. Point 44 of the decision says that: The fact that the additional data necessary to identify the user of a website are held not by the online media services provider, but by that user’s internet service provider does not appear to be such as to exclude that dynamic IP addresses registered by the online media services provider constitute personal data within the meaning of Article 2(a) of Directive 95/46. In point 47, the court says that: ... in the event of cyber attacks legal channels exist so that the online media services provider is able to contact the competent authority, so that the latter can take the steps necessary to obtain that information from the internet service provider and to bring criminal proceedings. This leads the court to point 49, where it says that; Having regard to all the foregoing considerations, ... Article 2(a) of Directive 95/46 must be interpreted as meaning that a dynamic IP address registered by an online media services provider when a person accesses a website that the provider makes accessible to the public constitutes personal data within the meaning of that provision, in relation to that provider, where the latter has the legal means which enable it to identify the data subject with additional data which the internet service provider has about that person. Nothing in the decision indicates that any particular governmental authority was considered to provide the "legal means" to get an ISP to link an IP used at a particular time to an individual. In this page from Intersoft consulting it is said that: Since the definition includes “any information,” one must assume that the term “personal data” should be as broadly interpreted as possible. ... The same also applies to IP addresses. If the controller has the legal option to oblige the provider to hand over additional information which enable him to identify the user behind the IP address, this is also personal data. In this page from eugdprcompliant.com it is said that: A much discussed topic is the IP address. The GDPR states that IP addresses should be considered personal data as it enters the scope of ‘online identifiers’. Of course, in the case of a dynamic IP address – which is changed every time a person connects to a network – there has been some legitimate debate going on as to whether it can truly lead to the identification of a person or not. The conclusion is that the GDPR does consider it as such. The logic behind this decision is relatively simple. The internet service provider (ISP) has a record of the temporary dynamic IP address and knows to whom it has been assigned. A website provider has a record of the web pages accessed by a dynamic IP address (but no other data that would lead to the identification of the person). If the two pieces information would be combined, the website provider could find the identity of the person behind a certain dynamic IP address. However, the chances of this happening are small, as the ISP has to meet certain legal obligations before it can hand the data to a website provider. The conclusion is, all IP addresses should be treated as personal data, in order to be GDPR compliant. Finally the european Commission says, on this official page: Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data. ... Examples of personal data ... an Internet Protocol (IP) address; While the case law is scanty on the point, it appears that the consensus is that IP addresses, even dynamic IP addresses, will be considered to be Personal Data under the GDPR. >