6 ms·

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

deleted 5y ago

[deleted]

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