How to comply with 18 USC 2257A We want our app to comply with 18 USC 2257A, which states that (...) producers of pornography, or depictions of any sexual activity using actual people, are required to verify that the performers are of legal age (18–years–old or older) by maintaining records of the performers’ names and ages. They also are required to disclose the location of these records,... So I suppose we basically need to disclose the exact geolocation of the datacenters that store this kind of content. We're currently using Google's Firebase, hence Google Cloud Storage to keep our files. And, as I would expect, they have no guarantee about which zone the servers are located. My question is: is it possible in any way to achieve compliance with 18 USC 2257A while using Google Cloud Storage (Or perhaps any other cloud storage service)? If not, if you have suggestions of providers that may offer the service that we need, I'm happy to hear them.
So I suppose we basically need to disclose the exact geolocation of the datacenters that store this kind of content. That is incorrect. You need to identify a place of business where federal investigators may inspect the records without first making an appointment for access. The location of cloud storage is not particularly relevant. is it possible in any way to achieve compliance with 18 USC 2257A while using Google Cloud Storage (Or perhaps any other cloud storage service)? Yes. You must store the records as required by the statute and by the regulations issued under the authority of that statute, 28 CFR Part 75. I only scanned the regulations, but it seems that the &quot;location&quot; of the records is the place where they are available for inspection, not necessarily the place where digital files are stored. (The regulations also provide that you may indeed keep the records in digital form.) But consider, for example, what would happen if the FBI came knocking for an inspection and a local utility company accidentally severed the fiber cable on the next block. Such a network outage happened at my company a few years ago, and the incident disabled all of our redundant networking, so we had no internet access whatsoever for several hours. The investigators would probably tolerate such a disruption, but it is probably better to have a copy on site in addition to any off-site copies you might have. Regardless, you should hire a lawyer with relevant experience, because you need advice from someone who can find out whether there has been any litigation that may have a bearing on your rights and obligations, and you should find out what state and local law have to say about this, if anything. This is a criminal statute, and trying to protect yourself from criminal liability without qualified legal advice is quite possibly going to leave you vulnerable.
This is a good question, as it raises an issue which places the controller's interest in providing a smoothly functioning customer sign up process against customers' right not to have their data leaked. Note that it is not necessary to consider &quot;enumeration&quot; here. Even just being able to check whether one person has a registered account raises the issue. The relevant provisions of the EU GDPR (or in the UK, the UK GDPR as defined in sections 3(1) and 205(4) of the Data Protection Act 2018) are (emphasis added): Article 4(2): 'processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction So, disclosure of the fact that a user has a registered account amounts to &quot;processing&quot;. Article 6(1): Processing shall be lawful only if and to the extent that at least one of the following applies: (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. Of these, only (a) and (f) are likely to be of any relevance: (a) is not too useful since it isn't feasible to design a sign-up system that depends on the user's consent (which they may not give). That leaves us with (f). As noted by the Information Commissioner's Office, &quot;Legitimate interests is the most flexible lawful basis for processing, but you cannot assume it will always be the most appropriate. It is likely to be most appropriate where you use people’s data in ways they would reasonably expect and which have a minimal privacy impact, or where there is a compelling justification for the processing.&quot;. The legitimate interest here would be that you need a sign up system which prevents duplicate registrations. Remember though that the processing has to be &quot;necessary&quot; for the purposes of the legitimate interest. One might argue that it is not since you could design the system to give the appearance of accepting the duplicate registration followed by sending an email to the account holder to inform them. On the other hand this will result in a less user friendly experience which could itself be a legitimate interest. Ultimately this is a balancing exercise and it is hard to say whether you have struck the right balance until someone complains to the ICO or the court and a decision is issued. The fact that the practice is widespread among well-resourced and large companies would tend to indicate that it is lawful albeit this is not conclusive in the absence of a court decision. I'm not aware of any cases involving this particular issue but would be interested to hear from others on this point. If the processing is unlawful then Article 18 is applicable: The data subject shall have the right to obtain from the controller restriction of processing where one of the following applies: [...] (b) the processing is unlawful and the data subject opposes the erasure of the personal data and requests the restriction of their use instead Where processing has been restricted under paragraph 1, such personal data shall, with the exception of storage, only be processed with the data subject’s consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the Union or of a Member State. In other words, the data subject could ask you not to disclose their registration status via the sign up page, and you would be obliged to comply with the request. Separately from the above points, in order to be lawful you must provide the data subject with certain prescribed information at the time when the data is collected. Of particular relevance here are the following items: Article 13(1): Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information: [...] (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing; (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party; So even if you conclude that the processing will be lawful you will have to give some consideration to the basis so that you can comply with the above provision.
Invasion of privacy and false light torts would probably not be applicable here. Very few states have adopted the false light tort because of its conflict with First Amendment principles and there was no agreement or even request to keep the text private. The copyright issue is trickier. First all, the TOS may provide that the copyright belongs to the text service provider or that there is a license. But, even in the absence of an express license, sending someone a message which is equivalent to sending them a letter, probably gives rise to an implied license that the person to whom it is sent can use the message that arises merely from the act of sending it without restriction or qualification. Implied license and fair use also heavily overlap. Publishing the text exactly as it was sent to you protects you from defamation liability because it is true. On the whole it would be extremely unlikely for there to be any legal liability for publishing a text from someone that they sent to you. Of course, one can imagine exceptions. If the person receiving the text was in an attorney-client relationship, or priest-parishioner making confession relationship, or was communicating regarding classified national security matters, or there was a non-disclosure agreement in place, among other possibilities, an evidentiary privilege and duty of confidentiality could apply and disclosing the material without the permission of the privilege holder could breach a duty of confidentiality and give rise to liability. If the picture was a nude picture of a minor, there could be a criminal and/or civil liability issue, and some states have also made posting "revenge porn" a criminal offense and/or a basis for civil liability. If the disclosure was effectively a way to facilitate insider trading that could be a problem. If the contents of the text were accurately transmitted but known to be false and were disseminated without disclosure of its falsity for the purpose of defrauding a third party, that could be a problem. But, no facts that obviously flag any exception are identified in the question. The mere fact that the posting may be embarrassing, or hurt someone's reputation, or was made without someone's express consent, in general, would not be a basis for liability.
Two questions, here: Can a text story be obscene under the law? As one who hosts a website, can you be held liable for the content of a site? Can a text story be legally obscene The United States Court of Appeals for the Eleventh Circuit published their opinion on United States of America v. Frank Russell McCoy on March 12, 2015. Mr. McCoy maintained a website, young-stuff.com, from his home. He authored or edited more than 200 graphic stories detailing "sexual abuse, rape, and torture of young children." Mr. McCoy was indicted in June, 2007 and found guilty. The appeals court affirmed the conviction. Both the initial trial court and the appeals court found Mr. McCoy's stories "lack serious literary, artistic, political, or scientific value." Can a web site's host be held liable for the content of a site? Section 230 of the Communications Decency Act says that No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider. It also states that no internet entity has immunity from federal criminal law. Section 230 has been found to apply to intermediaries of third-party content. Generally, most assume that when the content is simply hosted and not moderated by the web site then there is no liability for the provider. That's not always the case and is determined by whether the host of the web site is considered a provider of interactive computer services or an information content provider. Any person responsible "in whole or in part...for the creation or development of information" is an information content provider. Which are you? In Fair Housing Council of San Fernando Valley v. Roommates.com, the 9th Circuit Court of Appeals ruled that roommates.com was not immune under Section 230 because they asked questions of their users that helped facilitate a potentially illegal search under the Fair Housing Act. They, therefore, helped create the content the site hosted. The question will ultimately rest on whether someone decides the content is obscene enough to be prosecuted and then if you, the site's host, aided in creating the content. This definitely requires the assistance of competent legal counsel.
According to EU case law, everything in your scenario is legal except if Example Site is hosting the image without authorization and Pirate Site is a for-profit site, then Pirate Site is presumed to be violating Article 3 of the Copyright Directive on communication to the public (in this scenario, Example Site is also trivially violating Article 2 on the right to reproduction). In Meltwater, Case C-360/13, the court ruled that browser cache and on-screen copies fell under the temporary reproduction exception, Article 5(1) of the Copyright Directive. This means that the visitor is not infringing copyright (IPKat reference). In BestWater, Case C-348/13, the court ruled that embedding content was itself not a communication to the public when that content was hosted with rightsholder authorization, and so did not violate Article 3. This means that Pirate Site is not infringing on communication to the public rights (it is also not creating a copy itself, so is not breaking Article 2) (IPKat reference). When content is not hosted with authorization, the situation is quite a bit more nuanced. GS Media, Case C-160/15, is the controlling case. Here, the court ruled that if a link (note it doesn't even have to be embedded/hotlinked) is posted by a for-profit site, that site is expected to have done its due diligence to ensure the linked content is hosted legally. Therefore, it is presumed to be violating Article 3, i.e., the burden of proof is on the link posting site to demonstrate that it had done its due diligence in verifying the legality of the linked content. So in this scenario, Pirate Site is presumed to be infringing on communication to the public rights (IPKat reference - WARNING: slightly NSFW image here, Playboy was one of the parties to the case).
When the data controller is from the EU/EEA/UK, the GDPR applies. Any website inherently processes personal data such as IP addresses. Thus, when transferring personal data into the US (e.g. because the website is hosted in the US), it is necessary to comply with the GDPR's Chapter V which covers international transfers. The US hoster would also have to be bound as a data processor per Art 28. There are multiple legal bases for international transfers into the US. There used to be an “adequacy decision” that allowed transfers without further conditions in the form of the EU–US Privacy Shield, but it was found invalid in the 2020 Schrems II ruling due to concerns about US mass surveillance. The next alternative are “appropriate safeguards” to protect the transfer, which generally requires that the data exporter and data importer (here: you and the hoster) sign standard contractual clauses (SCCs). But in the wake of Schrems II, it is clear that SCCs alone are not sufficient, and would generally require supplemental measures to protect the personal data. The concern is that an US company would not be legally able to comply with the SCCs they've signed. Art 49 has fallback legal bases for occasional transfers such as the data subject's explicit consent, which are not useful here. What most people do is pretend like SCCs are sufficient and hope that regulators turn a blind eye, at least until another adequacy decision is negotiated. However, guidance by regulators including EDPB recommendation 01/2020 explains that it's the responsibility of data controllers to analyze their specific transfers, adopt supplemental measures if necessary, or stop transfers if such measures are impossible. To cut the chase short: there are no technical measures that could help in a cloud or SaaS setting, and I would include webhosting in that setting. As a consequence, it's effectively impossible to be GDPR-compliant while relying on services that store or process personal data in the United States. It would therefore be prudent to migrate an US-hosted website to a server located in the EU/EEA or in a country that has an adequacy decision. Your registrar's information seems correct in this regard, though it is admittedly a bit self-serving for a company that offers web hosting itself. On to your specific questions/arguments. Is all of this irrelevant because you are not using an US “cloud” service? No. Don't get distracted by the word “cloud”. The issue is that you are using an US-based service that processes personal data in the clear. Can you avoid disclosing the international transfer because you aren't processing personal data? But you are most likely processing personal data. The GDPR's definition of personal data does not just include identifying information, but any information relating to identifiable persons. Identification includes being able to single out a person. IP addresses are likely (but not necessarily) a kind of personal data. In any case, your use of Google Analytics sets tracking cookies that definitely allow identification of visitors. Since you are performing an international transfer of personal data, you must inform the data subjects. Is copying a standard privacy policy sufficient? While transparency about processing activities is an important part of GDPR, it is only a part. Other parts include: having a clear purpose and legal basis for processing activities binding services who process personal data on your behalf as data processors per Art 28 (here: in particular hosting and analytics) finding and implementing appropriate security measures having a plan for dealing with data subject requests In any case, the privacy policy must fulfil all points mentioned in Art 13 GDPR. Ideally, it should also cover the information obligations from Art 15. There are guidelines on transparency from the EDPB. If your privacy policy was drafted before 25 May 2018, it likely wasn't updated for GDPR. There is a staff-only private area. Whether or not there is any private area is not relevant for GDPR. GDPR is not about protecting private data in contrast to public data, but about processing of personal data, i.e. data that relates to persons. Also note that the staff members are data subjects as well. The only cookies are “technical cookies”. Very good! The ePrivacy directive is closely related to GDPR and addresses what kind of information you may use from user devices, including cookies or similar technologies like LocalStorage. This directive was implemented in the Italian Data Protection Code. You may only use cookies etc if they are strictly necessary for providing the service explicitly requested by the user (such as storing a language preference on your website), or if the user has given their consent. You are using Google Analytics, but only if the user gives consent. Since Google Analytics is an US-based service, some of the above concerns about international transfers apply. Relying on consent is good, though Art 7 GDPR gives some conditions for consent. In particular, the user must have a real choice. While analytics can probably be used without consent, setting cookies for analytics does require consent. As much as I loathe them, consent management tools can be useful here e.g. because they also help with keeping records of consent. In summary: While you have good data minimization practices, your website likely isn't GDPR-compliant in its current form. You can take some first steps toward better compliance, such as by avoiding unnecessary international transfers and updating the privacy policy to better align with Art 13 GDPR. Fines are unpredictable. Most data controllers are non-compliant in some way (probably including myself). But most data controllers don't end up getting fined. While fines should be “effective” and “dissuasive”, they also have to be proportionate to the infringement. Many data controllers have been able to substantially reduce or completely avoid fines by quickly remediating compliance issues when being contacted by their supervisory authority. I have yet to hear about a fine for data transfers into the US, but of course I have no idea what cases the supervisory authorities are currently investigating.
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
Simply use a cookie to store consent. First consider the opposite. If a user does not agree to store cookies, a cookie is the only way to remember this, as you want to avoid a new pop-up on every page-load. Because this use of a cookie is functional, you don't need permission to store that cookie. You seem have the impression that you have to prove towards the ICO if someone has provided consent. However I think it would be sufficient if you can demonstrate how your website works technically. In particular whether consent is handled properly. You might need to create screenshots or a screencast to do so. Add new proof after each major update of your website. Storing consent server-side would violate the data minimization principle of the GDPR I think. In particular because you would need to do something to be able to identify users. That would violate Art. 11(1) GDPR: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Notice it is possible to configure google analytics in a way so you don't need any consent. See my answer to this question. Just IP anonymization is not sufficient.