I'm all for empowering browsers to override abusive behaviour from websites, but using bad defaults and breaking innocent websites as a result is not the solution.
The browser is the agent of the user.
Come work tech support for a company/product with a web-based form that has a password field in it (like a CRM or other administrative system). Now explain to users why we can't stop their browser filling in their password in the field that's asking for the other user's password.
I've had situations where I'm configuring a VPN connection on the web interface for a router... then spending 10 minutes head-scratching why the hell it's giving me an invalid PSK message. Oh, because Chrome filled my password into the goddamn wrong field when it wasn't asked to.
Of course that would be a terrible idea for a number of other reasons, but if enough people specifically avoid more recent versions of Chrome for this reason, maybe Google will finally do what's actually best for users and make this behaviour configurable.
No, you can't do that.
Instead you have to tell them to stop saving passwords in the browser.
What? Why would the other user ever provide their password to this user?
So the helpful support person can now go "Your password is now 'foobar' and you will be asked to pick a new one when you login."
A one time password is nothing but a token - maybe not ideally named.
The employee should of course change their password and that should be enforced policy, the admin shouldn't know user passwords.
Tokens work too but it's a bit of an overhead, especially in smaller SMB where the admin is probably just across the corridor or atleast in the same building.
If it's something like a password, it should be treated like a password. Why shouldn't you use type=password for that?
>The browser is the agent of the user.
Here I support you, but do you remember that Googlers pressed assertively for hijackable right click, no opt-out history spoofing, and many many many other supremely user hostile features in W3C standards.
Out of all broken web novelties, they prefer to unilaterally break ones coming from outside:
Declarative right click menu from Mozilla was killed by Chrome.
Declarative SMIL animations, same story
They added support for HTTP pipelining and killed it just to force people to migrate to their protocol
They had working drag and drop on mobile, yet they killed it because "iphone's dnd is broken, so we made ours broke too"
They banned few people from bugzilla from insisting on turning off vibrator API from mobile Chrome, yet the moment people started using it for bot detection, they killed it in iframes (denying its use as a hard proof of clickfraud for ad companies)
I always told clients that if you have to choose in between having feature A broken on iphone or having it broken every other browser, to chose to break iPhone. Now, I don't know what is right to say there, probably something like "you need to settle on a variant where stuff is broken in a consistent manner across all browser"
In principle, I agree with you. But in reality, the iPhone market is very valuable.
If it was protecting your interests, it would be a toggleable setting that defaults to normalized behavior.
But you can always install (or develop) another browser that might do this job better for you.
> If it was protecting your interests, it would be a toggleable setting that defaults to normalized behavior.
The problem with this view is that the vast majority of end users do not want, and in fact will never know about or use a new setting, and so the when doesn't move forward. This is the opt-in problem that Google is talking about. In politics, an analogy is called public choice theory.
Google could even make an extension for this to allow users to gather and share a list of sites that behave in a user unfriendly way.
But of course, it was much easier to fuck up half of the Web.
Public choice and mandates are great for things that require cooperation and agreement against race to the bottom (like tax havens), not against autocomplete fucking off.
My guess is that many medical computers aren't well administrated and leave autofill on, which can easily cause accidental HIPAA violations.
Or that's why then the SysAdmin should disable the password manager.
It's not up to the website.
If you have an internal site, you already control the browser, then why do you want to fight the browser from the inside instead of from the outside? :o
There was a form where administrator can change certain details of another user profile, and if e-mail (or name) field was empty on a profile, then chrome would autofill it with administrator's e-mail, which can result in unwanted / corrupted data.
Some replies in this thread suggest configuring chrome differently in organizations where this is important to avoid, but when you are SaaS vendor, your users will inevitably blame you for Chrome's behavior.
How?
What do you imagine?
* Turn on anyway * Leave disabled for this form
= Remember my choice for this website
I'm a user.
I want that. I'm probably not "a majority" but I fail to see how being assimilated to the majority without my consent, without even knowing it is happening, is "protecting my interests"
What would you think of a restaurant that charges you 50% of the bill as tip because "the majority of the customers does that"?
I don't know about you but when I go to the restaurant, I can't change the price of the items. If they set the tip for you, that's pretty much setting the price, isn't it?
I forgot HN is mostly an american place.
Tip in most Europe is voluntary
We don't force people to tip
Now, Google shoves on you their preference (which is a coin-toss to align or not) and you shout that this is protecting your freedom of choice.
Chrome cannot decide on a whim that old websites should be broken. It is not how the web moves forward. Take for example Firefox that kept breaking extensions with every update, now they have few compatible extensions.
that's a misbehaviour of the browser, not the developers
The browsers were designed for viewing a single page at time
popup blocking is fixing a browsers misbehaviour, as much as fixing a car that when you hit the brake accelerates
You ship an experience like that, you end up not only breaking old websites but shift the emphasis on regularly updated websites that work on mobile. That was the intent! But it is not the web we know and love.
It's default on a lot of Android phones, but far from the only one available. I use Firefox on mine. Opting to use a non-Chrome browser on an Android phone is about as technical as using a non-Microsoft browser under Windows.
This is a gross oversimplifcation
They also cannot opt-in if you don't have electricity in your house or don't own a computer
DOH!
This is not a real argument
A real argument is obsolescence
Of course there's a point when older versions are not supported anymore
Here we are talking about future versions breaking compatibility, without a shared consent, without a deprecation roadmap, that need to be supported, in a Chrome specific way, making Chrome the new IE for no real benefits to the user and a vendor lock-in by Google
When they users will try a different browser, for whatever reason, they will experience a different web, that for the majority of them being non techy will look like a broken web
because that's what I want it to do.
I'm all for giving users the power to ignore the standard and disable certain features, but forcing it on users without making it configurable sounds like a really bad idea.
A better idea would be to show that yellow bar at the top explaining briefly what the site does and asking whether the user wants to allow that. That keeps the user informed and empowered, rather than subject to the whims of the website and browser makers.
If that's true, the browser should ask me and not assume what i want it to do.
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.
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.
You can also copy text with right-click -> Inspect Element -> copy($0.innerText). Although you'd use $0.value for an input or textarea.