I actually find this particularly annoying working for a service aimed at elementary schools.
Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time.
Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.
What you raise is a valid concern, but letting websites decide on enabling/disabling auto-complete is solving it entirely wrong way around.
If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer?
After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.
Websites will always have the ability to disable auto-complete though. Just now it will be though a series of ever-increasingly insane hacks found on StackOverflow (culminating in a custom JavaScript textfield with broken accessibility/internationalization)
Assumes a competent, dedicated local admin is on staff. This is not the case at about 75% of the SMBs I've come into contact with over the past two years
Modern operating systems have a guest mode which doesn't preserve state across sessions - if they cannot manage something this easy, everyone should be using a guest login.
We have a similar issue in the quality management space.
Multiple quality folks on a shop floor accessing a QMS from the same machine. If an IT admin forgets to disable password saving, compliance rules could be broken if one quality member has the ability to electronically sign a document using someone else's saved password.
Why should app developers have the power by default? It sounds to me like you're arguing for that just because that happens to be what you have trouble with. But I'm sure we can find plenty of other people where having the default be the other way would work better.
Your actual problem is that your users can't change even the most basic settings, and you're not in a position to change it for them. I'm sure autocomplete isn't the first nor the last symptom you'll have due to this problem. Good defaults are important, but good defaults are about more than what works for shared desktops in schools with clueless IT people.
> Not all school admins are smart enough to disable password saving
So how would allowing a small percentage of web apps to disable autocomplete resolve this? It only makes it slightly less painful for the websites where autocomplete is disabled - everywhere else you have the same problem. You're asking the wrong people to solve this for you here.
> We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]
> In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
> As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
If you would read what they actually wrote you would notice that - as usual - the headline does not even remotely catch the complexity of the problem.
Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time.
Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.