18 September

On web browsers ignoring autocomplete="off" for passwords (and, on devbros ignoring the messiness of reality)

A couple of frustrating things have occupied much of my afternoon: unexpected web browser behavior, and annoying devbro behavior.

The unexpected web browser behavior was a stubborn, persistent refusal to honor the autocomplete="off" attribute for passwords. The annoying devbro behavior was a stubborn, persistent refusal to honor the legitimacy of a question. In this thrilling post, I’ll be looking at both.

tl;dr

If you’re just trying to find a simple way to get browsers to honor autocomplete="off" on password fields, here you go: THERE ISN’T ONE. Browsers ignore it for a legitimate reason, but I feel they’re overzealous in their implementation.

However… if you’re trying to do what I was trying to do — basically using a password field as a write-only input — it’s never going to work, for a completely different reason. Why? View source and get back to me.

The only way to really create a write-only input is to not pass the value into the form at all, and have some other mechanism on the back end to detect whether or not the user entered a new value.

I was working on an admin page for a site I built; specifically, a page for editing some low-level configuration settings on the site.

One setting is the “client secret” for authenticating with an external API. I realized having that visible on-screen (even if it’s only on pages that require an administrator-level login) was a bit of a security issue, so I thought I’d quickly solve it by changing the input from type="text" to type="password".

Well, not so fast. Because while it worked, it also triggered Safari’s autocomplete feature, replacing the value in that field with my password for the site, and, maddeningly, replacing the value in the field before it with my username.

Then I remembered an attribute I almost never use: autocomplete="off". I figured I’d just stick that on those fields and, boom, problem solved. Only then I realized, Safari (and as it turns out, every other modern browser) completely ignores autocomplete="off" on passwords.

I set off for StackOverflow in search of an answer to my conundrum, and as is often the case, I stumbled upon another maddening thing: a devbro offering a “You’re doing it wrong” answer. (Seriously… I mean, I know nothing about the author of this post, so I wouldn’t use that epithet, but he literally said this:

It is so wrong that browsers are intentionally ignoring anyone who tries to do it. Those people should stop doing the wrong thing.™

This was at the end of a 600+ word answer that demonstrated classic devbro reasoning:

  1. Rejecting plausibly legitimate use cases as invalid.
  2. Denying obvious design flaws in the existing solution.
  3. Blaming the user for “doing the wrong thing.™”

Back to the specific matter of browsers ignoring autocomplete="off", there are some real problems here:

The autocomplete attribute is standard HTML that browser developers have deliberately chosen to ignore. I understand that browsers are constantly evolving, especially in response to unscrupulous web developers who find ways of exploiting features, and there are definitely ways this feature could be exploited. But!

Browsers are absurdly overzealous in their rejection of autocomplete="off". I was in a situation where the password field was in the middle of a form with 9 text inputs and 5 sets of radio buttons. How often does a login form have all of that? And, none of the fields had “username” or “password” anywhere near them… not in the name or id attributes, nor in their associated <label> fields. AND, there were already prefilled values in the form that got overwritten by autocomplete. AND, Safari is even programmed to aggressively fight any efforts at a workaround, such as extra password fields, hidden with CSS.

It was the last bit that really irked me, because my experimentation showed that Safari is programmed to detect very specific CSS attributes being applied to other fields in the form to determine whether or not there’s a second password field (i.e. that this is a form for resetting your password). If it detects any of various ways of making the field invisible, like display: none; or visibility: hidden; or position: absolute; left: -9999px;, then it will still autocomplete the password. The only CSS I was able to fool it with was opacity: 0; but I suspect that will change soon too.

It’s fine to argue that web developers shouldn’t use autocomplete="off" on password fields, and I even agree, to an extent, for login forms. But if browsers are going to ignore it, and have intricate means of detecting efforts at circumventing that, then they should also recognize that there are legitimate uses for <input type="password"> outside of login forms, and in those cases, honor autocomplete="off".

Here are some suggestions:

Don’t ignore autocomplete="off" if the form contains more than three or four visible input fields. Most login forms only contain two fields. I’ve seen some with more, so I’m being generous here. But how often does a login form contain ten or more fields? Come on.

Look for additional context before autocompleting login fields. Yes, developers can find ways to circumvent this, but if the only clue that this is a login form is the presence of a single password field, then maybe it’s not a login form. Look at the name and id attributes, the <label> tag, and the form’s action attribute. If it really, really doesn’t look like a login form, especially if the developer has also added autocomplete="off", maybe give them the benefit of the doubt and settle down with the autocomplete. At least, maybe in these cases ask the user if they want to autocomplete instead of just doing it. I mean, in some cases the form may be long enough that the autocompleted fields are off screen and the user didn’t even notice they turned yellow.

Don’t replace prefilled values with autocomplete values. I would sincerely appreciate if someone could explain to me the logic behind this one. If a form already has values in the fields, then autocomplete should never overwrite those values. Maybe it’s because I mostly work with HTML forms that are really data editing screens, rather than submission forms, so my perspective is skewed. But the fact that web-based data editing screens are a common thing makes this a valid use case. If a form loads with most or all of the values prefilled, a browser should not presume that it’s OK to autocomplete any of the values.

Check for an indication that the user is already logged in. I suppose there’s a murky security issue here somewhere, but if the browser could detect a cookie with a session ID, or a “log out” link on the page, it would be a way of indicating that the user might already be logged in, and so autocompleting passwords wouldn’t make sense.

Implement support for autocomplete="new-password". Apparently Chrome supports this already, and admittedly it reeks of workaround, but at least it’s something.

With all of these suggestions, I am not saying browsers shouldn’t autocomplete password fields… I’m just suggesting that they look for signs that a password field is not part of a login form, and in those cases, honor autocomplete="off" on password inputs.

Beep for Breakfast!

A package was waiting for me in the mailbox today. It was from someone I don’t know — at least, someone I don’t think I know (and if I do know you, sorry!) — sent from a city I’ve never visited. I opened it with some trepidation, though the anthrax scare and my own quasi-cyberstalker are distant enough memories that I wasn’t too worried. I assumed it was my Obama car magnet, though I wondered a bit why they’d roll up the magnet to send in a roughly 3×3×8 inch box, instead of just a flat envelope.

I was totally, utterly shocked when I opened it and discovered what was actually inside. It was none other than — well, OK, the surprise has already been ruined by the accompanying photo — a Beep for Breakfast cup, just like the one I remembered my grandfather keeping on the edge of his basement sink, so many years ago!

About three months ago, I put out a call to help me locate just such a cup, but I had mostly put it out of my mind, and certainly never expected one to randomly appear at my doorstep one day!

I’m still a bit perplexed as to how the sender obtained my address. (Well, not too perplexed, because I know how I’d have gone about finding it, and it probably wouldn’t have been terribly difficult.) But I’m glad they did!

To the sender (whose identity I will keep to myself), thanks!

Know the difference between BPM and kbps

And it’s not just type case.

As I’ve mentioned, I have taken a shine to Amazon MP3 as my primary source for music downloads now. Sorry, Apple. You know I love you, but Amazon’s just doing it better. Better selection, better prices, and usually better quality. Plus everything’s MP3, not AAC. And no DRM, ever.

And while I don’t anticipate ever switching media players (the iPod and iPhone have served me well, even if you’ve been stumbling a bit lately). My new car’s CD player supports MP3 (and, ugh, WMA) CDs, but not AAC. And yes, I keep an iPod nano in the car (note to potential thieves: no I don’t), but it’s still convenient to load up several albums’ worth of music onto a single CD and pop it in. No annoying cords or dangerous behind-the-wheel iPod fiddling.

So anyway… yeah, Amazon MP3. And MP3s in general.

I’ve ripped my entire CD collection multiple times. First, back in 2001 or so, I ripped it all as 128 kbps MP3s. Then I got to the jazz CDs and noticed how bad 128 kbps actually sounded on some music. So I re-ripped the whole collection as 192 kbps MP3s. That was the smallest size where I didn’t really notice bad audio artifacts.

Then in 2004 Apple introduced the iTunes Store, and with it everything was 128 kbps AAC, Apple’s own, semi-proprietary format. Better compression-to-quality ratio, so 128 kbps AACs sounded as good (to me) as 192 kbps MP3s, at 2/3 the size. So I went back through and started ripping my CDs again, this time as 128 kbps AAC format.

Then last year Apple introduced iTunes Plus, with 256 kbps AAC format. Sure, they’re twice the size, but now I really can tell almost no difference between the compressed versions and uncompressed CD quality. So I started ripping again, but honestly I could not tell the difference between 256 kbps AAC and 160 kbps AAC, but I could tell the difference between 128 and 160. So 160 was my new standard. I only made it through about a quarter of my CDs at this new level though.

Then this year we had the release of my own music on some download sites, and I went with 256 kbps MP3 for those. Combine that with my new embrace of Amazon and their use of 256 kbps MP3 as well, and that pretty much sealed it. 256 kbps MP3 is my new format of choice, and I’m going through my entire CD collection and ripping it yet again in this format.

Which brings me to the whole point of this post. When you put a CD in your computer, iTunes (or whatever ripping software you’re using) grabs CD track information from CDDB. This data is submitted by users. Sometimes if you insert a new release or a really obscure album into your computer, it will tell you that track info could not be found, and it presents you with the opportunity to submit information you’ve entered. Which means any typos or other idiosyncrasies in your own personal way of entering this information will now become what anyone else who inserts the same CD into their computer will see, provided they’re lazy enough not to fix your dumbass mistakes. I’ve grown accustomed to fixing band names, correcting spelling, normalizing title cases (You Don’t Capitalize Articles, Conjunctions or Prepositions in Titles, but It Is Correct to Capitalize Pronouns and Verbs, Even If They’re Only Two Letters Long, Thank You Very Much), etc.

But something I’ve noticed from time to time, and never quite got, really bothers me. First off, I think the BPM field is pretty much useless. Unless you’re a DJ and you actually know the tempo of the songs you’re working with, you have absolutely no need for this field. But sometimes I see it filled in, and with the same value for every track on an album. Highly unlikely. It’s just finally dawned on me over the past few days why this is, though, and it’s because I’ve only ever seen two values in that field: 128 or 192. The same idiots who can’t spell also can’t tell the difference between BPM and kbps.

So, let’s have a little acronym lesson, shall we?

BPM (Beats Per Minute): The “tempo” or, if your musical knowledge is severely lacking, “speed” of a piece of music. How many beats (you know, the part of the music that helps you dance) there are in a minute.

kbps (kilobits per second): This is the amount of data in the compressed (MP3, AAC, WMA or whatever) file per second of music. In other words, it’s the compression quality of the audio file, quantified.

And now you know… the rest of the story.