16 ms·

Related, there is a "bug" in chrome that disabled autocomplete="off" on input elements, marked as won't fix https://bugs.chromium.org/p/chromium/issues/detail?

• SigmundA 5y ago
  I can make my web site/app extremely hard to use in all sorts of bad ways, the developer being able to disable autocomplete should be the least of anyones worries. The other side is the situation we have now, autocomplete doing the wrong thing all over the place with no way to stop it. Stomping on my apps specific database driven autocomplete really hurts the user experience. Also autofilling fields without the user noticing and entering wrong data into forms. What a mess.
• yvoschaap 5y ago
  Yes. The Chrome devs refuse to accept there are viable cases for not allowing autocomplete.
  • deleted 5y ago
    [deleted]
  • vincnetas 5y ago
    It's not up to Chrome devs to accept or deny viable use cases. As someone from comments mentions, it's in the spec, and chrome devs should not deviate from that irrelevant if what they think is accepted or not accepted use case. Or they should go and push for spec change.
    • eru 5y ago
      Why? The spec ain't God given.
      • irjustin 5y ago
        That's how we ended up with decades of Internet Explorer.
      • monsieurbanana 5y ago
        > Or they should go and push for spec change
        • thaumasiotes 5y ago
          That attitude basically endorses the idea that the spec is God-given. There's nothing so important about getting the spec changed before you start ignoring it.
          • monsieurbanana 5y ago
            > That attitude basically endorses the idea that the spec is God-given That's a tad over-dramatic. And context matters, surely I don't need to remind you why Google is spending so much money on Chrome? Having a company control 70% of the browser market is bad enough, we don't need people telling them to go ahead and ignore specs, remember that they don't make those decisions out of goodwill for us.
    • bipson 5y ago
      I guess there are just too many pages that break autocomplete, e.g. for username/password as a "security feature". I encountered quite a few myself and was very annoyed. I guess devs took the "usability" side of the question. EDIT: phrasing
      • Aeolun 5y ago
        But it’s not useable at all. A form without autocomplete is perfectly useable. A form with autocomplete where it’s not wanted is an absolute hindrance.
        • lupire 5y ago
          A non autocomplete password field is an absolute hindrance.
    • Cederfjard 5y ago
      The spec is driven by browser implementations rather than the other way around, is it not?
      • vincnetas 5y ago
        It should not be so. Or else Spec would just look like "do as chrome does"
    • thaumasiotes 5y ago
      I feel like repeating an old comment of mine ( https://news.ycombinator.com/item?id=27231194 https://news.ycombinator.com/item?id=27231194 ) here: > Conforming to the spec is not a virtue. > When the spec is malicious, conforming to the spec is malicious behavior. > I'm comfortable calling it a bug in the spec. `a << 40` needs to have 0 in the lowest 40 bits. It does not need to have random values in bits 8-31. > This behavior is documented, but that doesn't make things better, it makes them worse. > But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec. Implementing a bad idea doesn't become a good idea just because someone once wrote that it was.
      • vincnetas 5y ago
        I think predictability is important. And specs define what you can expect. System with undefined/unpredictable behaviour does complicate a life in long run even if at the moment it looks more convenient.
        • wildrhythms 5y ago
          If the topic is predictability, I would expect banks to use the spec to disable only predictably non-autofillable fields with the user's best experience in mind. Disabling autocomplete on username and password fields in the name of some nebulous 'security' goal is neither predictable, nor in line with most user's expectation of usability; it also doesn't make the system more secure. I could argue that these sites themselves aren't following the spec by disabling the fields. Remember, there are autocomplete values to accommodate "current-password"[1]. If your bank has a field representing a password without that attribute, do you think that's following the spec? [1] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete-current-password https://html.spec.whatwg.org/multipage/form-control-infrastr...
    • benhurmarcel 5y ago
      > It's not up to Chrome devs Well apparently it is, because they're doing it.
  • mjthompson 5y ago
    I'm sure there are valid reasons. Unfortunately, many sites disable it without a good reason, and in those cases, I am glad Chrome hinders their misguided efforts. Many banks, for instance, think password managers are bad and disable it. Chrome preventing them doing so is a good thing.
    • andylynch 5y ago
      They can be persuaded to change these policies. Asking why they aren’t following the current NIST (US) or NCSC (GB) password guidelines is helpful.
      • Deestan 5y ago
        I can't persuade my bank to revisit their security decisions in any reasonable time frame or within any reasonable amount of effort.
    • Aeolun 5y ago
      I do not. Ultimately it is up to the website owners, it shouldn’t be ignored by the browser if it’s part of the spec.
      • noja 5y ago
        Why do you think it is up to website owners, and not website users?
        • jerf 5y ago
          You can strengthen that... it is up to the users, as a matter of practical fact. I've right-clicked -> edit attribute -> autocomplete=true more than once. I've cleared the right-click handlers and keypress handlers that were blocking paste, or run $0.setAttribute("value", "paste your password here on the console where they can't stop you") (after you select the element in the inspector). Browsers as they stand now are not capable of truly blocking autocomplete, or pasting into a field with an input box. If they aren't implementing their own text field with a canvas and taking keystrokes themselves they aren't blocking paste anyhow. (And if they do that I can still tampermonkey or something my way into a "paste".)
  • orangepanda 5y ago
    Are there any viable cases?
    • Lex-2008 5y ago
      OTP one-time-password fields
      • orangepanda 5y ago
        autocomplete="one-time-code" Any others?
        • Lex-2008 5y ago
          good point! But as soon as browsers stop autocompleting fields marked with autocomplete="one-time-code", won't website developers start marking _all_ input fields with this tag? After all, why do people put autocomplete="off" on input fields anyway?
          • scrollaway 5y ago
            autocomplete="one-time-code" causes a different type of autocomplete behaviour, it doesn't disable it. Specifically for example it will suggest a one time code you received by sms if one was recently sent (on mobile at least).
        • emilfihlman 5y ago
          Chrome recommends wrong passwords, passwords from wrong subdomains, and passwords for pages that will never accept custom passwords. It's broken as fuck.
        • rypskar 5y ago
          Admin page where you create users for other persons. Not cool when browsers try to add your password as password for all the users you create
          • 5y ago
• knorthfield 5y ago
  Safari also completely ignores autocomplete="off" when it thinks something is a username or password field. Even when, as a dev, I know it definitely isn't.
  • Lex-2008 5y ago
    I assume you're not in Apple Store team, then. Because they do put autocomplete="off" on login form, username, and password fields. At least for me: https://imgur.com/a/Ygb371g https://imgur.com/a/Ygb371g UPDATE: please help me write a sarcastic comment about Apple Store team putting autocomplete="off" there, and Apple Safari browser ignoring it.
    • saagarjha 5y ago
      I honestly believe that some of the people that work on apple.com don't test the website in Safari.
• plasma 5y ago
  tip: Using autocomplete="new-password" at least fixes the change password forms (so it wont pre-fill the password there). See https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#preventing_autofilling_with_autocompletenew-password https://developer.mozilla.org/en-US/docs/Web/Security/Securi...
• airza 5y ago
  The nuance here is that brain-damaged appsec pentesters reported this as a vulnerability for years, and so tons of websites followed that advice and dutifully disabled the functionality. But autocomplete has advantages: it lets users easily specify long, random, per-site passwords without ever having to worry about that. And when they can't do that, a pretty large percentage of them just give up and write the password down somewhere. In the end, i find a lot of chrome's decision to implement spec-breaking behavior awful in the context of having a website that works forever (Looking at you, samesite). But this behavior rarely breaks functionality and on the whole makes the web a lot more secure.
  • callamdelaney 5y ago
    I'd go a step further and say if my password manager doesn't play nice with a website, I'm less likely to use that website.
  • izacus 5y ago
    Oh man, enterprise "security" firms used by banks and other old behemoths are a cancer for users. If you want your website to actively abuse users (especially one with special needs and pretty much anyone that doesn't fit into an "made up average person mold") get those people on board and listen to the dumb things they say. I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!".
    • thaumasiotes 5y ago
      > I still can't believe that whole business managed to interpret 2FA for whole EU as "you MUST use SMS for 2FA!". Weeeeeelll... I'm familiar with two (2) common kinds of "2FA" implementations. TOTP and SMS. Of those two, only SMS is actually a second factor, albeit not a particularly secure one. TOTP is fundamentally a password, and two passwords are no different than one password.
      • wffurr 5y ago
        Doesn’t answering a TOTP challenge prove that you “have” the HMAC shared key that seeds the code generator?
• justusthane 5y ago
  I had a form with an input field named “accessibility-accommodations”. Chrome was seeing the “cc” and was assuming it was a credit card field, and thus prompting to autofill a credit card number. Occasionally a customer didn’t notice and sent us their credit card number via the form. The only way I was able to fix it was renaming the field.
• lucideer 5y ago
  Worth mentioning that Firefox & Safari also have the same "bug", and IE has no autocomplete support whatsoever (making the bug moot). The recommended alternative solution posted by a Googler in the above Chromium thread is to specify: autocomplete="semantic-description-of-field" And the MDN docs recommend specifically doing: autocomplete="new-password"
• heinrichhartman 5y ago
  I tend to side with Chrome here. IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not. Now, there is a valid question on how the user should be able to configure the AC behavior, and how the website may help inform this configuration, but the decision should be with the user. The website should not have the final say. So I would see this as more of a shortcoming of the HTML Spec.
  • rhdunn 5y ago
    The problem is when the web browser gets it wrong and decides to show autocomplete for an unrelated field, or a field that is not a login/enter password page. Some examples I've had to deal with: 1. A "name" field on a dialog for creating values in a controlled vocabulary (e.g. genres in fiction) -- Chrome thinks this is a username field so brings up a user autocomplete. I guess it thinks that "Jane Smith" is a valid label! 2. Editing user details (username, full name, email, etc.) -- Firefox thinks the email is a good place to autocomplete the password. With these, I've had to employ several workarounds to tell the web browsers that these are not login forms, so please don't autocomplete them as such, all because they ignore `autocomplete="off"`. I've got these working now, but if Chrome/Firefox decide to ignore the markup because of sites misusing them (like they've done before), I'll need to work out how to avoid this again.
    • reflectiv 5y ago
      I write web apps for a living and literally ran into this last week...and was promptly annoyed when I realized chrome was ignoring the attribute to disable it.
    • heinrichhartman 5y ago
      I understand the pain, and the need to somehow work around this. However, conceptually the right place to fix/configure this is the browser. So the correct long-term approach is to open a bug/feature request and get this properly addressed. Everything else is, well, -- a workaround. (Again: I understand that the correct approach can take years, and it is unclear if it will succeed at all - so it may be impractical.)
• cblconfederate 5y ago
  At least safari lets you force autocomplete by adding "Welcome back"
• rascul 5y ago
  Where do you see it marked as won't fix? Status is assigned and open according the the information on the left side.
• quotemstr 5y ago
  The Chrome people are right. The browser is a user agent.
  • slver 5y ago
    You should sit down and read the reports and realize users are harmed by this.
    • quotemstr 5y ago
      Are they? I think users are harmed by overzealous webmasters breaking a browser security feature. Sorry, but the people who disabled autocomplete unnecessary ruined that control for everyone.
      • slver 5y ago
        I thought I told you to sit down and read the reports. Why are you so insistent on speculating based on no information instead of actually reading the specific cases described there? One app is a kiosk that keeps saving people's passwords and autofilling them for the next user. Another app has its own address dropdown but Chrome hides it and keeps autofilling the same address over and over making the app useless. A third app is for admins creating users, and it keeps autofilling the admin's own details so that info keeps accidentally leaking into the user accounts. Another app is for applying for a bank service with very strict requirements, names get autofilled not following the requirement, users think the autofiller is perfect, then they get rejected and need to go to the branch physically to fix it. Don't be a know-it-all. Go actually learn something. Having a browser second-guess its own markup after this markup has already been established to work a certain way is really dangerous. We're talking about the web, the most popular platform in the world, and Chrome is the most popular browser. This is irresponsible handling of that burden from Google to make changes like this on a whim.
        • quotemstr 5y ago
          > Don't be a know-it-all. Go actually learn something. Try again, but with less personal invective. You're listing a few bad things that happen because Chrome ignores autocomplete="off", but you're not listing all the bad things that would happen if Chrome didn't ignore autocomplete="off" --- namely, users using weaker passwords and getting compromised more. Sorry, all the things you mention sound like minor annoyances to me. It's much more important that websites not block secure password storage features in browsers.
• deleted 5y ago
  [deleted]