5 ms·

This is not really a Safari-only thing. All password managers that I have used in the past had some kind of heuristic to decide whether a field should be auto-f

This is not really a Safari-only thing. All password managers that I have used in the past had some kind of heuristic to decide whether a field should be auto-filled or not. Here is a nice explanation by a (former?) 1Password employee (https://1password.community/discussion/94198/autocomplete-off-for-1pass-suggested-fields https://1password.community/discussion/94198/autocomplete-of...). To me as a web developer (among other things :D) this is quite annoying because password managers often hijack our forms when they decide that the label (or id or classname etc.) sounds suspiciously usernamely, passwordly or credit cardly.

irae 5y ago
As well they should. I sometimes hate the password managers too as a web developer. I am also a 1Password user, and I hate sites that block clipboard, block pasting, block right click, basically block any kind of way I have to type even my username, not to mention annoying full size on screen keyboards that can only be used with the mouse. I don't care about the reason they have to be so intrusive in UX, probably some malware fight and/or prevention. The fact is that if I am going to use 1Password or other password managers per site, with 25 characters long passwords with symbols and numbers, I want to be able to somehow fill that in without typing each letter. Some sites don't care about this use cases as they are trying to cover the asses of non-tech-savvy users. They must protect the password123 crowd, right? So password managers need to fight back, unfortunately.
- diegoperini 5y ago
  Automatic field detection is fine and good UX for password managers. What is bad is auto-fill without user action.
- xzel 5y ago
  I have/wrote a one line auto hot key script for typing in strings in fields that don’t allow paste. Originally intended for a tax program that doesn’t allow pasting banking passwords. The pain of making a mistake and have to enter a 30+ character password over and over still haunts me. Also, if you have a problem contact their customer support. I had a tweet get a few hundred likes about a non pastable field for a transportation website and they actually changed it later that week!
  - throwawayboise 5y ago
    What is the rationale for disabling paste on passwords, account numbers, other "sensitive" data? The absolute worst are fields where paste is disabled, and the characters are also echoed as "*" so you can't even see what you are typing. I saw this with SSNs when I submitted some tax forms on my state's website recently. The only argument I can think of for disabling paste (and I think it's pretty weak) is on a form to set a new password, where you need to input the password twice (and the form validates that they match) you might want to make the user actually type the same password twice, rather than let them copy/paste the first entry into the second field.
    - kempbellt 5y ago
      When I used to have a multi-monitor dev environment, I did accidentally paste a password into Slack (left screen) and not Chrome (right screen). Immediately deleted the chat message and had to cycle the password. This is the only issue I've ever had with copy/pasting passwords, it only happened once, and the site preventing me from pasting would have done nothing to prevent it. I don't understand the rationale either. Also, double validating passwords should allow for pasting to promote the use of managers. Forcing users to type them in creates more possibility for mistakes - you can type the same wrong password twice... Muscle memory is funny that way.
      - jakelazaroff 5y ago
        I’ve also accidentally typed a password into a chat app when I meant to type it into a browser. Just zoned out instead of looking at the password field where stars should have been showing up. Ultimately, people are just going to make mistakes!
      - oneeyedpigeon 5y ago
        If anything, pasting a password into a password field should be explicitly allowed, whilst pasting it anywhere else should either be forbidden or, possibly, prompt for confirmation first.
      - robocat 5y ago
- 8ytecoder 5y ago
  Not to mention the 2-step flow that’s so predominant now.
- deleted 5y ago
  [deleted]
- sandgiant 5y ago
  NIST actually recommends allowing users to paste exactly for this reason: > Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets. https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html I use the "Don't Fuck With Paste" add on for Chrome/Firefox, which mostly works well.
  - rav 5y ago
    Here's a bookmarklet version of "Don't mess with paste" for those who don't want to install the add-on: javascript:void(document.documentElement.addEventListener( 'copy',e=>e.stopPropagation(),true), document.documentElement.addEventListener( 'paste',e=>e.stopPropagation(),true))
- tankenmate 5y ago
  For exactly this reason I wrote a script that reads from the clipboard cut buffer and inserts the keys one at a time into the keyboard input stream; voilà, pasting that side steps asinine browser page restrictions.
blacktriangle 5y ago
Definetly an terrible feature as a web developer. I stopped counting how many bug reports I've had to can because the users thought we were the ones auto populating their fields with crap.
ericwood 5y ago
It's such a pain. I've had all kinds of oddities when using type="password" for private data. A lot of password managers would see that and assume a password and fill in the email in whatever the form element before it was. You can't tell them not to, either! I've also had to scrub data when users somehow put their credit card numbers into public fields. Still no explanation on that one, but it happened with enough users that our only guess was browser auto-fill gone awry and people blindly hitting submit.
xvolter 5y ago
This has been annoying for me. I build a healthcare EMR software, and the browser trying to autofill the employee's information into every patient field is often a problem. By accident we end up with patient's phone numbers, addresses, and emails being set to employee's information. Since its software, I don't have control over those employees, but we have had to put in recommendations to disable autofill in browsers being used to cut it down. We've spent countless developer hours trying to work around password managers. I agree that sites shouldn't attempt to disable password management for login and sign up pages, but it's annoying how often these password managers do the wrong thing and break the user experience for pages… like Safari is doing for livewire-ui/spotlight.
- lostlogin 5y ago
  I’ve made this error and will admit to being utterly baffled the first time I hit it. As an administrator was trying to work though a users problem. But their account details all matches mine. It took an embarrassing amount of time for it to click.
Brian_K_White 5y ago
Fine if there was a field there. This is creating a field where there was none. And it's the browser itself rather than an electively installed plugin where you asked for it. It's outrageous. By rights, modifying the content this way should be seen as utterly outrageous by both site authers and users, not just some quirky glitch that it's not smart enough and doing the modification in the wrong place sometimes and will shortly be improved to false-positive less often.

irae 5y ago

As well they should. I sometimes hate the password managers too as a web developer. I am also a 1Password user, and I hate sites that block clipboard, block pasting, block right click, basically block any kind of way I have to type even my username, not to mention annoying full size on screen keyboards that can only be used with the mouse. I don't care about the reason they have to be so intrusive in UX, probably some malware fight and/or prevention. The fact is that if I am going to use 1Password or other password managers per site, with 25 characters long passwords with symbols and numbers, I want to be able to somehow fill that in without typing each letter. Some sites don't care about this use cases as they are trying to cover the asses of non-tech-savvy users. They must protect the password123 crowd, right? So password managers need to fight back, unfortunately.

diegoperini 5y ago
Automatic field detection is fine and good UX for password managers. What is bad is auto-fill without user action.
xzel 5y ago
I have/wrote a one line auto hot key script for typing in strings in fields that don’t allow paste. Originally intended for a tax program that doesn’t allow pasting banking passwords. The pain of making a mistake and have to enter a 30+ character password over and over still haunts me. Also, if you have a problem contact their customer support. I had a tweet get a few hundred likes about a non pastable field for a transportation website and they actually changed it later that week!
- throwawayboise 5y ago
  What is the rationale for disabling paste on passwords, account numbers, other "sensitive" data? The absolute worst are fields where paste is disabled, and the characters are also echoed as "*" so you can't even see what you are typing. I saw this with SSNs when I submitted some tax forms on my state's website recently. The only argument I can think of for disabling paste (and I think it's pretty weak) is on a form to set a new password, where you need to input the password twice (and the form validates that they match) you might want to make the user actually type the same password twice, rather than let them copy/paste the first entry into the second field.
  - kempbellt 5y ago
    When I used to have a multi-monitor dev environment, I did accidentally paste a password into Slack (left screen) and not Chrome (right screen). Immediately deleted the chat message and had to cycle the password. This is the only issue I've ever had with copy/pasting passwords, it only happened once, and the site preventing me from pasting would have done nothing to prevent it. I don't understand the rationale either. Also, double validating passwords should allow for pasting to promote the use of managers. Forcing users to type them in creates more possibility for mistakes - you can type the same wrong password twice... Muscle memory is funny that way.
    - jakelazaroff 5y ago
      I’ve also accidentally typed a password into a chat app when I meant to type it into a browser. Just zoned out instead of looking at the password field where stars should have been showing up. Ultimately, people are just going to make mistakes!
    - oneeyedpigeon 5y ago
      If anything, pasting a password into a password field should be explicitly allowed, whilst pasting it anywhere else should either be forbidden or, possibly, prompt for confirmation first.
    - robocat 5y ago
8ytecoder 5y ago
Not to mention the 2-step flow that’s so predominant now.
deleted 5y ago
[deleted]
sandgiant 5y ago
NIST actually recommends allowing users to paste exactly for this reason: > Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets. https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html I use the "Don't Fuck With Paste" add on for Chrome/Firefox, which mostly works well.
- rav 5y ago
  Here's a bookmarklet version of "Don't mess with paste" for those who don't want to install the add-on: javascript:void(document.documentElement.addEventListener( 'copy',e=>e.stopPropagation(),true), document.documentElement.addEventListener( 'paste',e=>e.stopPropagation(),true))
tankenmate 5y ago
For exactly this reason I wrote a script that reads from the clipboard cut buffer and inserts the keys one at a time into the keyboard input stream; voilà, pasting that side steps asinine browser page restrictions.

blacktriangle 5y ago

Definetly an terrible feature as a web developer. I stopped counting how many bug reports I've had to can because the users thought we were the ones auto populating their fields with crap.

ericwood 5y ago

It's such a pain. I've had all kinds of oddities when using type="password" for private data. A lot of password managers would see that and assume a password and fill in the email in whatever the form element before it was. You can't tell them not to, either! I've also had to scrub data when users somehow put their credit card numbers into public fields. Still no explanation on that one, but it happened with enough users that our only guess was browser auto-fill gone awry and people blindly hitting submit.

xvolter 5y ago

This has been annoying for me. I build a healthcare EMR software, and the browser trying to autofill the employee's information into every patient field is often a problem. By accident we end up with patient's phone numbers, addresses, and emails being set to employee's information. Since its software, I don't have control over those employees, but we have had to put in recommendations to disable autofill in browsers being used to cut it down. We've spent countless developer hours trying to work around password managers. I agree that sites shouldn't attempt to disable password management for login and sign up pages, but it's annoying how often these password managers do the wrong thing and break the user experience for pages… like Safari is doing for livewire-ui/spotlight.

lostlogin 5y ago
I’ve made this error and will admit to being utterly baffled the first time I hit it. As an administrator was trying to work though a users problem. But their account details all matches mine. It took an embarrassing amount of time for it to click.

Brian_K_White 5y ago

Fine if there was a field there. This is creating a field where there was none. And it's the browser itself rather than an electively installed plugin where you asked for it. It's outrageous. By rights, modifying the content this way should be seen as utterly outrageous by both site authers and users, not just some quirky glitch that it's not smart enough and doing the modification in the wrong place sometimes and will shortly be improved to false-positive less often.