So the question becomes what's less bad: for website developers to break their own site, or for Chrome to break other people's site.
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.
Chrome is a program that I run on my computer. It protects my interests, not the interests of random crappy website developers doing horrible things like hijacking clipboard events. I'm all for the defaults being whatever is best for me.
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.
I suppose you could tell them to go back to a previous version of the browser.
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.
That doesn't sound like a safe way of resetting passwords. You should supply them a token they can use to set their own password. Your employees should not know your users passwords.
Exactly that. I use this feature as an Admin relatively often in Adobe Analytics. I never am able to know the "real" password a user provides on first login after reset.
A one time password is nothing but a token - maybe not ideally named.
In a corporation, this is totally okay as long as the reset password is safe or the account is locked from external access until the password has been changed.
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.
You're creating a secret token. Both the administrator and the browser should be made aware of this. The administrator, so that they don't send it to the user via an unsecure method (Tweet it publicly), the browser so that it shows warnings if the site is somehow served without ssl or is compromised.
If it's something like a password, it should be treated like a password. Why shouldn't you use type=password for that?
>Chrome is a program that I run on my computer. It protects my interests, not the interests of random crappy website developers doing horrible things like hijacking clipboard events. I'm all for the defaults being whatever is best for me.
>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"
> It's not protecting your interests, it's protecting Google's interests.
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.
Users don't use thousands of sites. If a site misbehaves and users want autofill on it, they should be able to override autocomplete=off for that site.
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.
I have a site that deals with HIPPA protected information. I absolutely don’t want autofill, especially for sign in information. Chrome makes that impossible and just ignores the code.
Could you explain the downside of allowing auto-fill for sign-in information here? I understand that security is a concern, but I don't see how allowing a password manager to handle sign-ins would be harmful.
In a medical setting, most computers are public. Sharing passwords is a HIPAA violation, because HIPAA requires a complete, accurate log of everyone who has looked at or modified a medical record.
My guess is that many medical computers aren't well administrated and leave autofill on, which can easily cause accidental HIPAA violations.
Disabling autofill seems like the wrong way to handle the problem, though. Autofill does not necessarily mean that passwords are being shared; it just means that the user isn't typing them in. Strong policies on the machines in question and ensuring that users aren't sharing each others environments seems like a considerably more complete solution to me. This can be facilitated by tools like https://www.imprivata.com/single-sign-on-sso. Ironically enough, disabling autofill may actually prevent this tool from providing some of the benefits it's intended to provide.
While I agree that autofill on its own is not a complete solution to GP's scenario, it's certainly a potential point-of-failure, and I understand their need to eliminate as much risk as possible. While the most significant aspect to be improved is the security habits of the clients themselves, that doesn't mean that GP and their company should be prevented from doing what little they can just because Google wanted things to work their way.
That's why there are profiles. Even in Chrome. But too in Windows.
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
I can't remember exact scenarios that triggered it, but I've seen situations where Chrome autofills data other than sign-in passwords as well (also ignoring autocomplete=off).
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.
With the same yellow bar at the top that they use for other issues. Tell them what the site is doing and ask whether they want to allow or block that, and whether to do that for all sites or only this one.
IMO, breaking an established API with no reliable way to work around it is very bad. I have been bitten by this, and only now understand why. I will probably switch to Firefox.
> The problem with this view is that the vast majority of end users do not want
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"?
> 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 don't really use that auto filling thing that much but the few time I did, Chrome asked me if I wanted to use it on that website. Isn't that what you consider a toggleable setting? I chose to use autofill my user account information on that website.
Firefox would have given you an option. Which someone would have made an extension to control it for each site. In fact, that is exactly what happens there.
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.
Adblock is "breaking websites". If a website is doing something crappy, I'd prefer to not have that crappy thing happen than experience the developer's true intent.
Adblock is opt-in. If the browser misbehaves because of an extension, the browser nor website is to be blamed.
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.
it's a little reductio ad absurdum but what about defaulting to popup blocking? blink? marquee?
It's not the same thing but maybe worth considering when defending web author's intent being ignored.
I believe Chrome on mobile is the default (only?) browser. So it is opt-out, and a very painful opt-out that requires technical knowledge.
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.
> I believe Chrome on mobile is the default (only?) browser.
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.
They also can't opt-in to adblock or noscript or me choosing to run Netscape version 4. Developers fundamentally do not get a say on what I choose to run on my system; at best the only control they have is saying "nope we aren't even going to try to run on whatever you've got" but even that isn't a guarantee.
> They also can't opt-in to adblock or noscript or me choosing to run Netscape version 4.
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
But is it best for you when sites you use don't work properly because the latest update of your browser breaks the standard?
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.
You mention website developers and Chrome developers, but spare a thought for users as well. If I want to use a password manager and the website developer decided to stop me from doing that, I appreciate Chrome helping me out.
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.