Does a US company moving its PII and web servers to the EU solve the Meta fine problem? As discussed in this question about the Meta fine it is a problem for companies that host websites with access to EU user registration data in US datacenters. This is based on the 'Schrems II' decision in 2020 that the EU-U.S. Privacy Shield fails to protect Europeans' rights to data privacy when companies are transferring those data to the U.S. The details and requirements are discussed by the International Association of Privacy Professionals. Suppose Alice Inc. was in this situation, in that they are a US company with their websites running on the cloud in US datacenters, let us say in a single docker container with apache and MySQL and their simple site. They could with a simple purchase of alternative hosting and a few commands deploy their webserver on an EU host. This would however have little effect on the access to the data, in that if US law enforcement turned up at the offices of Alice Inc. they could be required to hand over the data and their access to the data will not be changed in any way by the location of the web hosting. If they did this, would this satisfy the particular aspect of the GDPR that was covered by the 'Schrems II' decision and the Meta fine?
Maybe this changes something, maybe not. But at first glance, yes, avoiding US-based vendors does help comply with Schrems II. They need not be EU-based. Definition of an international data transfer The GDPR unfortunately does not define what an international transfer is, and just explains when they may be lawful: Art 44: Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country […] shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor, including for onward transfers of personal data from the third country […] to another third country […]. […] This has been interpreted, in particular by the official EU SCCs and by EDPB guidance, to imply two roles: the data exporter, and the data importer. Per those EDPB guidelines, a transfer occurs when three criteria are fulfilled together: The data exporter is subject to GDPR (e.g. as a controller via Art 3, or as a processor via an Art 28 data processing contract). The exporter discloses or makes available personal data to the importer. The importer is in a &quot;third country&quot; (for EU GDPR: anything outside the EU/EEA). Note that these importer/exporter aspects are independent from roles like &quot;controller&quot; or &quot;processor&quot;. It also does not depend on where in the world the exporter is situated. Applying this to your scenario How does this apply to your scenario? I am assuming Alice Inc is subject to the GDPR (criterion #1). Now, Alice Inc can process personal data, and that's not an international transfer, even if Alice Inc is in the US (or any other third country). The general GDPR rules apply, such as the requirement to implement appropriate technical and organizational measures to ensure compliance and security of processing operations. If Alice Inc engages data processors to process personal data on Alice Inc's behalf, then this would fulfil criterion #2 (disclosure to a third party). For example, hosting providers generally act as data processors. Any other kind of data sharing (e.g. to other data processors) would also fall under this category. Tricky in an US context: while employees would be agents of Alice Inc and would not be separate recipients, contractors/freelancers would also be potential data importers. If those data importers are based in the EU/EEA, then criterion #3 is not fulfilled and there's no international transfer. For example, using an EU-based hosting providers would sidestep Chapter V of the GDPR completely. If those data importers are based outside of the EU/EEA, then criterion #3 is triggered and we have an international transfer. Lawfulness of international data transfers When there is an international transfer, it must be adequately protected. In order of decreasing priority: country has an EU adequacy decision appropriate safeguards for a group of companies: Binding Corporate Rules (BCRs) Standard Contractual Clauses (SCCs) Art 49 specific situations What SCCs and BCRs do is to translate enough of the GDPR from statutory law into a contract to ensure adequate protection. But to be effective, they must actually be enforceable, and the data importer must actually be able to comply with those rules. In Schrems II, the CJEU found that the US (at that time) did not offer an adequate level of data protection, and that SCCs are probably invalid as well since importers cannot comply with both the SCCs and with US surveillance laws. Before using SCCs, it is effectively necessary to perform a transfer impact assessment (TIA) analyzing, among other things, the legal context of the importer's country. It may be possible to defuse this, for example by using supplemental security measures like end-to-end that prevent unlawful use of the data even if it falls into the wrong hands. However, such measures also tend to prevent intended use, especially in a cloud context. In the DPC Ireland decision against Meta Ireland (PDF), the DPC finds: 7.202 In summary, therefore, I am satisfied (and I so find) that: (1) US law does not provide a level of protection that is essentially equivalent to that provided by EU law; (2) Neither the 2010 SCCs nor the 2021 SCCs can compensate for the inadequate protection provided by US law; and (3) Meta Ireland does not have in place any supplemental measures which would compensate for the inadequate protection provided by US law. 7.203 Accordingly, in making the Data Transfers, I find that, subject to the analysis contained at Section 8 below, Meta Ireland is infringing Article 46(1) GDPR. Implications of using non-US vendors As already mentioned, using EU-based data processors avoids the international transfer problem due to the way how international transfers are defined. Even if an international transfer occurs, that might not be a problem. Some countries have an EU adequacy decision, for example Canada, Israel, or South Korea. While there would nominally be an international data transfer that needs to be disclosed e.g. in a privacy notice, there is no additional bureaucracy required. In other countries, transfer tools like SCCs might work. A TIA might show that that the issues discussed in the Schrems II decision and the DPC decision wouldn't apply there. But isn't that a contradiction? You correctly point out a problem with the GDPR's approach to data transfers: This would however have little effect on the access to the data, in that if US law enforcement turned up at the offices of Alice Inc. they could be required to hand over the data and their access to the data will not be changed in any way by the location of the web hosting. Yes, this is arguably a loophole. However: If the US-based Alice Inc is a data processor in behalf of another controller, that controller would likely be violating the GDPR by transferring personal data to Alice. If Alice Inc is a data controller: while this might not be a violation of the Chapter V rules on international data transfers, such a scenario could be argued to be an Art 24 or Art 32 violation instead (requirement to ensure compliance and security). When Alice Inc transfers personal data to data importers, that is less visible to data subjects, and outside of their immediate control. However, when Alice Inc collects data on data subjects, that is more visible to data subjects, in particular through an Art 13 or Art 14 privacy notice. That notice must also contain the identity of the data controller, which would disclose that Alice is US-based, which may enable to data subjects to make more informed choices. This won't help Meta While moving to non-US data processors can be a sensible compliance approach for many companies, it is less useful for multinationals like Meta. In this context, Meta is an Irish data controller who engages platform and development services from an American company. Even if Meta Ireland tries to perform all GDPR-covered processing activities outside the US, it's actual corporate structure situates some processing activities such as administration tasks in the US and other third countries. If my above analysis is correct, it would have been easier for Meta to comply with GDPR if the US-based Meta company were the data controller.
The question says: But by hashing a IP address you process the personal information and that you can't do without the user's permission! But processing personal data (PI) is covered not by the e-Privacy Directive (ePD) but by the GDPR. Under the GDPR processing may be lawful if it is done under any of the six lawful bases specified by Article 6. Consent is one of these. But paragraph (f) permits processing when: 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 ... This is generally known as the &quot;legitimate interest&quot; basis for processing. It normally requires a balancing against the privacy interests of the data subject. Where, as here, the processing is specifically to remove any traceability of the subject, and hence to protect the privacy of the subject, there doesn't seem to be much conflict, so I suspect such processing would be lawful. I have not found, after a brief search, an actual case where this has been tested, so my conclusion might be mistaken. Personal Data under the GDPR and hashing GDPR Quotes Article 4 of the GDPR defines &quot;Personal data&quot; (in paragraph (1) as follows: 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 term &quot;pseudonymisation&quot; is defined in paragraph 5 of article 4 as follows: ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person; GDPR recital 26 reads: The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. 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 principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes. Hashing If a cryptographically secure hash function is used to convert an identifier, such as an IP address, into a replacement hash, there is no practical way from the hash value alone to recover the identifier. However, if a particular identifier value is compared with a stored hash value, it is easy to tell if there is a match. Finding a match does not prove that the identifier is the same -- depending on the length of the hash value being used and of the identifier, there may be many values that would give the same hash. But the chance of two random IDs having matching hashes is very small. Thus, if a controller were to store hashed versions of the IP addresses, no one could convert that back to a list of visiting IP addresses. But if soemoen had the IP address of a suspected visitor, and access to the hash function, it would be easy to check if that IP was on the list. If a keyed hash function were used, only someone with access to the key could perform this check. It is not feasible to hash all possible IP addresses as there are over 4 billion possible IPv4 addresses, and over 10^38 IPv6 addresses (over one thousand decillion). Thus creating a table to reverse the hashing in general is not feasible. Whether the possibility of checking for a match makes a hashed IP &quot;reasonably identifiable&quot; as representing a specific natural person under the GDPR and related laws has not, as far as I know, been authoritatively decided. Note that at most it would reveal that a person using a certain internet connection had (probably) visited a particular site.
GDPR rights and obligations cover different things: A duty of the data processor towards the government of the country where they operate to present certain documentation, and to implement technical and organizational measures to protect data. These would be audited by government agencies, not the individual customer. A single data subject cannot waive them. A duty of the data processor to process and store personal data only with a legal justification. User consent is one possible justification, if it is informed, revokable, etc. So a single data subject can waive a &quot;ban&quot; on storing his or her data in a database along with all the other users who waived that &quot;ban,&quot; but the duties towards the government regarding that data would still apply. A duty of the data processor to respond to an Article 15 request by the data subject in a certain way and timeframe. If a data subject writes a letter to the data processor and explicitly states that the letter is not an Article 15 request, then Article 15 does not apply. The data subject would of course have the right to make an Article 15 request at a later time.
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.
That GDPR Disclaimer is no protection in some jurisdictions: the applicable laws to that situation in germany for example don't care about the GDPR: Cold calling, mailing, or e-mailing private people to advertise services all is handled by the same law: Without the consent it is expressly illegal under §7 of the law against unfair competition (Gesetz gegen unlauteren Wettbewerb UWG) and such cases are rather Slam-Dunk if the origin can be made out. The punishment can be a 300.000 € fine. The fact that to email someone you need their e-mail address and that e-mail addresses and private addresses are by default considered personally identifiable information is making it worse for the advertizer: Without either an exception (there is none available to cold-emailing) or special allowance of the person the data belongs to, you violate §4 of the federal data protection law (Bundesdatenschutzgesetzes BDSG) just by handling their e-mail address. That's a separate crime from the UWG one, adding up to another 300.000 € fine under §43 BDSG - or even up to 2 years in prison under §44 BDSG! Oh, and if the email does not contain a proper sender's address, that's another chance for a huge fine under the UWG... So, GDPR is your least trouble, if you violate the marketing laws of a country, or their own data privacy laws. A disclaimer means nothing as the act of sending the mail, even to an unintended addressee, is what is illegal and the law as written does not give a damn about 'I didn't want to advertise to that person' when in fact you sent them unwanted advertisements. Oh, and the very repository you suggest? It would violate the very same §4 BDSG and be illegal for processing private data if it was not actively asked to do that by the end user. As a result, that database is useless: It does kick back all people not in its database. Its database is incomplete because only few people give their address to that database as people not aware of the database never add their data on their own. So it regularly violates §4 BDSG with every German citizen's e-mail address it gets and kicks back, and claiming those addresses would be OK, it throws the company trying to check the database under the bus because they rely on data that is impossible to be reliable. tl;dr Don't do cold-(e)-mail marketing. You throw yourself into boiling oil with a lit torch in hand. further reading Other laws banning such behavior I had listed here, and I quote myself: The US has the CAN-SPAM-Act, which illegalizes sending unsocialised advertisements. You may NOT send a mail if any of the following is true: it has no opt-out the email was gained by 'harvesting' contains a header not matching the text contains less than one sentence the adressee does not have any relation to you In fact, you are liable for a 5-digit fine per infringing e-mail in the US. The FTC itself suggests to never buy e-mail lists - as E-mail harvesting or generating any possible e-mail adress itself is illegal.
The site would combine the data in novel ways, which is processing the data. Processing personal data which is publicly available is still processing personal data. You would have to take GDPR into account. That does not mean the processing is forbidden, but you need a legal basis for doing it. In many ways, having the informed consent is the easiest legal basis, but there are others. The data subject would have the right to demand information about the data you hold, and to demand the correction of wrong data. There is not necessarily a right to demand deletion, but if consent is withdrawn and you have no other basis for data processing, you have to delete. Note also that the consent basis would mean you have to actively contact the people whose consent you seek before the processing starts, and document how you do it. That makes pay-per-request models difficult. But consider that the news media can process some data about some people without the consent of the subjects of their activities. They just need to balance privacy and other legitimate interests all the time.
That a company (C) has a website that can be accessed from a given county does not mean that the company operates in that country. If C is located in country A, markets and advertises to country A, offers products designed to appeal in country A, has its site only in the primary language of country A, uses servers located in country A, and has all its assets and physical offices in country A, it is not operating in country X, even if a few people from X do business with C over its web site. Country X may have laws which claim to apply to C or its web site. It will find it hard to enforce those laws, particularly if owners and officers of X do not travel to X. It will find it hard to extradite anyone for violations of the laws of X unless those actions are also crimes under the laws of A. If X is a major, powerful country such as the US, the UK, or the EU it may be able to get A to enforce its court orders, or to use its influence over the banking system to impose penalties on C. If X is North Korea, or even Brazil, it is probably out of luck. Thus the management of C needs worry primarily about the laws of A, and to a lesser extent the laws of major countries that make some effort to enforce their laws outside their own borders, such as the GDPR, or certain US laws. It probably has little reason to worry about the laws of other countries. If A is itself a major country that can easily resist any pressue from X, C has even less reason to worry. If C does significant business in countries D and E, and particularly if it opens physical offices in D or keeps assets in E, it will have much more reason to worry about the laws of D and E. If it does advertising in the D &amp; E markets, this also gives C more reason to be concerned with their laws. There is always some risk of X finding a way to enforce its laws, but the risk is small.
It is not different. But one company can decide to approach compliance differently from another. Here, TomTom has chosen a fairly safe/conservative interpretation, whereas Google and Apple decided that more data collection is appropriate. A “find my device” style functionality appears to be entirely unproblematic if the user books that particular service (regardless of whether the service is paid or gratis) and provides consent for the location data collection. The legal basis for such a service could then be Art 6(1)(a) consent or Art 6(1)(b) necessity for performance of a contract to which the data subject is party. Personally, I believe that Google is not sufficiently transparent about how Find My Device works, but that TomTom could provide a compliant service if they wanted to. That TomTom doesn't offer this service primarily shows that they don't think developing this service is worth it. Wiping a remote device is unrelated to this issue and doesn't seem to provide GDPR challenges. At least in a business context, remote wiping may be an appropriate security measure and may then even be mandated by the GDPR (e.g. see Art 24 or Art 32).