MSEdgeExplainers

Password reveal: an explainer

Authors: Bo Cupp, Alex Keng, Greg Whitworth

Status of this Document

This document is intended as a starting point for engaging the community and standards bodies in developing collaborative solutions fit for standardization. As the solutions to problems described in this document progress along the standards-track, we will retain this document as an archive and use this section to keep the community up-to-date with the most current standards venue and content location of future work and discussions.

Motivation:

Passwords have long been a pain point for users on the web. Newer standards and extensions have been introduced in hopes of resolving some of the problems to varying degrees of success.

EdgeHTML offered a unique feature in the platform - a button, the user could use to reveal their passwords. This is not a paradigm that was invented by Microsoft, but it is a common functionality seen across the web on top sites such as Google and Netflix as well as many apps on modern platforms.
Google's login screen with eye toggle to reveal passwords Netflix's "Show" toggle to reveal password

Our motivation to bring that to Chromium came from a preference test with end users of varying technical capabilities. We tried to understand their password input use patterns and perceived value of revealing the password. We wanted to understand how common they felt the problem of incorrectly typing in their password was, then discussed the options with them. The specific question we used: “How often do you incorrectly type in your password?”. Below are the results:

Of the respondents, 2 out of 3 users stated that they incorrectly type in their passwords Occasionally, Frequently, or Very Frequently.

Realizing that many users are still impacted by this, despite evolution of standards and extensions we did a usability study to discuss our proposed reveal solution. We asked them which option they preferred when logging into an email account or their favorite social media network:

Overwhelmingly, 4 out of 5 users chose Option 2, with the reveal capability. Then when looking at the verbatim feedback of why they chose Option 2 over Option 1, it verified the correlation between users incorrectly typing in their passwords and their desire to check it before hitting submit, here are a few verbatim quotes:

There is evidence that suggests that top web sites or apps may offer this functionality, and also that most smaller properties might not do the work required. Users would prefer a universal approach that would work on all of the sites they use.

Finally, we uncovered a scenario that we didn't consider originally – (likely one of many) a site that presents just one password input field during registration - hopefully you typed it right on the first try!

These qualitative factors encouraged us to propose a standardized solution. Additionally we've instrumented the reveal pseudo-element to check how often it appeared and how often it was clicked, and we found that unique users clicked the button on average on up to 10% of the sessions where the pseudo-element appeared.

Proposal:

The goal of our below proposal is to enable two key aspects:

This proposal is to include this as part of CSS Selectors Level 4 with the addition of the following specification text:

The ::reveal pseudo-element

User agents may implement the reveal pseudo-element on inputs that have type=password. If the user agent does implement this pseudo-element the following rules must be followed:

Toggling between revealed and obscured

Allowing for ease of author adjustment

Showing, hiding password reveal element, obscuring the password

Following events would show a password reveal element:

Following events would prevent password reveal element from appearing:

Following events would obscure password and hide a reveal element:

This is important because even though the user may find value in being able to see their password, they may only desire for it to be visible for a short amount of time and doing this allows for keeping the password private even if the user forgets to invoke the ::reveal pseudo-element. Additionally, when the browser itself loses focus the password is obscured as well.

Supported styles

Only the following CSS properties can be applied:

The :revealed pseudo-class

User agents that implement the ::reveal pseudo-element must also implement the :revealed pseudo-class on the password input. When a user invokes the ::reveal pseudo-element the pseudo-class should be applied to the password element. This will allow authors to provide different styles when the password is either revealed or not.

Example

Here is an example of an author that wants to show an eye image to reveal and a closed eye image to hide the password again.

<input type="password">
<style>
input[type=password]::reveal {
    background-image: url(my-eye-image.png);
}
input[type=password]:revealed::reveal {
    background-image: url(my-eye-image-revealed.png);
}
</style>

Related issues | Open a new issue

This site is open source. Improve this page.