GDPR vs ICANN WHOIS Let’s start with some basic information: While a bit vague, for years you’ve been required to submit registrant, admin, and technical contact details. https://whois.icann.org/en/domain-name-registration-process Domain name registrants have certain responsibilities that are incorporated into these terms and conditions like payment of registration fees and submission and timely update of accurate data. In some cases, a person or organization who does not wish to have their information listed in WHOIS may contract with a proxy service provider to register domain names on their behalf. In this case, the service provider is the domain name registrant, not the end customer. Registrars are organizations accredited by ICANN and certified by the registries to sell domain names. They are bound by the Registrar Accreditation Agreement (RAA) with ICANN, and by their agreements with the registries. The RAA sets out responsibilities for the registrar including maintenance of WHOIS data, submission of data to registries, facilitating public WHOIS queries, ensuring domain name registrants details are escrowed, and complying with RAA conditions relating to the conclusion of the domain name registration period. Last Updated: July 2017 GDPR article 6 allows for processing of personal data on a contractual basis (section 1b) 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; Also section 1c processing is necessary for compliance with a legal obligation to which the controller is subject; And finally section 1e processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; So from the above information registrars are covered as they are under contract with ICANN to obtain and submit this information. The user is entering into a contract which requires information to be public. At any point in time the user can decide not to enter into the contract. Now technically speaking WHOIS data is not strictly required in order to facilitate domain registration. However you can argue the same for purchasing a house. It’s not technically required that your name be public record. But even in the EU your name is public record. https://www.eui.eu/Documents/DepartmentsCentres/Law/ResearchTeaching/ResearchThemes/EuropeanPrivateLaw/RealPropertyProject/GeneralReport.pdf Yet there is no exception for this within the GDPR. So the question is, how is ICANN under so much fire when EU’s own land registry violates the GDPR if we are to presume ICANN violates the GDPR. As my opinion sits I see multiple justifications within the GDPR that ICANN’s WHOIS can still operate legally.
For land ownership records and other similar scenarios such as business directors, the requirement for these to be public will be in legislation rather than a contract - this provides the legal basis, see GDPR Article 6(1c). Additionally when government departments are doing it they also have 6(1e) as lawful basis: "1. Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" -- GDPR, Article 6(1c,e). I'm not familiar enough with the specific legislation that will apply here but pretty sure this will be the case, and having said this you may well find public registries also become less public going forward. The reason ICANN has come under fire, is partly because under GDPR privacy is a protected fundamental right and therefore to comply personal data should be kept private by default and privacy never something you would be required to pay extra for. Any contract ICANN have in place with their registrars will not override legislation, it is in fact the other way around. "2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons." -- GDPR, Article 25(2). This doesn't stop ICANN from maintaining a register of domain name owners (registrants), but it does mean they can't just publish all records upon request to anyone anymore - whether people will be granted access to personal data will now depend on if they have a lawful basis for this, and in these cases their processing of the personal data will be limited to those purposes. Being nosey doesn't count! "When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of the contract." -- GDPR, Article 7 (4) - Conditions for consent. What this means essentially, is that if the consent is conditional for the contract it will not be treated as freely given, and therefore not valid - it will no longer be acceptable to contractually bind the provision of a product or service with consent to publish personal data or any other form of processing such as marketing mailing lists. Looking now at the specific points you have raised: "GDPR article 6 allows for processing of personal data on a contractual basis (section 1b)" Whilst this is true, this is only part of it - it doesn't allow for unlimited processing for any purpose and sharing it with any people, if you look at Article 5(b) it states that the information is collected for specific explicit legitimate purposes. Each purpose requires its own legal basis and needs to be compatible with the principles of GDPR. Without consent, ICANN currently does not have a legal basis to make the WHOIS records public for EU citizens and should have adopted some technical controls to require them to opt-in if they wish to be included in the public register. They're coming under fire for non-compliance having been given 2 years to prepare and change their systems/processes. "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;" Again whilst this is true, not all processing is necessary for the performance of a contract. In the same way people must give consent to receive marketing communications, they must freely give consent for their information to be shared/published (separate to the contract for provision of service) in the absence of other lawful basis for this processing. "Also section 1c, processing is necessary for compliance with a legal obligation to which the controller is subject;" There is no legislation which requires them to publish the personal data of domain name registrants. In this paragraph 'legal obligations' refers to those required by legislation (i.e. statutory obligations), not contracts (or non-statutory obligations) which are covered under Article 6(1b). "And finally section 1e, processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" ICANN has no official government-assigned authority, and publishing the personal data globally is not in the interests of the data subject's or others' welfare or well-being - this is what is meant by 'public interest'. As far as I can see what ICANN are actually doing to comply seems to be accepted by the European Data Protection Board, they are only 'under fire' as you say because they are late in doing so. The deadline was 25th May 2018 and they had 2 years to prepare like all other organisations.
“From your perspective you should not worry about asking permission to use reCaptcha as it is not you who is processing the data it is google and any GDPR compliance falls on them.“ This is plain wrong. If a user visits your website you are the controller of data collected on your website. Regardless of what entity collects that data. However in my non-legal opinion reCAPTCHA falls under Article 6 section 1d and 1f. Also Recital 49. 1d: “processing is necessary in order to protect the vital interests of the data subject or of another natural person;” While you could argue in some cases (most probably) reCAPTCHA is used to reduce spam to a business entity thus not a “natural person”. 1f: “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 which require protection of personal data, in particular where the data subject is a child.” Here is where the real ruling applies “Legitimate interests”. You as a business have a legitimate interest in reducing spam into your business. Not only does spam take up your time but it also takes up your resources. As to the extent in which spam takes up is dependent on the usage in question. But nearly everyone can safely assume reducing spam (one of the cornerstones of the GDPR) is a legitimate interest. Recital 49 (excerpt): The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, […] by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems.
Names clearly are personal data and so a good question to ask for GDPR compliance is: Do you need to do what you want to do in order to offer your product or service? For your scenario a common answer seems to be that websites ask for the users first and last name during account creation. The reason is that they need this information to confirm the identity of the account creator. But the public profile only displays a user name that the user can pick freely. In general there is no good reason to publically show the legal names of users so websites don't do it. So for your website ask yourself, why do you want to publically show the names of your users? If you have a good reason to do that specify it in the user terms and go ahead. If you don't have a good reason don't do it.
Consent for processing someone's personal data is only one of the possible requirements to process that person's personal data. The options listed in Art. 6.1 are (text in Spanish, with links to other languages): a. the data subject has given consent to the processing of his or her personal data for one or more specific purposes; 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; c. processing is necessary for compliance with a legal obligation to which the controller is subject; d. processing is necessary in order to protect the vital interests of the data subject or of another natural person; e. processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; f. 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 which require protection of personal data, in particular where the data subject is a child. Obviously, your case meets the criteria for c.1 So, you do not need consent from your hosts, and your hosts do not have to sign any consent and they cannot refuse to provide their data if they want to reside at your dwelling. The moment you ask your hosts any data to which you do not have a legitimate interest, you need the consent. And you cannot refuse hospitality to your hosts if they do not want to provide that piece of data. Anyway, maybe it would be a good idea to print a leaflet explaining why you require their data in case they have any doubts. 1 For the Guardia Civil, it would be c. and maybe a few more cases.
There are a few different grounds under which PII can be handled. Perhaps the most discussed at the moment of GDRP introduction is consent, because of the wave of consent-seeking. But there are a number of other grounds. "Necessary for contract execution" is a trivial one, to deliver a pizza you'll need an address. The relevant ground for sanctions lists is also pretty obvious in hindsight, you may process PII in order to comply with legal obligations. Note that this is still an integral part of the GDPR, not an exception to the GDPR. That means you need to apply all the basic GDPR rules. You need to explicitly store where you got the PII from, for which purpose, and you need to document how you're using it. Note that this might be hard - why do you need to store this data? Why can't you just check the list as the moment it's relevant? The GDPR for a large part depends on you justifying your actions, not just in hindsight but already up front.
StackExchange is a processor under GDPR because it processes the data you provide it when you sign up and input personal information. It's determined by an analysis of what function(s) the business is performing. If you are merely processing the data but don't have control over it (e.g. another business is using your software to do something with data that it is providing you) then you are likely to be a data processor. Conversely, if you control the data, you are likely to be a data controller. It is possible to be both a data controller and a data processor at the same time. That specific link in your post goes on to state: Our business customers may qualify as controllers when they purchase certain of our products and services. We act as processors on behalf of such Customers. This is referring to the Teams product that StackExchange offers or whatever the &quot;internal company-only question and answer site&quot; product they offer is called.
As I understand it, the GDPR does not permit sending of personal information (which includes the IP address) without prior consent by the user. That's not exactly true, consent is merely one of six possible legal basis for processing (article 6). For example, processing of personal data can also be lawful if it necessary to perform a contract, legally mandatory, or in the public interest. The court decision acknowledges that but rules out another basis in this case because it considers that it is possible to serve fonts without relying on a third-party ([…] der Einsatz der Schriftarten auch möglich ist, ohne dass eine Verbindung von Besuchern zu externen Servern hergestellt werden muss). Confusingly, it only refers to article 6(1)(f) when it seems to me that (b) would also be plausible but maybe this wasn't raised during the proceedings? If the data controller cannot invoke any other basis for the lawfulness of the processing then yes, the only thing left is asking for consent, i.e. invoking article 6(1)(a). But that doesn't mean that you should expect to be asked for consent each and every time your personal information is being used. The consent form on the site also implicitly assumes consent, which I thought was also a violation. Yes, implying consent doesn't really make sense under the GDPR definition (article 4, see also article 7): ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action European data protection authorities have issued guidelines that detail what that means and clearly reject “bundling” different data processing. The regulation also makes it clear that data subjects should be able to withdraw consent at any time, which does not seem possible with the fonts on golem.de My reading of all this is that assuming consent because you are using a service (or even created an account or checked a box at some point) simply isn't valid consent. Either you don't need consent at all in the first place or what you need is freely given, specific consent and “implying” consent or bundling it with a registration process achieves exactly nothing. But this is still extremely common and it might take some time before enforcement and case law definitively settle this question. Smart data controllers trying to avoid collecting consent (like Meta) have abandoned any claim that signing up to the their services would constitute consent (because that's transparently not the case) and try to bypass the issue entirely using another basis like contractual necessity. This is also being litigated. I know that a EU regulation can be implemented and interpreted differently from country to country, and that a single court ruling in Germany doesn't even mean that the national law was correctly applied. From what I've read, I get the impression that this particular ruling was not unlikely to be overturned by a higher instance, if it came down to it. So my question probably both pertains to German law specifically and the EU regulation itself. That sounds more like the way EU directives work. Regulations are supposed to be immediately applicable (no implementation in national law necessary) with minimal differences between countries (except when they explicitely provide for that). Of course, enforcement would still mostly be in the hands of national court systems and (in Germany) provincial data protection authorities but there are mechanisms to ensure consistency (the European Data Protection Board, prejudicial questions to the CJEU, infringement proceedings from the European Commission…).
I'm pretty sure that under GDPR, you can indeed request them to send all data they have on you. If it's a complex request, they may charge you something like £10. If they have a lot of data on you, they may list the categories of data they have and ask you to pick one, rather than them having to collect and send everything. They should respond within one month, but iirc in the UK implementation, they can inform you (within that month) that they will respond within three months instead. For the rest, I only know current Dutch law. GDPR is not that different from what we already had (in general terms) and in many cases it even extends it. Under our law (WBP), you can also request a correction of the data in case it is incorrect, or deletion if they no longer need it for the purpose for which it was collected and stored. I don't really know how that works out in practice though, as Facebook can of course claim that "being able to connect you to your friends when you sign up for WhatsApp or Facebook with that number" is a legitimate purpose (in their eyes). They might also not have your full name and therefore not be able to connect your data to your request. Or, perhaps, they have only your full name (and there are probably more people with your name), so they'll have a hard time verifying that it's really your data which they would be handing over or deleting. The company is required to verify your identity before acting on your request. How they implement that is up to them. Under Dutch law, if I remember correctly, any data that can be connected to your person by any party is personally identifiable information (PII). While Facebook might not be able to find who's behind a phone number, your carrier most certainly can. Therefore, the data falls under PII protection laws and they will have to implement a way to verify you and get you your data. Finally, whether your local laws apply to Facebook, I don't know exactly. There's lots of information on this though, so you should be able to find it. Generally, countries say that if something happened within their territory (e.g. you signed up for WhatsApp while in the UK), their law applies. Companies, I've read, will instead try to claim that their main office is in SomeCountry and therefore SomeCountry's laws apply. But I'm pretty sure you'll be able to find a Facebook office somewhere where GDPR applies, so that's probably fine. While not an exact answer and while I am not sure about everything, I hope this gave you some pointers to go on!