- tl;dr sec
- Posts
- How to Slay a Dragon
How to Slay a Dragon
In this talk, Adrienne describes three ways to tackle fundamentally hard problems, using challenges the Chrome security team has faced as illustrative examples.
Clint Gibler
January 14, 2020
Adrienne has been on the Chrome security team for 6 years and focuses on usable security.
In this talk, she describes three ways to tackle fundamentally hard problems, using challenges the Chrome security team has faced as illustrative examples.
Hard Problems in the Real World
There may be some cases where there’s a clear path forward to solve a security problem with no tradeoffs. But in Adrienne’s experience, security is usually a tradeoff between security and something else that you need to make work at the same time.
For example, you can force people to regularly rotate their password. This helps if their credentials have been compromised, but you’ll have to deal with people forgetting their password, writing it down, and/or creating weak or easily guessed passwords.
Often, there is no right choice when it comes to security decisions - there are only imperfect solutions. You have to weigh hard to quantify risks with easier to quantify costs.
Regardless of the tradeoff you decide to make, you’re going to make some people unhappy.
Security is the art of making tradeoffs.
A dragon is a problem with imperfect solutions.
How to Slay a Dragon
When faced with an “impossible” problem that will have tradeoffs either way:
Fight its little cousin instead
Find the more easily solvable variants of this problem.
You can do this over and over again to chip away at the sub parts of the problem that feel tractable.
Accept imperfection and criticism
You’re going to have to accept that after you solve the little subproblems, eventually you’ll still have to make a hard call.
And people will criticize you for the tradeoffs you’ve chosen to make progress.
Pay off your debt over time
Reducing the cost that decision may have made.
She talks about 3 examples of this process.
Site Isolation
“Site isolation” is having one process for each origin. Adopting this model required changing many assumptions throughout the Chrome source.
The core tradeoff here is security vs memory.
After Spectre and Meltdown, the Chrome security team decided that the security benefit was worth it.
#1 Fight its little cousin instead
They made a massive dependency diagram of all the blockers, things they’d have to refactor, things that could cause performance challenges.
Rather than determining how to isolate everything off the bat, they first tackled iframes and extensions.
#2 Accept imperfection and criticism
After pulling off this incredibly feat of engineering that had the security community excited, there were a number of tech outlets that complained about how Chrome now used more memory.
You can’t please everyone. Site isolation requires a fundamental security vs memory usage tradeoff
Chrome Security Indicators
The Chrome security team wanted to be able to indicate to users when their communications with a site were secure (over HTTPS).
They did a number of user studies and found that conveying this context to non technical users is fundamentally hard. They tried a number of icons, but it was tough to convey that HTTP wasn’t secure when the majority of websites at the time did not use TLS. If Chrome had adopted a red icon for HTTP sites on day one, this would have scared users - they would have thought the whole web was insecure, or perhaps that browsing in Chrome was insecure.
They decided that it was easier to get the Internet to move to HTTPs than to teach people the difference between HTTP and HTTPS. They partnered with Firefox and Let’s Encrypt to help get big, popular sites to use HTTPS.
After HTTPS adoption was higher, they could label HTTP as “not secure” instead of HTTPS as “secure.”
Displaying URLs
How do we help people understand web identity?
End users generally don’t know how to validate domain URLs. In a user study, 2/3 of people presented with a Google login page on various TinyURL URLs said they would enter their credentials, even though they were told this was a study where there might be phishing.
On the other hand, technical users like the way URLs work now. If Google were to change the URL display to help convey to non technical users website identity, technical users may find it harder to get the info they want from it.
Formatting and displaying URLs is fundamentally hard: punycode, small window sizes (e.g. mobile) make you choose what to display.
Conclusion
Security is the art of managing risks and tradeoffs.
You’re often in a position where you want to build a new system or you want to make something better, but making it better doesn’t necessarily mean that you’re going to make everything better, it often means you’re going to have to balance the security risks with other types of usability costs or other types of product costs.
But nevertheless,
Dragons are worth slaying.
Impossible problems are tractable a bite at a time.