Why does Clearview AI get multimillion dollar fines while Pimeyes is allowed to operate freely? Yesterday the UK has fined Clearview AI 7.5 million pounds for a string of breaches of local privacy laws. The main reason for the fine is that Clearview has never asked individuals whether it can use their selfies in an AI-based identity-matching service which it sells to entities such as law enforcement. In the past the company has also been fined by privacy watchdogs from italy, France and Australia. Meanwhile a polish facial recognition company called pimeyes is doing exactly the same thing as Clearview AI, it scrapes images from the web for use in an identity-matching service. The difference between this company and Clearview AI is that pimeyes does not scrape images from social media websites. Furthermore the service that Clearview AI offers is only available to law enforcement agencies whereas the service pimeyes offers can be used by anyone (provided they pay). Other then that there are no real differences between the two companies. So why is it then that Clearview AI receives multimillion dollar fines from multiple countries whereas pimeyes was only investigated once by a german data watchdog? Like clearview AI, pimeyes.com does not ask permission before scraping publicly available images either. So why isn't the company pimeyes receiving multimillion dollar fines as well?
Why is it that police only stop some speeding motorists? There are always more crooks than cops and therefore there will always be some who get away. Given that the regulators do not have the resources to do everything they could do and not even everything they want to do, they have to choose who to target and who to ignore. Factors that influence that decision is how resource intensive the investigation will be, the likelihood of obtaining a conviction, and the prospects of collecting any resulting fine. Clearview AI is a US based company and US courts will generally enforce UK court orders. Primeyes is based in Belize which is less cooperative with foreign law enforcement - largely so companies like primeyes will base themselves there. That said, perhaps EU authorities just haven’t got to them yet.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/
Since you are from Europe, GDPR applies to all your processing activities per Art 3(1) GDPR, regardless of where the users are located. If you would like to avoid GDPR compliance, you would have to manage your business from abroad so that you no longer have an European establishment, and would have to avoid offering your services to people who are in Europe. So let's assume that you have no European establishment. Then, GDPR can only apply per Art 3(2) to those processing activities that relate to offering goods or services to people who are in Europe. For determining this, IP-based geolocation is indeed common. Very likely, you do not need consent for this. GDPR does not require consent for everything, just a legal basis. There are six potential legal bases in Art 6(1), though the relevant ones are consent, necessity for performing a contract, legal obligations, and necessity for a legitimate interest. For things like security checks, it would be common to claim a legitimate interest. Complying with GDPR can hurt revenue. However, data subjects have a right to data protection, but you do not have a right to a particular business model. Similarly, paying taxes can &quot;hurt revenue&quot;, but it's not really optional. If your business model can't deal with GDPR compliance (or with taxes), it might not be a sound business model. In Europe, many newspapers have since moved from advertising-only to a consent-or-pay model. That is, the user is given a choice: You can read articles without tracking if you buy a subscription. You can access articles for free if you consent to tracking. The legality of this is hotly debated. In principle, such an approach can be compliant, but the details are problematic, for example that you can only buy subscriptions rather than individual articles, and that these subscriptions are often orders of magnitude more expensive than what would be earned through ads. But this might actually be easier to solve for a mobile application than for a website, due to the availability of in-app payment and micropayment infrastructure. In any case, GDPR limits how much you can &quot;encourage&quot; consent – per Art 7(4), you cannot make access to your service conditional on consent. There must be a way to use your app without consenting to anything, unless that consent is actually necessary for the app to work. For example, consenting to camera access is necessary for a QR code reader app to work. It is extremely unlikely that ads would be necessary in this sense. Users also must not suffer detriment for declining or withdrawing consent. From this, the EDPB has developed the concept of &quot;permissible incentive&quot; in their guidelines on consent. In this post, &quot;Europe&quot; means EU/EEA/UK as appropriate.
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.
From a German perspective, it would be absolutely normal and expected that you're providing identity &amp; contact information publicly. Per §5 TMG (Impressumspflicht / Anbieterkennzeichnung) this is required for German tele-media offerings, such as websites or email providers, even if non-commercial. Whereas for you as an upstanding and diligent email provider an abuse@... address should be enough, the German context expects a street address where you could be served with a lawsuit… There absolutely are privacy and free speech issues with this compelled self-doxxing. But by running an email service, you're not just acting as a private person. Your privacy interests and the transparency and security interests of other people have to be balanced. Now since you are not in Germany, the TMG does not apply to you. You have no legal obligation to provide this information. However, the ISP also has no legal obligation to to deliver your email. The ISP does have an obligation to apply appropriate organizational and technical safety measures. It seems that one organizational measure they have found appropriate is that they will only deliver emails from providers that provide public contact information, as would be the norm in Germany. I am not entirely sure how the GDPR applies here. The GDPR doesn't really allow or prohibit disclosures of personal data, it just requires that every purpose of processing for personal data has a legal bases per GDPR Art 6. One such legal basis is a legitimate interest, which boils down to a balancing test between your rights and freedoms and other people's interests. I'm also not sure if the contact information should be classified as personal data in this context, because the contact info primarily relates to your role as an email provider. I'm also not sure if the ISP is processing your personal data in the sense of the GDPR when they merely require you to publish it on your own site. They would be processing it as soon as they scrape, store, or otherwise use this info.
I don't think the issue is that it is a violation of a law, but rather that it is a violation of the terms of service you agree to when you sign up for the site - which is a breach of contract. You can be sued for breach of contract, if the site can prove any damages based on your breach. So if you use a bot to make money on a site, in violation of the site's license agreement, then I believe the site could indeed sue you to get the money back. Also, the phrasing of your question ("creating a robot") raises a separate issue. It is not actually creating the bot that is illegal, but using it where not allowed can be a violation of contract. Suppose person A makes a poker bot, just as a programming exercise, and doesn't use it. But then suppose person B uses the robot created by person A on a site that forbids it. Although this could be a gray area, I do not believe the site would have any recourse against person A (even though they probably would against person B).
Yes, you did something wrong; you used both the university's trade mark and copyright without their permission. I don't know the law in India, however, if it is similar to Australia it is unlikely that the police will be interested in doing anything about it. While it is technically a crime, criminal prosecution is usually reserved for egregious breaches on a for profit basis. I suggest you apologise and agree to stop distributing your app.
Per GDPR Art 12(5), “any actions taken under Articles 15 to 22 and 34 shall be provided free of charge”. The right to rectification is Art 16 and reads in its entirety: The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement. Thus, I think it would be invalid to charge a fee for an address change if that change was made in exercise of your data subject rights. If you didn't invoke this right, it's debatable whether charging a fee would be proper. On the one hand, they can charge whatever service they want (provided that this was part of the contract you entered). On the other hand, they have an obligation to assist you with your exercise of data subject rights. This includes recognising a data subject request even if you didn't explicitly invoke the specific GDPR article. For example, refusing a request for erasure just because you didn't invoke some magic GDPR words would be clearly noncompliant in my opinion. If the company offers multiple customer service options, charging for some of them may be all right. Typically, the lowest-cost solution for a company to deal with GDPR requests is to offer an online self-service option. An email to the data protection officer would typically also be free. Charging for phone support might be fine though. In an insurance context, there could also be a legitimate claim that updating your address is not a mere correction of your personal data, but a modification of the contract (depending on what you're insuring). Another possible counterpoint (which I think is not valid though) would be that the company never stored inaccurate data and therefore doesn't have to satisfy a rectification request.