Chrome Autofill doesn't respect autocomplete=off | Hacker News Reader

Chrome Autofill doesn't respect autocomplete=off

bugs.chromium.org

Chrome does not respect autocomplete=off (2018) - https://news.ycombinator.com/item?id=26309919 - March 2021 (74 comments)

Good. I have never, not once, seen autocomplete=off where it actually made sense, except in the minds of a developer who erroneously thinks it's a good idea to block password managers.

I can imagine legitimate hypothetical use cases for it. I've just never seen a legitimate actual use case.

Edit: NIST says (in https://pages.nist.gov/800-63-FAQ/#q-b12):

> In SP 800-63B, NIST has not explicitly recommended the use of password managers, but recommends that verifiers permit the use of “paste” functionality so that the subscriber can use a password manager if desired.

I'll take their word over some rando app developer who doesn't want users to have a working 1Password setup.

Two-factor auth selecting focus and suddenly seeing a dropdown of old, worthless 6-digit numbers comes to mind.

I've never seen that in the wild.

Consider yourself lucky.

I don't recall the service, but one employer of mine had both the suggestions for the MFA token, and as an added bonus, the browser would attempt to correct the "typo" in my username.

There is `autocomplete="one-time-code"` for this.

The autocomplete attribute is very extensive.

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

hell yes. But even worse are customers that want exactly this for "security reasons".

edit: on login pages, beside those are some legitimate usecases.

This is about more than just password fields, although that is a big one.

I can give you a legitimate, actual use case where I had to develop a workaround: a page where an admin can change the password for a user. Under no circumstances would an autofill be desirable on that page, yet Chrome thinks it knows best.

Edit: I stand corrected, this approach worked for me when I was building an internal app but apparently doesn't work at other times.

Just don't give the input an "id=password" and Chrome won't throw your password into it.

It's just a label, the autofill is because it matches all the other sites where you do want Chrome to autofill your password.

Ha, how did you come up with that nonsense solution? You've obviously never actually dealt with this if you think that would work.

Yeah, Chrome can be very devious at figuring it out. I've had success using `autocomplete="new-password"` at least.

set autoFill to "new-password"

Autofill many times fill data in wrong fields, and it break UI style too.

Yeah, so weird to see so many cheer for it here. I am surprised.

For me, Chrome has countless times clobbered the context-aware autofill (address fields, countries etc.) provided by the website with their useless autofill overlays.

I would much prefer if I could all together disable Chrome's suggestions in DOM input fields. Even when it has nothing to autofill, it sometimes puts something in there to take me to autofill settings or something.

The linked issue mentions one -- data entry at a medical clinic where new users are being signed up.

And that can be managed by proper browser settings at that establishment.

Forms implementing their own autocompletion logic seem like a pretty compelling case. E.g. for a search input, it makes sense to offer suggestions based on the domain (valid values, popular searches) rather than previous inputs for the same browser.

Yes, we turn it off on the searchbox of our web page because browser's autocomplete gets in the way of our own despite being much less useful.

It's useful for <input type=password ...> fields that aren't _actually_ passwords. For instance if a UI wants to hide some secret value and then have a click-to-reveal button. autocomplete=off makes sense in these cases because otherwise the browser tries to show worthless autocomplete dropdowns and if there's any form on the page then submitting it will also prompt you to save it in the autocomplete database. Which is also annoying (and worthless).

When you're trying to deploy your app to a U.S. Department of Defense environment. This includes things like the Veterans Affairs network of hospitals, too. It's a requirement that your web-app has autocomplete disabled (I don't have the DISA STIG ID# off hand...).

I was faced with this dilemma a few years ago. IIRC, the workaround was sketchy as hell. It was something like creating a password input field with the visibility set to none (and then chrome would autofill it, but it wouldn't be visible), and then the user enters their password into a regular text box, but you style the text box with CSS so that it appears as all discs. ~It was something like that, don't recall exactly.

Browsers should be designed to best serve their users, not to cater to misguided security requirements.

This is one of my pet peeves. Browsers used to be called User Agents. But they've become increasingly user hostile. I want to be able to tell my browser what to remember. Not some random manager/developer who thinks it's insecure for me to have a form field remember my username.

This is one of the areas where browsers could really add some value. Make it easier to decide what to (not) remember. Make it easier to view and edit what's remembered. This is all a tedious pain at the moment, for no good reason I can see.

the input field to a chatroom, https://i.imgur.com/jhZj8Ur.png

>I can imagine legitimate hypothetical use cases for it. I've just never seen a legitimate actual use case.

I find it somewhat annoying that when I fill out my timecard at the end of the day autocomplete is on the hours field. I never want it to pop up my previous hours worked, that's annoying, I only want to enter the hours I worked today.

> I work on a health industry related web app. Our web app is used by health professionals on tablets that are shared between their team members. We have a form within our app that enables our customers (the health professionals) to set up new Clients (their patients).

> Autofill is a Privacy Violation here as it is retaining identity information about Clients when it MUST NOT.

Seems to make perfectly fine sense to me.

The problem is not in the autofill, it's storing the information in the first place!

Will it store things that were placed into a field with auto fill off?

AFAIK yes, caching can do so. Even if it doesn't, autofill=off doesn't require it to not store the data, just to not fill it in. Things like session resumption can still store and refill it.

The web app has no control over what information the browser is and isn't saving. Autofill can and should be disabled in the browser in that case.

I take it you've never seen Chrome's built-in autofill conflict with an extension that the user installed on purpose?

I have an app at work that has a Search box. Used to accept regex patterns for selecting a host by name or description on the inventory list below. When clicking on that search box, it pops up a list of other search terms that I've entered on other web sites, which has absolutely nothing to do with this app. And when in a zoom meeting, I really don't want others to see my previously typed-in searches.

At least this is one of the top complaints about my app that I get from the customer service folks that use it. I ended up somewhat fixing this by renaming the field, but sometimes it will still pop in something strange -- is Chrome picking up the word "Search" that appears as part of the user facing page content, even if the field ID is different?

Yes, I should have to read out and type my 30 character password from my password manager when sites use `autocomplete=off` and disable pasting on the confirm password field (at least for when I accidentally leave clipboard events on).

I use LastPass with over 600 passwords and have never had this issue...

well also most password managers disable the native autofill, i.e. 1password x disables native autofill in chrome/firefox

LastPass likely ignores autocomplete=off (like almost everything else). Therefore, you would never have an issue with autocomplete=off preventing autocomplete.

Well that is kind of my point: It doesn't make sense to complain this would break password managers if they don't even use autofill in the first place.

My works's SSO tries to block autocomplete. Before Chrome started ignoring it, a lot of people switched to Safari over the issue.

This is a low quality post; this linked bug appears to have thousands of comments, most of them are advocacy repetition, and I don’t know whether OP is trying to point out the technical workaround linked, advocating for this to be changed, or advocating against this being changed.

OP, I wish you’d written a blog post about what you see as relevant and interesting here, citing material from the bug and/or elsewhere — and then posted that to HN. (And, no, altering the post title wouldn’t help; your title is correct for the link you provided - thank you for adding Chrome!)

Why is every top-level comment equating autocomplete with the ability to paste a password? Those are two explicitly different use cases, and one should not affect the other.

I don't want my password fields autocompleting; that sounds like an absolute usability nightmare. Conversely, I don't think browsers should even be able to stop me from pasting whatever I damn well please into a password field.

As to the other sentiments expressed here and in the main issue thread, I don't really disagree with Google's stance on autocomplete in regular form fields. I only really care about being able to remove invalid autocomplete entries that I may have mistakenly entered in the past (without simply deleting every entry).

> I don't want my password fields autocompleting; that sounds like an absolute usability nightmare.

Why? The usability is really good. This feature is invaluable if you use unique random passwords for every web site. Security has to be painless in order to work. If it's not, people will go back to using the same weak password for every site.

Letting web developers tell the browser what fields it should autofill is a fine idea. Unfortunately, they decided to use this power to turn off people's password managers for bullshit "security reasons". This is why we can't have nice things.

I don't respect it, either.

It hasn't since at least 2015. And good.

https://bugs.chromium.org/p/chromium/issues/detail?id=468153...

I don't think that's a good thing. Perhaps it's better than the alternative (which is that web developers abuse the hell out of the feature), but there's been plenty of cases where autocomplete has annoyed the hell out of me.

For example, I've accidentally reset multiple system passwords on a management interface where I could set the passwords/keys for several components when Chrome helpfully started autocompleting fields.

I'd much rather see a Firefox-style nag screen that notifies the user that the application in question has disabled their ability to autocomplete. If dumb developers disable autocomplete because of backwards "security" policies, showing a message saying "this website has told Chrome to disable autocomplete. If you wish to enable it, contact the website owners" or similar would be much more preferable to me. Maybe even leave the autocomplete behaviour in, but then put it behind a setting somewhere that's off by default.

All the good use cases for autocomplete=off have been ruined by all the terrible web developers and corporate managers out there.

> Web applications developer KNOW THE CONTEXT OF THEIR USE CASE

I'll believe this when web sites stop disabling paste

Another thing browsers should not allow the page to override.

You need it for google docs, etc to intercept paste events and do the right thing from the perspective of a document editor.

But this also illustrates the fact that "useful" browser features can be trivially abused.

That's an interesting point. I could see the feature looking like:

- Allowing a page to intercept a paste.

- If the page doesn't modify the DOM in response, then override it and actually paste the content.

Still trivial to bypass.

Maybe, but it might block the common case of "well intentioned developer breaks the built-in functionality without realizing it".

Is that really a common case when paste is disabled? I can't recall ever coming across it where it wasn't obvious that it was intentional.

That may be true. Maybe instead we could have a menu like

- Copy

- Paste

- No, really, paste the darn text

There's an extension called "Don't fuck with paste" which disables intercepting paste, not sure how. You have to remember to add sites that you do want to intercept paste (mostly rich text apps) to the whitelist.

And copy. And right click. And text selection.

Firefox ignores the right click overrides if you hold down shift. I'm not sure about text selection, but there's probably a way to do that as well. I haven't found a bypass on Chrome yet, though.

As for copy, I often find that the less common copy/paste commands (ctrl/shift+insert) still work when control+c/v have been intercepted. Sometimes adding an extra key also works (ctrl+shift+c). I theorize that this is because a lot of the times copy/paste is disabled, the incompetence of the people deciding on and building in the anti feature drips all the way down to the JS implementation.

> I'm not sure about text selection, but there's probably a way to do that as well

Sure. It's usually some CSS rule that can be easily turned off. These things are still extremely annoying though. We should not have to fix people's sites.

Reply on news.ycombinator.com