Catching Issues in Evolving Interfaces

You may remember this summer’s media frenzy surrounding adultery-matchmaking site Ashley Madison. In brief, the company had its password database hacked, stolen, and posted online with great fanfare. Amidst the stories focusing on noteworthy individuals and the demographics of the membership as a whole, some people have been investigating other aspects of the site’s operations, from their “Affair Guarantee” package to their practice of charging to delete a user’s account from their servers.

"Leaky" Interfaces

One researcher uncovered a quirk of the site’s password-recovery form that actually allows someone to check whether an email address is associated with an account. In security we often refer to such a flaw as “leaking” sensitive information.

Usually leaks that occur with sign-in or password-recovery forms involve the text of the interface – e.g., a sign-in form that responds “The password entered does not match the one on file for this email address” as opposed to the more broad “The email address and/or password entered do not match our records.”

The Ashley Madison password-recovery form actually uses the same text whether or not the email address entered is in their database. However, in one case the text-input field and the button stay present in the screen, and in the other case they disappear.

Image: Screenshots from Ashley Madison’s password-recovery form.
Screenshots of Ashley Madison’s password-recovery form when the email address is not (left) and is (right) part of their database.

Supporting graceful product evolution

Given the site’s focus on discretion – and the carefully-worded textual content of the form – it’s unlikely that someone sat down and intentionally designed it to behave this way. It’s more likely that this interaction snuck in as parts of the site’s architecture were reworked over time. Since the folks working on the site likely don’t reset their passwords on a regular basis (much less compare the result when the email address is and is not in the databse), it's easy to see how the team missed the addition once it was added.

This is an example of why it's important to think of designing not just the product, but also processes to support the product's graceful evolution over time.

Here are some ideas to help catch interface problems that sneak in:

  • Create UX reviewers. Just as teams conduct code reviews before a set of code changes are committed, it can be useful to have UX reviews as well. These can be performed by a designer – advisable when an interface is being implemented against a set of mockups that the designer created – or by another engineer when the change is small. The goal is to make sure that at least one other person takes a solid, critical look at the user-facing implications of the changes, just as the code implications are examined.
  • Create an adversary persona. Many teams craft user personas to help them design interaction patterns that will meet the needs of their diverse user population. Why not also create one or more personas representing attackers? (Thanks to @gretared for her take on @jorm's idea of creating a troll persona – "because you can't design for good without understanding the evil"). This adversary persona can help UX reviewers identify ways that the interface might inadvertantly leak information.
  • Regularly audit against known best practices. Armed with your attacker persona and other approaches for threat modeling, try to identify a set of principles or clear protection goals that you can then use to evaluate the user experience on a regular basis. For example, many websites require users to reauthenticate before accessing sensitive parts of their account; this is a best practice that protects against both accidental and some intentional forms of data compromise. Keep the list of best practices as short as you can, to make it feasible to schedule a regular review that assures your interface hasn't evolved too far from its original privacy-driven design.

Screenshots of Ashley Madison password-recovery forms captured by Troy Hunt and used on his blog, which is published under a CC BY-SA 3.0 license.


Lessons from Architecture School for IoT Security

IoT security needs UX design to appropriately manage complexity. Architecture school teaches how to design for an IoT context with privacy in mind..

Retail Apps and Data Collection

San Franciscans surprised us with positive feelings about data collection by retail apps, which they considered beneficial to their communities.

When Closed-Source Software Wins The Day

We prefer to use open-source software as a matter of principle. We believe that putting software code in the open is the best way for the public to build trust in it. You might find it curious, then, that we choose to foster communication and community through a tool like Slack, which is closed-source. (Note: you can request to join our Slack channel by sending a request to Many software teams that build privacy-preserving tools host similar spaces dedicated to communication with volunteers and users.