The Web public key infrastructure is essential to providing secure communication on the Internet today, and certificate authorities play a crucial role in this ecosystem by issuing certificates. These authorities may misissue certificates or suffer misuse attacks, however, which has given rise to the Certificate Transparency (CT) project. The goal of CT is to store all issued certificates in public logs, which can then be checked for the presence of potentially misissued certificates. Thus, the requirement that a given certificate is indeed in one (or several) of these logs lies at the core of CT. In its current deployment, however, most individual clients do not check that the certificates they see are in logs, as requesting a proof of inclusion directly reveals the certificate and thus creates the clear potential for a violation of that client’s privacy. In this paper, we explore the techniques that have been proposed for privacy-preserving auditing of certificate inclusion, focusing on their effectiveness, efficiency, and suitability in a near-term deployment. In doing so, we also explore the parallels with related problems involving browser clients. Guided by a set of constraints that we develop, we ultimately observe several key limitations in many proposals, ranging from their privacy provisions to the fact that they focus on the interaction between a client and a log but leave open the question of how a client could privately report any certificates that are missing.

Uniform Resource Locators (URLs) unambiguously specify host identity on the web. URLs are syntactically complex, and although software can accurately parse identity from URLs, users are frequently exposed to URLs and expected to do the same. Unfortunately, incorrect assessment of identity from a URL can expose users to attacks, such as typosquatting and phishing. Our work studies how well users can correctly determine the host identity of real URLs from common services and obfuscated "look-alike" URLs. We observe that participants employ a wide range of URL parsing strategies, and can identify real URLs 93% of time. However, only 40% of obfuscated URLs were identified correctly. These mistakes highlighted several ways in which URLs were confusing to users and why their existing URL parsing strategies fall short. We conclude with future research directions for reliably conveying website identity to users.

Certificate Transparency (CT) is an emerging system for enabling the rapid discovery of malicious or misissued certificates. Initially standardized in 2013, CT is now finally beginning to see widespread support. Although CT provides desirable security benefits, web browsers cannot begin requiring all websites to support CT at once, due to the risk of breaking large numbers of websites. We discuss challenges for deployment, analyze the adoption of CT on the web, and measure the error rates experienced by users of the Google Chrome web browser. We find that CT has so far been widely adopted with minimal breakage and warnings. Security researchers often struggle with the tradeoff between security and user frustration: rolling out new security requirements often causes breakage. We view CT as a case study for deploying ecosystem-wide change while trying to minimize end user impact. We discuss the design properties of CT that made its success possible, as well as draw lessons from its risks and pitfalls that could be avoided in future large-scale security deployments.

HTTPS error warnings are supposed to alert browser users to network attacks. Unfortunately, a wide range of non-attack circumstances trigger hundreds of millions of spurious browser warnings per month. Spurious warnings frustrate users, hinder the widespread adoption of HTTPS, and undermine trust in browser warnings. We investigate the root causes of HTTPS error warnings in the field, with the goal of resolving benign errors.

We take a systematic approach to developing a symmetric cryptography library in Javascript. We study various strategies for optimizing the code for the Javascript interpreter, and observe that traditional crypto optimization techniques do not apply when implemented in Javascript. We propose a number of optimizations that reduce both running time and code size. Our optimized library is about four times faster and 12% smaller than the fastest and smallest existing symmetric Javascript encryption libraries. On Internet Explorer 8, our library is about 11 times faster than the fastest previously existing code. In addition, we show that certain symmetric systems that are faster than AES when implemented in native x86 code, are in fact much slower than AES when implemented in Javascript. As a result, the choice of ciphers for a Javascript crypto library may be substantially different from the choice of ciphers when implementing crypto natively. Finally, we study the problem of generating strong randomness in Javascript and give extensive measurements validating our techniques.

How is work created, assigned, and completed on large-scale, crowd-powered systems like Wikipedia? And what design principles might enable these federated online systems to be more effective? This paper reports on a qualitative study of work and task practices on Wikipedia. Despite the availability of tag-based community-wide task assignment mechanisms, informants reported that self-directed goals, within-topic expertise, and fortuitous discovery are more frequently used than community-tagged tasks. We examine how Wikipedia editors organize their actions and the actions of other participants, and what implications this has for understanding, and building tools for, crowd-powered systems, or any web site where the main