Trans-Atlantic Data Privacy Framework - defined national security objectives According to this release from the White House they state: the United States is to put in place new safeguards to ensure that signals surveillance activities are necessary and proportionate in the pursuit of defined national security objectives What does that mean? Isn't that a cart blanche to track anything and anyone on the whim of what anyone sees as a “threat”? You criticize something? OK, potential threat. You ask a question: OK, potential threat. You post this question: OK, sketchy person. etc. I'm not trying to be hyperbolic but history has shown quite often that “national security objectives” has a rather wide interpretation; not the least when it comes to non-US citizens. Anyone know what safeguards and legal standing EU citizens has in this deal? Is there any article / reports or the like that judge what the deal entails, i.e. from a critical viewpoint?
The statement says that The new Framework marks an unprecedented commitment on the U.S. side to implement reforms that will strengthen the privacy and civil liberties protections applicable to U.S. signals intelligence activities. That at least claims to be a restriction on surveillance, not an increase in authorization for surveillance. The statement also says that the US will: establish a two-level independent redress mechanism with binding authority to direct remedial measures, and enhance rigorous and layered oversight of signals intelligence activities to ensure compliance with limitations on surveillance activities. That seem to be rather different from allowing surveillance on a &quot;whim&quot;. Until the details of this new &quot;framework&quot; are published one cannot judge how effective these measures are likely to be, they might be mere lip service. But let us look at the reason behind them. Since the Schrems II decision, EU entities have, in many cases, been restricted from sharing data with US entities, or storing data on US-located servers, because of a concern that current US law did not sufficiently protect the privacy of EU residents. These restrictions have been a problem for many US businesses. It seems that this new framework is aimed at giving enough privacy protection to lower these restrictions. It will be up to the EC and the European Courts to judge if the framework achieves that goal. If they decide that it does not, they can decline to lower, or reimpose, the data transfer restrictions, which would make the framework pointless for the US. It is in the US's interest to keep the EU authorities satisfied on this point. In the article &quot;United States and European Commission Announce Trans-Atlantic Data Privacy Framework: Setting the Scene for Schrems III?&quot; from the National Law Review it is states that: The success or failure of the new agreement will depend on the extent to which it overcomes the flaws identified by the ECJ in Schrems II. The ECJ ruled against the EU Commission’s adequacy decision in favour of Privacy Shield, finding that data subjects were inadequately protected against electronic surveillance or “signals intelligence” activities carried out under US Federal authority, and that data subjects impacted by such activities had no viable route to redress. ... It is important to remember that Schrems II did not strike down Privacy Shield, which has continued to operate since July 2020. Rather, the European Court of Justice ruling struck down the EU Commission’s adequacy decision in favour of Privacy Shield. Consequently, a key objective of the new Trans-Atlantic Data Privacy Framework is not to replace Privacy Shield, but to revive and enhance it with new mechanisms to address the flaws identified in Schrems II. Participating companies and organizations that take advantage of the Framework to legally protect data flows will continue to be required to adhere to the Privacy Shield Principles, including the requirement to self-certify their adherence to the Principles through the U.S. Department of Commerce. The language of the White House fact sheet suggests some areas likely to attract close scrutiny once the full details are available: What degree of impact on individual data subjects will be considered acceptable, and in what circumstances? The US government is not promising to refrain from the use of signals intelligence and electronic surveillance. It is promising only that intelligence activity will be limited to “legitimate national security interests” and that the impact on individuals will not be “disproportionate”. How far the composition of the proposed Data Protection Review Court will ensure that it is truly independent of the Federal government? According to this NY Times story: The deal includes a way for Europeans to object if they feel that their privacy has been violated, including through an “independent Data Protection Review Court,” the White House said in a fact sheet released after the news conference. The deal still needs to be made final, the United States and the European Commission said in a joint statement, adding that the White House would put its commitments in an executive order. Businesses that send European Union data to American servers have pushed hard for the governments to reach a new deal. Since the last pact was struck down more than 18 months ago, regulators in European countries have said companies cannot use certain web services, like Google Analytics and Mailchimp, because doing so could violate the privacy rights of Europeans. Meta, the parent company of Facebook, said this year that it might shut down its services in Europe if the governments didn’t resolve their differences. Google’s top lawyer had urged “quick action to restore a practical framework that both protects privacy and promotes prosperity.” The Friday announcement is the latest development in a lengthy debate about how far governments and tech companies should go to protect users’ privacy. Europe’s top court twice struck down pacts governing data flows between the United States and the European Union over concerns that the data would be exposed to American surveillance programs. All of this is based on the joint announcement by the US and the EC, with detailed documents apparently yet to come.
Your code is considered free speech (Bernstein v. United States) and you have allowed the use of the code via the MIT license. Since the application of your code is very generic and is not specifically targeting anyone. You probably are not criminally liable. This is simply writing a "Proof of Concept" for security testing purposes. That same way Metasploit, Nessus, and Nmap have actual exploit code but are considered tools of the trade. Now if you go around using your spyware on non consenting victims. You might get a visit from some people with guns and badges that have 3 letters on them.
You premise is correct. The processor is someone that processes data on your behalf, and since the GDPR definition of processing is extremely broad, that is about every third party subcontractor that you use for data processing, including various cloud providers. I'm afraid it will soon become a huge mess with a gazillion contracts to sign. I disagree. Yes, the GDPR says that a contract between the controller and processor must exist, but Article 28 of the GDPR does not say anything about how the controller shall document these instructions. Basically, in cases like the one you describe where John Doe relies on a web agency for having a contact form on the web, there will be a standardized (by the web agency) service agreement between the John Doe (controller) and the web agency (processor). There is nothing stopping the parties from agreeing that this service agreement that John Doe accepted as part of the onboarding procedure is also the DPA as required by the GDPR. Putting something like the following in the service agreement would do it: The parties agree that this Service Agreement between You (controller) and Us (processor) set out Your complete and final instructions to Us in relation to the processing of Personal Data and that processing outside the scope of these instructions (if any) shall require prior written agreement between You and Us. You also agree that We may engage Sub-processors to process Personal Data on Your behalf. The Sub-processors currently engaged by Us and authorized by You are listed in Annex A. I think we will se a lot of amendments in service contracts as the GDPR gets better understood, but I don't really see a flood of DPAs in addition to these amended service contracts.
There are professionals who are doing penetration testing in an attempt to find security vulnerabilities with the target company. They will have a clear, written contract with the target company to permit the attack. Professional conduct means making sure that the permission is genuine before starting the attack. Their aim is to map weak points in the security, not to extract personal data. There will be non-disclosure agreements to make sure. Reports go to the target of the attack, not to any third party. As you describe it, it looks as if scammers are setting you up as the fall guy for their schemes. They and the money will be gone, you go to prison.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
The GDPR has a fairly broad concept of what it means for a data subject to be identifiable. The details are given in Recital 26: To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The good news is that this mandates a risk-based approach to identifiability. You don't have to prevent re-identification with absolute certainty, but you must make sure that re-identification is not “reasonably likely”. The bad news is that “identify” does not just mean “figuring out the real-world identity of the data subject”, but also “being able to single out the data subject”. Hashes of personal data are still personal data. The hashed password still allows you to single out data subject, since the hash now serves as an identifier that links multiple records. Equivalently, a random ID would serve as an identifier. Depending on the information in the linked records, this could reasonably likely also allow linking to a real-world identity. I'll also point out that the GDPR explicitly notes that “online identifiers … such as internet protocol addresses, cookie identifiers or other identifiers” enable profiling and identification, and are thus a kind of personal data. Note that it seems you have a user database that includes a password hash. This database includes rich links between the password hash and other, more directly identifying, data. Alternatively, consider that the software that collects tracking information along with this tracking identifier would also receive other information about the data subject that could allow re-identification, such as the data subject's current IP address. It would be reasonably likely that such additional information could be used to identify or single out the data subject. For this analysis, it is irrelevant whether you have any intention of singling out users – it only matters whether, under an objective analysis, the relevant means to do so exist. Related: EDPB thinks hashed phone numbers are personal data. There has been recent debate by regulatory bodies on the question whether hashed phone numbers are personal data. This debate was published by the EDPB binding decision regarding the Irish DPC's fine against WhatsApp, which uses hashed telephone numbers to intersect user's address books. The question in the context of the fine was whether this represents processing of personal data of users who are not WhatsApp users themselves. Originally, the Irish DPC argued that such hashes were not personal data. However, the German, French, Portuguese, and Dutch supervisory authorities pointed out that the specific hashing approach used by WhatsApp does not provide anonymization, for example because there still is contextual information (such as the user's social graph) that would allow indirect identification (and because their hashing was pretty weak and reversible with reasonable effort). Such hashing would only be pseudonymization, not anonymization. The Hungarian supervisory authority makes the argument that WhatsApp could always re-create the hash from the original data, thus permitting re-identification of the hash. This is in line with my above argument that the hash allows singling out. Again, the hash should be considered pseudonymous, not anonymous. The EDPB upheld all these objections against the Irish interpretation as “relevant and reasoned”, and largely agreed with their merits. Some parts of the resulting analysis are specific to issues around phone numbers, in particular that there are comparatively few phone numbers. However, a recurring point is that the hashed data cannot be viewed in isolation. It must be viewed in the context of how it is created and used, and in the context of other data that the data controller has. Conclusion It is possible that in some cases the hash could serve as an anonymous token. But this would require careful analysis about how the hash is created and used, and about what other data you have available and could potentially link or correlate with this token. Unless you are extremely sure that there are no means that could be reasonably likely used to perform re-identification or singling out, you should consider such tokens to be pseudonymous data. Pseudonymization is a great security measure, but such data is still personal data. I suggest reading the WP29 opinion 05/2014 on Anonymization Techniques (WP216) (PDF link). It predates the GDPR and is slightly outdated in both legal and technical matters, but still contains highly relevant guidance on the matter of proper anonymization in the European data protection context. Aside from identifiability issues, I am concerned about using the password (or derived hashes) for anything other than authentication. Even in hashed form, this is fairly sensitive data. In most cases where you would use a password hash, you can likely use a random number instead.
I think that one cannot answer a question such as "Will the personal use exception in the GDPR apply to personal blogs?", because it is unclear if you refer to: personal information published on the blog pages personal information collected from the Website, by way of forms, cookies, server logs, strictly collected and processed for the purpose of operating the Website for your own personal purposes as a blogger (by yourself of through a subcontractor in the sense of GDPR) and not personal information collected from the Website's operation, transferred or provided to third parties for their own purposes (this would include cookies used to identify and track users across multiple domains) Regarding 1., a personal blog wanting to benefit from the exemption should not publish third party's personal information without their consent or another legal basis, and C-101/01 certainly applies here. About 2., if the information is strictly collected and used for the own personal purpose of the operation of the blog, I would tend to agree that it should benefit from the exemption. I feel that C-212/13 would not necessarily be an indication that because the blog is publicly accessible it is then "directed outwards from the private setting" in the sense of this ruling, and should not be considered as "purely ‘personal or household’ activity". C-212/13 case was relating to a camera installed by an individual on his family home for its own security purposes which was also monitoring a public space. The persons filmed on this public space had absolutely no direct connexion with the person collecting their images. In case of a blog, the visitors of the blog interact with the blog for fulfilling the own personal purpose of the operation of the blog of the publisher of the blog. Another argument is given by the Recital 18 which you quote: a personal blog can be viewed as a type of social networking or related online activity. Finally, about 3., there is no doubt for me that, in this case, the publisher of the blog is engaged in an activity which is not personal, since it willingly provides personal information to third parties which they use for their own purposes (and not as subcontractors in the sense of GDPR). There may be other approaches apart from these 3, but that's a start for your considerations.
I think haveibeenpwned would be legal in the EU because it carries out a task in the public interest (Art. 6(1)(e)), and it shares no more data then necessary, for example you can search for a password, but it would not show you the emailaddress which belongs to that password. It would also be legal for you to hold a copy of a leaked database, but only if you have a legitimate interest (Art. 6(1)(f)) to have it. Being a security company does not change that, but finding a legitimate interest might be easier. If you have a legitimate interest to hold a copy of a leaked database, it does not mean you can use it in any way you like. For example testing if the password still works, is very likely illegal everywhere in the EU. But I'm not familiar with the UK laws.