Blocking certain countries Due to some laws one wants to block certain countries from accessing his app which he uploaded on play console.One turns off those countries in GOOGLE play console so it cannot be downloaded in those country. Someone pirates it and aquires it. In EULA one clearly specifies the blocked countries and reasons for ban . Then writes - &quot;Use of this app is strictly prohibited if you are located or are a resident of or are a citizen or relate to anywhere outside the supported countries.You accept you are liable for any fines or damage we face if you continue.&quot; So for EEA countries the users in EEA are told they are not allowed to use the app at all and must not keep it . If they continue to use they take the responsiblity to pay any GDPR fines or liblity for us. Thus it is strictlgy priohibited. Is such an agreement legal?
If you can’t stand the heat, get out of the kitchen The thrust of this question, as well as many others you have posted, seems to be looking for a way of avoiding your obligations under the GDPR because they are difficult, onerous and/or expensive. Too bad! You don’t have the option of which laws you comply with and which ones you don’t. If I had my choice, I’d comply with the GDPR and not with tax law, but I don’t so I can’t. You have 3 simple choices: Do your best and insure the rest. This means learning what’s required and implementing it to the best of your ability and taking out appropriate insurance cover to deal with any mistakes you make. Ignore the law and hope you don’t get caught. Don’t release apps.
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
No, a company cannot suspend your GDPR rights – contracts can't override the law. Your rights as a data subject apply as long as your personal data is being processed. However, there is no requirement in the GDPR that they fulfill your data subject rights through a self-service mechanism like a “download my data” button. They can require you to use another support channel. (But Google offers infamously bad support.) In some cases, the service may legitimately decide that they cannot give you access to the data, for example if they believe that you are not the actual data subject (e.g. if they think that you hacked the account). The right to access must not adversely affect other people (Art 15(4)). If they have doubts about your identity, they can require further information to verify you (Art 12(6)). If your requests are excessive or unfounded (if you are spamming them), they can also turn down the requests (Art 12(5)).
Is it actually necessary for businesses (such as a Small Town News USA Inc) that do not reside in EU to care about GDPR? Only if they offer goods/services to or monitor behavior of people in the EU (Art. 3(2)). Note that: having a commerce-oriented website that is accessible to EU residents does not by itself constitute offering goods or services in the EU. Rather, a business must show intent to draw EU customers, for example, by using a local language or currency. If it is then how (and by whom) would compliance be audited and/or enforced? Supervisory Authorities will care of it.
These kinds of cookie banners are typically noncompliant and useless since they are not clear and provide too little information to users. Careful: blocking a user who declines consent is usually a GDPR violation! Instead, only those aspects of the site that rely on this consent should be disabled. When cookie consent is needed Per the EU ePrivacy directive (PECR in the UK), information society services (websites, apps, …) are only allowed to store or access information on the end user's device if one of the following holds: the access or storage is strictly necessary for performing a service that was explicitly requested by the user; or the user has given consent Note: there is no “legitimate interest” exception for cookies. When is access/storage strictly necessary? For example, it is strictly necessary for a photography app to store photos on a device. It is strictly necessary for a website to store session cookies so that you can log in to the site. It is strictly necessary for an ecommerce site to store the contents of your shopping cart. It is strictly necessary to remember cookie consent status. And so on. It is not strictly necessary from the perspective of the user to have analytics cookies, ad personalization cookies, or cookies for features that the user doesn't actually use. Many websites that just provide the service the user expects will therefore not have to ask for cookie consent, even if they use cookies. It is worth noting that the ePrivacy definition is entirely technology-neutral. It doesn't relate specifically to cookies, but to any kinds of storage, including LocalStorage. Regulatory guidance considers any access or storage of information on the device to be in scope, even JavaScript APIs in a browser (for example to read the screen dimensions), and considers techniques like fingerprinting to be functionally equivalent and therefore subject to the same rules. It is also worth noting that these rules apply regardless of whether the information being accessed/stored qualifies as “personal data”. What consent is Consent is defined in Art 4(11) and Art 7 GDPR, and further explained in EDPB guidelines 05/2020. A defining feature of consent is that it must be freely given. The user must not suffer “detriment” for revoking or declining consent. And per Art 7(4): 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 that contract. This disallows making access to a service conditional on unrelated consent. For example, it would not be permissible for a website to exclude users who decline consent for advertising cookies. But: The EDPB guidelines discuss that there can be “permissible incentive” for consent. For example, courts and some DPAs seem to be of the opinion that a subscription website can offer free access to users that consented to personalized ads: consent-or-pay-walls can be compliant, whereas consent-walls alone would not. Sometimes consent is really needed for a processing activity, in which case it is OK to block that service until consent is given. For example, websites should not load third party content like YouTube videos or embedded maps until consent is given to share personal data with the third party. The rest of the website should still work, though. If consent was not freely given, if the user didn't have an actual choice, then the consent is invalid. What should the data controller in your scenario do? The data controller should reassess the role of the cookies for which they are trying to ask for consent. If these cookies are strictly necessary from the user's perspective, then it is proper to inform the user about them – but this should not be confused with consent. It is my personal opinion that purely informational cookie banners are confusing/misleading and should be avoided, but this could also be argued differently. If these cookies are not strictly necessary, then the phrasing “We need to use cookies to provide you with our service” is quite misleading. It should be made clearer to the user that they can opt-in to additional services/improvements if they want to. The user should be able to configure this on a per-purpose basis. Thus, more compliant cookie consent flows will typically give the user three options: continue with only strictly necessary cookies/purposes (must be default behaviour if none is selected) consent to all purposes configure purposes For example, I'm fairly happy with the current Reddit cookie notice: Why this is a good notice: it explains the data controllers (Reddit and partners) it summarizes the purposes for which consent is sought it links to more detailed information the presented options “accept all” an “reject non-essential” are less ambiguous that “accept/decline” Comparing this with the list of minimum required information for informed consent in section 3.3.1 of the EDPB guidelines linked above, the following information is missing though: the identity of the “partners” what (type of) data will be collected and used the existence of the right to withdraw consent
If GDPR applies, then no one can opt out. If it doesn't apply, then an IP block is superfluous. Whether GDPR applies is determined by Art 3 GDPR. For this, we must distinguish where the data controller is operating from. It is irrelevant where the site is hosted, but primarily relevant where the data controller (your colleague) has an “establishment”, e.g. where he resides or typically works from. Per Art 3(1), GDPR applies to all processing activities in the context of an European establishment, regardless of where the users are. So if your colleague were running this site from Europe, they wouldn't be able to circumvent GDPR by blocking European users. However, if your colleague is running this site from outside of Europe, then Art 3(1) doesn't trigger. Per Art 3(2), GDPR can apply to processing activities where there is no European establishment. There is the Art 3(2)(a) “targeting criterion”: if your colleague “offers” goods or services to people who are in Europe, regardless whether paid or gratis, then GDPR applies to all processing activities related to this offer. I'll discuss this more below. There is also the Art 3(2)(b) criterion: if your colleague monitors the behaviour of people that occurs in Europe, then GDPR applies. For example, an app collecting geolocation information or a website creating interest profiles for ad targeting might trigger this criterion. An IP block can help to establish that no offering/monitoring related to people who are in Europe is happening, but it might not be necessary. It may be worth talking a bit more about the targeting criterion. The GDPR explicitly says that mere availability of a website in Europe doesn't imply that GDPR would apply. Instead, it is necessary to establish the data controller's intention – are they soliciting users from Europe, or otherwise expecting that people from Europe might use those services? Recital 23 gives a couple of non-exhaustive factors that can be considered here, for example: the site uses a language or currency used in the EU but not used in the controller's own country the site mentions users or customers from Europe, e.g. in testimonials This means that a lot of US websites, written in English or Spanish, only mentioning payment in USD (if any), not mentioning any European countries, will not be subject to GDPR. Then, occasional European visitors are irrelevant. It wouldn't be necessary to IP-block potential European users. However, such an IP-based block would help establish that the data controller really doesn't intend for those services to be offered to people who are in Europe. My personal opinion is that it's wasted effort to block users from foreign countries in case their foreign laws claim to apply, but if such a block brings peace of mind that might be worth it. While geoblocking might not be necessary, is it sufficient? There is no clear guidance on this subject, but it seems to be generally accepted that IP-based geoblocking is fine, even though it is trivially circumvented using VPN services. Of course, if a website were to block European IP addresses but were to also advertise that people in Europe can use their services via VPNs, that would probably still be an “offer” and might defeat the point of doing any geoblocking. The Art 3(1)(a) targeting criterion is most easily applied to things like ecommerce where physical goods are shipped to the customer in return for payment – so essentially whenever the data controller participates in the EU Single Market. This is roughly similar to the concept of a Nexus in US tax law. But in principle the targeting criterion can also apply to other kinds of websites or apps such as blogs, even if they are gratis. GDPR does not just apply to for-profit commercial activity, and doesn't distinguish between controllers that are entities/LLCs and controllers who are natural persons. Things are slightly more complicated due to the Art 3(2)(b) monitoring criterion and the pervasive use of online trackers on websites, but this aspect of the GDPR is difficult to enforce and frequently ignored. In this answer, “Europe” means the European Union (EU), the European Economic Area (EEA), and the United Kingdom (UK). Note that countries like Norway are covered by GDPR, whereas Switzerland is not. Of course, the GDPR is not the only privacy law relevant internationally.
Apple has rules for publishing apps on the App Store, and either you follow the rules, or your app won't go on the App Store, simple as that. What you do is either not put your app on the App Store, or make the changes they ask you to make. Why are there conflicting statements? Because Apple and Google are different companies. Does Apple ask the other company? No, why would they spend their time on this, when they can ask you to make the changes? In the end, Apple has huge pockets, so they are not going to approve anything that might give a company a way to take money out of their pocket. What you want to do sounds very much like it could give some company a pretext to sue Apple; that's one thing that Apple won't let happen.
Only if you ask Valve for permission first, and they agree in writing. I'm not a lawyer, but when I was reading through the Subscriber license you linked, this stuck out to me: You are entitled to use the Content and Services for your own personal use, but you are not entitled to: (i) sell, grant a security interest in or transfer reproductions of the Content and Services to other parties in any way, nor to rent, lease or license the Content and Services to others without the prior written consent of Valve, except to the extent expressly permitted elsewhere in this Agreement (including any Subscription Terms or Rules of Use); (ii) host or provide matchmaking services for the Content and Services or emulate or redirect the communication protocols used by Valve in any network feature of the Content and Services, through protocol emulation, tunneling, modifying or adding components to the Content and Services, use of a utility program or any other techniques now known or hereafter developed, for any purpose including, but not limited to network play over the Internet, network play utilizing commercial or non-commercial gaming networks or as part of content aggregation networks, websites or services, without the prior written consent of Valve; or (iii) exploit the Content and Services or any of its parts for any commercial purpose, except as expressly permitted elsewhere in this Agreement (including any Subscription Terms or Rules of Use). The part that I've bolded is probably the part that makes this against the Terms of Service, since in order to post these sorts of automated messages to their service, you'd need to use a &quot;utility program&quot; to &quot;emulate or redirect the communication protocols used by Valve in any network feature of the Content and Services, through protocol emulation, tunneling, modifying or adding components to the Content and Services&quot;. I doubt that Valve would ever agree, since such a program could very easily be used to create spam bots that works bombard users with unsolicited advertisements, but maybe Valve would be willing to cut deals with AAA video game companies to let them deploy tools to automatically manage their store pages.