If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!
Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.
With all the frustration around trying to get Glen Greenwald to use encryption [0,1], it is not surprising that Edward Snowden has described GPG as "damn near unusable" [2]. Such usability problems of end-to-end email encryption tools have been around for a long time. In 1999, a seminal study found that most participants were unable to use PGP 5.0 to encrypt an email when given 1.5 hours to do so [3]. Others have tried to solve these usability problems by automating the key exchange and encryption [4]. However, issues persist around a lack of end-user trust in the software [5], difficulties in getting encryption widely implemented, and having to deal with a general absence of understanding the email architecture [6].
Despite being almost 50 years old [7], email is still not widely encrypted on an end-to-end basis. In this year's SOUPS keynote (the major conference on usable security), Christopher Soghoian described how we as a community are not doing nearly enough to get security into the hands of consumers: we are mostly stuck with the same broken interface as PGP 5.0 from back in 1999, people still face the same conceptual barriers, and we still have crappy defaults [8]. While there has been renewed interest in end-to-end email encryption after the Snowden revelations [9], many projects do not take usability into account.
This talk goes into some of the dos and don'ts gleaned from the usable security research field. Building on a discussion of the history, methodology, and findings of the research, the talk will cover topics including the constraints of humans, the need for clear mental models, and the usefulness of user testing. Some examples of successes and failures will be used to illustrate a range of usable security principles. Remaining pain points such as metadata protection, key management, and end-user understanding will be covered, including proposals for fixing these such as anonymous routing, more appropriate metaphors, and trust on first use. Various open questions will also be discussed, including:
- Should we patch the existing email architecture or should we move towards new protocols?
- How can the crypto community build subversion-resistant collaboration platforms?
- Is there a way to standardise our cryptoplumbing to a restricted set of secure algorithms?
- Can we provide developers with usable coding technologies to prevent nightmares like OpenSSL?
- How should we involve end-users into the development cycle of open source software?
- Can we empower end-users to take security back into their own hands?
English: Finished