The difference is that disabling of "autocomplete" is a user interface issue, and can be addressed by the browser I use. The problem of ridiculous password restrictions is not usually something that can be controlled by the client.
I like the idea of convincing IT to change crazy password policies, but I don't have the mental energy to navigate these huge bureaucracies.
When IT is convinced they have to decide when to put it into the budget. If they think their policy is not okay, just not perfect the fix will probably be buried in the bottom of the budget pile and cut every year.
When a company does not follow a NIST standard [that applies] that is admissible in court against them. While it isn't an automatic loss they have to defend why they didn't follow the standard. In some cases the defense is not to the jury, but the the judge while can make a "statement of fact" and tell the jury to assume negligence for not following the standards. When legal says the cost of not complying with NIST password guidelines is potentially 10 million dollars that puts fixing the password requirements much higher in the budget.
But that's a recent change to the NIST guidance. Searching for "Bill Burr NIST" will turn up recent stories about the original author's regret of a lot of the password recommendations from the original publication in 2003 that survived until the update this year.
A recommendation won't allow you to sue a company contrary to what the other commenters seem to think, but it's enough for any internal employee who works on something to call for and justify a change.
Your question is one of the reasons I didn't say the legal route was a better way. It is an option that may get better results in some cases. Even in the US it may not always get the best result.
So - what's ok to break, and what isn't? In the end, it's a judgement call on the browser developer. I like what another person said here - the browser is an "user agent", as long as the actions are clearly motivated by user interest, I think they're ok even if/when they break some standards.
I'd say, for a start, achieving consensus before breaking is ideal. If the attempt to achieve consensus fails, at least I can see they tried (or I can disagree). Hopefully in the future users can use their leverage to make it not a judgement call on the browser developer, but a judgement call by the community of users. The myriad of features in browsers, however, makes it a difficult arena to enter making a large swath of users subject to these judgement calls.
> as long as the actions are clearly motivated by user interest
It doesn't matter what the road is paved with. Many things are not clear and intent is also not clear. You should not use intent to determine what you are ok with, you should use the action and effect. You may be ok with Safari's approach to third party cookies, or Chrome's approach to cookies, which is ok. But you might not be ok with the next action, and when it hurts you as a user, the reasoning will matter less than it does when you support it.
The people who disagree are third-parties who want to impose their own preferences on Chrome's users. Their opinions should not be taken into account because they are not Chrome's users.
If there is never a valid reason to disable autocomplete and therefore "the standard is wrong", there are ways to change the standard. The standardisation process for Web APIs actively involves browser vendors but allows for building a consensus before jumping the gun.
If the Chrome team could figure out a way to force all of those sites to change their password restrictions through a Chrome update, they probably would.
What? No. Clearly it should never have been in the spec, and a browser should be the extension of the users desires.
In a perfect world that would be the case, because the browser would belong to the user. But how much did you pay for your last browser? Consider yourself lucky when the browser does something you consider beneficial.
How insane would the password rules have to be for anyone to travel 1 hour more to go to a different university? How insane for them to stop playing a given video game? To change banking institutions?
I don't have the answer for others, but for me, the answer to all of those is "pretty insane". Except for the banking case, password security is a minor concern (and even then, the system protects us with anti-fraud laws and what not).
In a sense, the market is sorting itself out: it just decided that it doesn't care much about passwords. In fact, if you figure out a way to be profitable while offering twice the interest rate but every time people log in to your bank they have to dance the robot or whatever, you'd probably still have customers.
The right thing to do is to bring the issue up with whoever is running the website. If they decide not to act on it because they think they know security/UX better than Google/you, they're stuck with crappier security/UX and the market should sort it out.
I've actually managed to convince a company to stop prohibiting copy-paste on logins by pointing them at the new NIST password guidelines. I don't expect this to work for every company, but if they intentionally don't change, it's okay to name and shame them for it. Whether it's a UX sin or security voodoo.