{"id":47195,"date":"2022-06-21T15:18:04","date_gmt":"2022-06-21T15:18:04","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/33564\/Hidden-Anti-Cryptography-Provisions-In-Internet-Anti-Trust-Bills.html"},"modified":"2022-06-21T15:18:04","modified_gmt":"2022-06-21T15:18:04","slug":"hidden-anti-cryptography-provisions-in-internet-anti-trust-bills","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/hidden-anti-cryptography-provisions-in-internet-anti-trust-bills\/","title":{"rendered":"Hidden Anti-Cryptography Provisions In Internet Anti-Trust Bills"},"content":{"rendered":"

Two bills attempting to reduce the power of Internet monopolies are currently being debated in Congress: S. 2992, the American Innovation and Choice Online Act<\/a>; and S. 2710, the Open App Markets Act<\/a>. Reducing the power to tech monopolies would do more to \u201cfix\u201d the Internet than any other single action, and I am generally in favor of them both. (The Center for American Progress wrote a good summary and evaluation<\/a> of them. I have written<\/a> in support of the bill that would force Google and Apple to give up their monopolies on their phone app stores.)<\/p>\n

There is a significant problem, though. Both bills have provisions that could be used to break end-to-end encryption.<\/p>\n

Let\u2019s start with S. 2992. Sec. 3(c)(7)(A)(iii) would allow a company to deny access to apps installed by users, where those app makers \u201chave been identified [by the Federal Government] as national security, intelligence, or law enforcement risks.\u201d That language is far too broad. It would allow Apple to deny access to an encryption service provider that provides encrypted cloud backups to the cloud (which Apple does not currently offer). All Apple would need to do is point to any number of FBI materials decrying the security risks with \u201cwarrant proof encryption.\u201d<\/p>\n

Sec. 3(c)(7)(A)(vi) states that there shall be no liability for a platform \u201csolely\u201d because it offers \u201cend-to-end encryption.\u201d This language is too narrow. The word \u201csolely\u201d suggests that offering end-to-end encryption could be a factor in determining liability, provided that it is not the only reason. This is very similar to one of the problems with the encryption carve-out in the EARN IT Act. The section also doesn\u2019t mention any other important privacy-protective features and policies, which also shouldn\u2019t be the basis for creating liability for a covered platform under Sec. 3(a).<\/p>\n

In Sec. 2(a)(2), the definition of business user excludes any person who \u201cis a clear national security risk.\u201d This term is undefined, and as such far too broad. It can easily be interpreted to cover any company that offers an end-to-end encrypted alternative, or a service offered in a country whose privacy laws forbid disclosing data in response to US court-ordered surveillance. Again, the FBI\u2019s repeated statements about end-to-end encryption could serve as support.<\/p>\n

Finally, under Sec. 3(b)(2)(B), platforms have an affirmative defense for conduct that would otherwise violate the Act if they do so in order to \u201cprotect safety, user privacy, the security of nonpublic data, or the security of the covered platform.\u201d This language is too vague, and could be used to deny users the ability to use competing services that offer better security\/privacy than the incumbent platform\u2014particularly where the platform offers subpar security in the name of \u201cpublic safety.\u201d For example, today Apple only offers unencrypted iCloud backups, which it can then turn over governments who claim this is necessary for \u201cpublic safety.\u201d Apple can raise this defense to justify its blocking third-party services from offering competing, end-to-end encrypted backups of iMessage and other sensitive data stored on an iPhone.<\/p>\n

S. 2710 has similar problems. Sec 7. (6)(B) contains language specifying that the bill does not \u201crequire a covered company to interoperate or share data with persons or business users that\u2026have been identified by the Federal Government as national security, intelligence, or law enforcement risks.\u201d This would mean that Apple could ignore the prohibition against private APIs, and deny access to otherwise private APIs, for developers of encryption products that have been publicly identified by the FBI. That is, end-to-end encryption products.<\/p>\n

I want those bills to pass, but I want those provisions cleared up so we don\u2019t lose strong end-to-end encryption in our attempt to reign in the tech monopolies.<\/p>\n

Tags: cryptography<\/a>, laws<\/a><\/span> <\/p>\n

Posted on June 21, 2022 at 6:34 AM<\/a> \u2022 16 Comments<\/a> <\/p>\n