Does GDPR cover the collection of data by websites that crawl the web and resell user data I have found that a lot of my personal info is now available on a bunch of websites that collect data and resell it. I'm talking about those 'find anything about anyone' websites. A lot of the data is also inaccurate. Since a lot of these companies are American and I have lived my life half US / half EU and I'm now an EU resident, I was wondering: does the GDPR applies to them? does the GDPR applies to data they claim was 'public', but I see that this is not really true? What's the responsibility of search engines, like Google, in indexing and promoting that content. As they seem to have a 'contact the webmaster' approach to it, is it possible to get the content (at the minimum the inacurate one) removed from their index?
The GDPR applies to such sites if they offer services in the EU/EEA. If they clearly wanted to avoid being subject to the GDPR, they should block visitors from the EEA. For the GDPR, only location matters. Other concerns like residence or citizenship are generally irrelevant. Personal data does not turn non-personal just because it was public. So the GDPR still applies when the data was collected from public sources. However, the data controller (who determines the purpose of processing) often has to balance your rights and interests against other interests (e.g. when using legitimate interest as a legal basis for some processing). For the purpose of publicly displaying your data, only showing data that was already public anyway makes it easier to argue that this is fine. But when the GDPR applies, you have data subject rights. Relevant rights include: a right to access, to see all the data they have about you a right to rectification, to correct wrong data they hold about you a right to restriction, effectively an opt-out a right to erasure (also known as the right to be forgotten) These rights apply both against the website and against Google Search (arguably, both are doing the exact same thing). Google correctly points out that they can't remove information from the Web, but they can hide information from search results. If you feel that your requests have not been resolved correctly, you can issue a complaint with your country's data protection authority. In theory you can also sue them. In practice, GDPR enforcement against overseas data controllers can be quite difficult and has not yet happened.
A data subject access request can be valid even if it wouldn't disclose new information. The right to access ties in with the GDPR's transparency principle (finding out which data is being processed) and with the right to rectification (are there any mistakes in the data being processed?). For rectification, it's pretty much ideal if you get back exactly the data you expect – but you're allowed to check with an access request. The Art 12(5) limitations on excessive or manifestly unfounded requests do put a limit on the right to access, but this limit helps controllers respond to legitimate requests. For example, if a request is clearly intended to harass the controller with busywork, it can be denied as unfounded. Similarly, requesting access to the same data very frequently would be excessive. However, the controller has burden of proof to show that the request is excessive or unfounded – basically impossible for a one-time request for specific data. A request is not automatically excessive just because it is likely to only return data you already know. But ultimately, detailed guidance on the interpretation of “excessive” is up to the supervisory authorities – the GDPR itself provides no guidance. Aside from the above exception, access can only be denied if it would adversely affect the rights and freedoms of others. For example, you could be denied access to non-anonymous performance reviews. There would be no such adverse effect for basic information about your employment. If a data controller improperly considers your request as excessive or unfounded, you can lodge a complaint with your supervisory authority, e.g. the ICO in the UK. Most controllers are suddenly extremely helpful once contacted about an official complaint.
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.
The critical part is the nature of the relationship between you, the website provider, and the provider of the material you embed. If the embed-provider acts as your data processor, then things are generally fine. The GDPR does not really distinguish between personal data processing activities that you perform yourself versus activities that you've outsourced to third parties. However, you would remain responsible for compliance. This also means that per Art 28 GDPR, you will need a contract with that embed-provider (sometimes called a “Data Processing Agreement”, DPA). This contract stipulates that the processor will only use the personal data as instructed by you, but not for their own purposes. With the Google Fonts case, it must be highlighted that Google does not act as a processor for this service. Google does not offer a DPA that covers the Fonts CDN. While Google promises that it doesn't use the personal data collected in this context in any nefarious way, there are zero contractual guarantees for website providers. So we have to consider the scenario when the embed-provider is an independent data controller. We as the website provider have no control over what the embed-provider does with the collected data, our control only extends to whether or not we cause the website to disclose data to that third party. But this is still processing as personal data (see also the CJEU Fashion ID case), and we need a legal basis for this data sharing. In the Google Fonts case, the court in Munich found that there was no legal basis for using Google's CDN. There was no consent, no contractual necessity, and no necessity for a legitimate interest. After all, these fonts could all be self-hosted. (Technical remark: and given how modern browsers enforce cache isolation and provide HTTP/2, serving fonts from your main domain is probably faster anyway). Consent management services will typically act as your data processor. You don't need a legal basis for “sharing” data with them, because the processing remains under your control. As far as the GDPR is concerned, loading a script from your processor's servers is equivalent to loading a script from your own servers (which you're probably hosting via a another data processor anyway). Sometimes, the necessary data processing agreement is already part of the standard terms of service, sometimes it's a separate document that has to be signed. Figuring this out is your responsibility as the data controller, before deploying the service. Art 6 GDPR doesn't say that you always need consent. It says that you need a legal basis, for which paragraph 1 enumerates six choices. For a lot of use cases, a “legitimate interest” will be appropriate, though it requires a balancing test. Sometimes, other laws mandate that you use a particular legal basis. For example, the ePrivacy Directive says that you must get GDPR-consent when accessing or storing information on the user's device (such as cookies), unless that access/storage is strictly necessary to provide a service explicitly requested by the user.
You are correct that facts in general are not protected by copyright, and most raw data are facts. However, a collection of data may be protected by copyright as to its selection and organization. A use which copies such selection might possibly be copyright infringement. If data constitutes a trade secret it may be protected as such, and &quot;improper&quot; access might be unlawful. This would not apply to publicly available data or collections of data. If, to access a data set, one must sign or agree to a contract, that contract may limit the use of such data. Again, this would not apply to most publicly available data.
As always, it depends. However, it is by no means certain that any public facing hobby project, such as a web app, is exempt from having to comply with the GDPR. Since the GDPR is only a few days old, we have of course no case law based upon the GDPR itself yet. However, when considering this, one should take the following two facts into consideration. 1. The "personal use exeption" in the GDPR is not new. The personal use exemption is unchanged from the article 3(2) of Directive 95/46/EC. (There as a lot of lobbying for removing "purely" from the sentence – but drafters wanted to keep it.) 2. Case-law under the previous regulation restricts the scope of the exception The ECJ has ruled on the scope of the personal use exception in two cases: C-101/01 C-212/13 In both these cases, the ECJ took an extremely restrictive view, and concluded that the personal use exemption did not apply to the processing done by these individuals. In C-101/01 it can be argued that the hobby project as a blogger was connected to the controllers professional activity (she was a catechist in a local church, and blogged about her work. including her colleagues). But in C-212/13, there no such connection to professional or commercial activity. Here, the controller operated a CCTV to protect his home, but set it up to also capture public space, and that was enough for the ECJ to decide that the personal use exception did not apply. Discussion Case-law based upon Directive 95/46/EC is in no way binding for a future court that need to rule based upon the GDPR. We need to wait for case-law decided under the GDPR to be able to have some degree of certainty about the scope of the "private use exception" under GDPR. However, given what we know about how the ECJ has ruled in these cases in the past, I think it is hazardous to think that just because what you are doing on the web is just a "hobby project" not connected to professional or commercial activity, you are exempt from complying with the GDPR. Conclusion IMHO, you may be exempt, or you may not be exempt. I think it really depends on your activity in your hobby project, and to what extent this project processes the personal data of other people than yourself.
Article 32 of the GDPR requires companies to adequately secure their data when handling data belonging to EU citizens. This also applies to cross border scenarios where data is transferred between countries. Technically speaking, the GDPR doesn't set a standard for security: you don't have to encrypt your data, use AES or RSA encryption, or hash and salt passwords. It is your choice on how to secure your data, though the GDPR does mandate specific ways to secure data. However, not doing so opens yourself up to two consequences: The European data protection supervisor is tasked with the enforcement of regulations. A company can be forced to increase their level security if a valid complaint alleging that inadequate security measures are in place is made There is a significant amount of security risk, and if a data breach occurs, the GDPR allows authorities to levy heavy fines. Especially heavy fines may occur if it is found that the data was not securely stored. So the answer is: A complaint to relevant authorities can force the company to take action, or they will lose access to the European market.
I spent a few years working in and around the Energy industry - including a stint working at a supplier, I'm no longer there so unfortunately I no longer have access to the email chains I had discussing this with legal. The consensus at the time was that a "traditional" i.e. non-half-hourly (NHH), non-smart meter reading itself was not considered personal data - they are conceptually tied to a metering point (which may or may not be a physical meter), not to an individual and don't represent an individual's energy consumption (the granularity of the reading is insufficient to tell anything about the usage profile) But this information, while all around the implementation of GDPR it was a couple of years back and to be honest it was bugging me that I might be out-of-date on the current practices so I reached out to a former colleague who was the Data Protection Officer at the supplier I worked at to try and get a more up-to-date take. He's since moved on but was there until recently so has more experience with the topic since GDPR actually went into effect. I asked him whether a) estimated opening reads were considered "personal data" and b) what would happen with a request to change one under article 16 and he had this to say, I've translated industry-speak in square brackets: a) for NHH ["Non Half Hourly" - meters that are read ad-hoc, essentially all non-smart domestic meters will be this] an estimated reading wasn't personal data automatically until the billing flag was set in CRM and those would be the only ones we'd include on an SAR [Subject Access Request], any others are internal data not personal. HH ["Half Hourly" - meters for higher consumption users, typically larger business premises are billed on increments for each half hour so have readings for each] and remote [smart meter] readings are always personal for domestic and microb [micro-businesses are a certain class of non-domestic energy customer see condition 7A] b) erm no! we'd only change it if the value in CRM didn't match the value in the D10 [industry Data Flow used to transmit meter reads] for some reason. if they match it's an accurate representation of what we estimate the reading to be so it's just a vanilla billing dispute not a data protection issue so i'd have punted it to [name of person who was head of metering] From that it would sound as though the estimated read would count as personal data - so long as it's being used for billing purposes, but that doesn't mean they have to accept your read in it's stead. It all comes down to accuracy - GDPR requires that personal data be "accurate" but provides no definition as to what "accurate" means (which makes sense since you can't give a one-size-fits-all answer that isn't an encyclopedia) and while The Electricity Directive 2019 confirms the need for accuracy in billing again it doesn't tell us what that means. The implementation is left to member state regulators. In the UK this is OFGEM and all opening meter readings are validated through third parties (so you don't end up with the foxes guarding the hen house!) and are calculated using the following formula: Last validated reading for the meter point &lt;= supplied reading &lt;= (expected daily usage x number of days since last validated reading x 2.5) where "expected daily usage" is obtained from a database maintained by the regulator - it's calculated off meter type, property type, property use, previous validated reads etc. So if the customer provides a reading that falls outside the above the supplier can (and in practice invariably will) reject it as being inaccurate. Now this is why the when a meter reading is provided matters - reads you provide are always assumed to be the read on the day you give them. With opening reads there's some leeway, I can't remember the official rule on how much but usually they give you up to the next estimated read is generated but more on that later. Now if the reading you're trying to submit is a "now" reading and it's failed the validation criteria and you aren't happy with the rejection you can force the issue by demanding the supplier come read the meter. You don't say how long has passed since the opening read - more than the week from what you've said so presumably at least a month (guessing you've had at least your first bill). Now if they are saying the opening read was X (based on the estimated usage) and you're it should have been X + Y and the current reading is X + Y + Z you want to pay your actual usage Z not Y + Z. What you need to do is dispute the opening read, which you're entitled to do, arguably GDPR of Article 16 gives you this right, but on it's own it's a weak argument. There's established means by which an estimated read's "accuracy" is determined and assuming they followed that they're going to just tell you that as far as they are concerned it is accurate. Any challenge to that accuracy is going to have to be done within the legal/regulatory frameworks for assessing accuracy, that's what they're there for, if they won't accept your reading escalate that to the regulator - and as soon as you can. OFGEM for example allow disputing of opening reads for 12 months - it doesn't have to be resolved within that 12 months it just has to be lodged with them within that time. If you try and use the GDPR angle to pursue this IMHO it's going to muddy the waters and not help you get what you need - pursue this on billing accuracy.