Unsafe Impedance: safe languages and safe by design software
summary
Security agencies label several languages as memory‑safe (Ruby, Go, Java, Python, Swift) but the paper introduces unsafe impedance, a practical metric for how easy it is to write or load unsafe code, and rates nine languages: C/C++ = no impedance, Rust = low (the unsafe keyword), Java/Swift trending lower due to native interfaces, Erlang/Elixir = high because unsafe work requires NIFs. Proposes an Unsafe Acceptance Process with six required proofs and a long‑term push toward an iron‑beam VM that forbids loading native code.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:29Global call for safe by design
- 3:23Secure by default vs safe languages
- 4:51Unsafe impedance in memory safe languages
- 7:22Categorizing languages by unsafe impedance
- 9:32Unsafe acceptance for libraries
- 12:45Long-term language safety goals
- 17:26Steps for Erlang and Elixir
- 19:12Multi-language systems with UAPs
- 21:03Cost of secure development
- 23:34Q&A: Type checking
- 24:37Q&A: Tooling and standards
- 26:23Q&A: Social pressure
- 27:32Q&A: Open source incentives
- 29:01Q&A: EU regulations
- 30:48Q&A: Java’s unsafe impedance
- 32:16Summary
related talks
01h 01mMemory Safety: Rust vs. C
45mThe existential threat against C++ and where to go from here
43mC++ and Security: Can We Do Better?
30mEnsuring Rust Safety: Strategies for Managing Unsafe Rust
01h 10mHow 10 open source projects manage unsafe code
53mFrom Chaos to Control: Overcoming C and C++’s Inherent Unsafety
05mThe Safety of Unsafe Swift
45mBuilding Safe and Secure Systems in Rust