Hidden Anti-Cryptography Provisions in Internet Anti-Trust Bills - Schneier on Security:
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; and S. 2710, the Open App Markets Act. Reducing the power to tech monopolies would do more to "fix" 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 of them. I have written in support of the bill that would force Google and Apple to give up their monopolies on their phone app stores.)
There is a significant problem, though. Both bills have provisions that could be used to break end-to-end encryption.
Let's 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 "have been identified [by the Federal Government] as national security, intelligence, or law enforcement risks." That language is far too broad. [...]
Sec. 3(c)(7)(A)(vi) states that there shall be no liability for a platform "solely" because it offers "end-to-end encryption." This language is too narrow. The word "solely" suggests that offering end-to-end encryption could be a factor in determining liability, provided that it is not the only reason. [...]
In Sec. 2(a)(2), the definition of business user excludes any person who "is a clear national security risk." 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. [...]
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 "protect safety, user privacy, the security of nonpublic data, or the security of the covered platform." 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—particularly where the platform offers subpar security in the name of "public safety." [...]
S. 2710 has similar problems. Sec 7. (6)(B) contains language specifying that the bill does not "require a covered company to interoperate or share data with persons or business users that...have been identified by the Federal Government as national security, intelligence, or law enforcement risks." 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.
I want those bills to pass, but I want those provisions cleared up so we don't lose strong end-to-end encryption in our attempt to reign in the tech monopolies.
If you are a US citizen, just in case you want to express your opinion, don't forget that Senators love to hear from their constituents.
(Score: 0) by Anonymous Coward on Thursday June 23 2022, @01:22AM (3 children)
The infrastructure is being put into place to prevent running software that is not blessed by a central authority. This would allow enforcing anti-encryption laws for the masses.
E.g., Microsoft's Pluton (that is being integrated into all the major brands' x86 CPUs; and the one vendor's ARM SoCs that are licensed to run windows), has as one of its features remote attestation. You are not required to use Pluton today, but in a much more likely future than many of us would like, its remote attestation of the software / user lockout state of the hardware you are running may be required for online banking, government websites, maybe other random sites due to "app stores" on the major platforms enforcing restrictions on all software in the "store"-- for your security, of course. Major mobile platforms are already able to enforce such a policy. Android safetynet, user having root causes safetynet to fail, blocking banking apps, etc. Google could add using an unapproved app (possibly employing unauthorized encryption) to trigger safetynet fail too. And, on iOS, you literally need to run an exploit to be able to access your hardware in a way that the ghost of Mr. Jobs hasn't approved of.
In such a world, yes, "only outlaws will use end-to-end encryption."
An observation. Once infrastructure is in place that can facilitate , it is only a matter of time until it is used to enable -- no matter how unpopular, distasteful, immoral, (currently) illegal, etc., is.
(Score: 2) by JoeMerchant on Thursday June 23 2022, @02:19AM (1 child)
>The infrastructure is being put into place to prevent running software that is not blessed by a central authority.
They can try, and they can get some mainstream (Intel, maybe AMD) hardware vendors on board.
I seriously doubt they will be outlawing ARM processors and open source software, at least not successfully.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2, Interesting) by Anonymous Coward on Thursday June 23 2022, @03:43AM
Most ARM processors already require closed-source blobs to run Linux, often tied to specific kernel builds, and any Windows compatible ARM device requires a Microsoft signed bootloader. They don't need to outlaw open source, just make it impossible to run non-approved versions.
(Score: 4, Informative) by tangomargarine on Thursday June 23 2022, @02:59AM
Oh, you mean like TPM and SecureBoot, which is already implemented and out there, that Microsoft just Double Pinky Promised they won't use to fuck us over and lock us out of other OSs?
Bend Over Here It Comes Again
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"