2019 Security Wish List In Review
In January of this year, I put together a wish list for security in 2019. As the year draws to a close, I wanted to look back and reflect on what was accomplished, and where there’s still work to do.
Rust breakthrough
Original success criteria:
- Adoption of Rust as an official development language by another major OS and browser.
- Public talks/writing from teams that adopted Rust in these domains describing the value it added from a security perspective.
Rust is officially used in Firefox and ChromeOS. Microsoft has written encouraging blog posts about usage in Windows, and I’m told Android is currently testing out Rust for a new component. There are now enough large organizations adopting Rust that RustConf this year featured a meetup for them!
I’m not sure the first criteria was accomplished to the letter, but I think we hit the spirit for it.
While lots of organizations are adopting Rust, there hasn’t been enough public writing about the impact it’s having on security. This will be a big opportunity for 2020.
Security key breakthrough
Original success criteria:
- Google Accounts, Facebook, and Twitter switching from the legacy u2f.js API to webauthn.
- Every major browser ships webauthn in a stable release. NFC security key support on iOS.
- 25% drop in cost for keys (currently $10 for USB only, $17 for NFC, $25 for BLE+NFC). This would mostly be accomplished by removing the need for BLE keys, via iOS support for NFC keys, but cost reduction in other variants would also be valuable.
- My bank to offer security key support.
- Just once when talking to someone about security, I’d like them to have heard of security keys before I spoke to them.
Google partially migrated (login uses webauthn, but key registration still uses u2f.js). Twitter has fully migrated, and Facebook has not migrated at all. Partial credit on the first criteria.
With just a few weeks to spare, Apple shipped iOS 13.3 with NFC key support. Cross number two off the list!
The promotion that led to Yubikeys being available for only $10 has ended, so this has regressed I believe. Removing the need for BLE keys does present some savings, but on the whole I don’t believe the cost of keys has meaningfully decreased.
My bank still doesn’t offer security keys.
However, awareness is on a great trajectory. My new job involves me doing a security briefing for all on-boarding staff, so I’ve seen first hand that there are people who are familiar with security keys already!
TLS 1.3 to the moon
Original success criteria:
- TLS 1.3 jumps from 5.7% of TLS connections in Firefox to 15%.
- TLS 1.0+1.1 drop from 1.2% of TLS connections in Firefox to less than 0.1%.
The first target was easily eclipsed, TLS 1.3 is now around 30% of TLS connections in Firefox.
TLS 1.0+1.1 are currently hovering between 0.1% and 0.3% of TLS connections in Firefox, so not quite hit. However, all major browsers have pledged to drop TLS 1.0 and 1.1 in 2020, and that plan is on track, so the miss here is ultimately not a big deal.
Who builds secure software?
Original success criteria:
- Op-Eds, papers, and blog posts discussing to what extent the current situation is a problem, how can we better fund secure software development, and whether this is just a small piece of a broader conversation on monopolist behavior in technology or if security is a distinct challenge.
Not even close. I’m not sure I’ve seen anyone writing about this, much less a groundswell of attention to this issue. To me this issue remained front of mind in 2019, as my dependence on ChromeOS’s security has deepened as has my concerns about Google.
Urgency around exploitation
Original success criteria:
- At least one major platform explicitly acknowledges this crisis, and announces a plan to address it systemically, with deliverables starting in 2019.
- Substantial increase in the difficult of exploitation from that platform, based on analysis independent security researchers.
Microsoft wrote a series of blog posts describing why memory unsafety is untenable, and Rust is a possible solution, however they didn’t quite commit to actually adopting Rust and moving away from C and C++. There were similarly encouraging signs from parts of the Linux kernel community, but no firm commitments. I’ve had lots of private conversations about this issue with developers of others operating systems and browsers, but no public statements.
That said, I do believe progress was made on this issue, spurred along by Google Project Zero’s disclosure of an exploitation campaign targeting Uyghurs, and the disclosure of exploitation of a 0-day vulnerability in WhatsApp targeting 1,400 people. It is my hope that people see these for what they are: trailing indicators that we need to make fundamental changes to how we develop software in order to protect our users.
User agency first
Original success criteria:
- Op-Eds, papers, and blog posts discussing how well software is living up to its responsibility to act on users' behalves.
- At least one major product announces a substantial functionality change as a result.
In 2019, software continued to get more complex, and collectively almost no time was spent talking about how users can have control over their digital experiences in light of that.
Conclusion
On the first three, technical, targets lots of visible progress occurred. On the second three, social, targets not as much occurred. This possibly reflects that my technical skills are stronger, and therefore my ability to make projections there is better calibrated.
On urgency around exploitation in general, and memory unsafety (as addressed by Rust) in particular, I believe a lot of excellent work was started in 2019, and I’m hopeful that in 2020 results can be delivered. And I’m optimistic that when we do pursue systemic remediation to memory unsafety, it’ll have a significant impact on at-risk users' security.