How The EARN IT Act Is Significantly More Dangerous Than FOSTA


Publish Date:
February 4, 2022
Related Person(s):
Related Organization(s):


From Riana Pfefferkorn, who called out this nonsense two years ago:

To recap, Leahy’s amendment attempts (albeit imperfectly) to foreclose tech providers from liability for online child sexual exploitation offenses “because the provider”: (1) uses strong encryption, (2) can’t decrypt data, or (3) doesn’t take an action that would weaken its encryption. It specifies that providers “shall not be deemed to be in violation of [federal law]” and “shall not otherwise be subject to any [state criminal charge] … or any [civil] claim” due to any of those three grounds. Again, I explained here why that’s not super robust language: for one thing, it would prompt litigation over whether potential liability is “because of” the provider’s use of encryption (if so, the case is barred) or “because of” some other reason (if so, no bar).

That’s a problem in the House version too (found at pp. 16-17), which waters Leahy’s language down to even weaker sauce. For one thing, it takes out Leahy’s section header, “Cybersecurity protections do not give rise to liability,” and changes it to the more anodyne “Encryption technologies.” True, section headers don’t actually have any legal force, but still, this makes it clear that the House bill does not intend to bar liability for using strong encryption, as Leahy’s version ostensibly was supposed to do. Instead, it merely says those three grounds shall not “serve as an independent basis for liability.” The House version also adds language not found in the Leahy amendment that expressly clarifies that courts can consider otherwise-admissible evidence of those three grounds.

What does this mean? It means that a provider’s encryption functionality can still be used to hold the provider liable for child sexual exploitation offenses that occur on the encrypted service – just not as a stand-alone claim. As an example, WhatsApp messages are end-to-end encrypted (E2EE), and WhatsApp lacks the information needed to decrypt them. Under the House EARN IT bill, those features could be used as evidence to support a court finding that WhatsApp was negligent or reckless in transmitting child sex abuse material (CSAM) on its service in violation of state law (both of which are a lower mens rea requirement than the “actual knowledge” standard under federal law). Plus, I also read this House language to mean that if WhatsApp got convicted in a criminal CSAM case, the court could potentially consider WhatsApp’s encryption when evaluating aggravating factors at sentencing (depending on the applicable sentencing laws or guidelines in the jurisdiction).

In short, so long as the criminal charge or civil claim against WhatsApp has some “independent basis” besides its encryption design (i.e., its use of E2EE, its inability to decrypt messages, and its choice not to backdoor its own encryption), that design is otherwise fair game to use against WhatsApp in the case. That was also a problem with the Leahy amendment, as said. The House version just makes it even clearer that EARN IT doesn’t really protect encryption at all. And, as with the Leahy amendment, the foreseeable result is that EARN IT will discourage encryption, not protect it. The specter of protracted litigation under federal law and/or potentially dozens of state CSAM laws with variable mens rea requirements could scare providers into changing, weakening, or removing their encryption in order to avoid liability. That, of course, would do a grave disservice to cybersecurity – which is probably just one more reason why the House version did away with the phrase “cybersecurity protections” in that section header.

So, take a wild guess which version is in this new EARN IT? Yup. It’s the House version. Which, as Riana describes, means that if this bill becomes law encryption becomes a liability for every website.

Read More