3 ms·
for backend admin, when creating usernames and passwords for new users, you dont want those saved in your own browser. pretty much the only use-case i've run i
by leeoniya 12y ago
for backend admin, when creating usernames and passwords for new users, you dont want those saved in your own browser.
pretty much the only use-case i've run into and can think of.
- pasbesoin 12y agoI've worked on use cases in both work and home environments. Remember, a few years ago, not everyone had their own computer. For large chunks of the world (demographically and geographically), this is still the case. Shared computer? You want to be applying autocomplete=off to sensitive fields. It's no guarantee, but it's one layer, assuming other layers (e.g. preventing keyloggers) are being maintained. Only, I guess, you won't have this option, any longer. At one point, I had to get one of my banks (big, "evil", you've heard of them) to apply it to their login web page. And I worked for another very big corporation that had at least in some people some pretty clueful in house developers. We applied it, as well. There were, and are, valid use cases. The setting alone won't save you, but it's one piece of a broader approach. P.S. Oh yeah, and I seem to recall nudging a domain name registrar to apply it to the credit card number field on their payments page.
- ploxiln 12y agoBrowsers already automatically disable auto-complete from form history for "password" type input elements, this "autocomplete=off" would additionally prevente password managers from working. So that's what this change does: password managers will work, but password input fields still don't actually auto-complete from form history. You should still be able to use autocomplete=off for non-password fields, like credit card.
- pasbesoin 12y agoThank you for the clarification. I should have read through everything.
- pbhjpbhj 12y agoDoesn't private tabs solve that?