251–260 of 278 posts
It's like walking over a railroad bridge that's falling apart.
The deeper problem here is that credit card numbers are obsolete. Websites should be using Apple Pay and similar stored payment info APIs that don't go through an unnecessary error-prone user-facing interface. (Yes, Apple etc. are oligopolists, but so are Visa/MasterCard)
"Websites should be using Apple Pay and similar stored payment info APIs" I think the problem is precisely that very last character, the "s". How many such APIs should "websites" be using?
Other commenters here have bemoaned the need for these kind of heuristics in dealing with compat with bad HTML form implementations, but there's an easy fix to that: origin-based compat lists. Browsers do this for quirksmode/website compat fixes: they apply heuristics to a specifically tested list of sites. And browsers need to work with a much larger set of webpages than 1Password, so there's no reason 1Password couldn't do the same.
There isn't really any good excuse for applying heuristics blindly by default to a wide range of websites you have not tested those heuristics against. There might be an argument if it increased overall compat with the web IF these weren't highly sensitive pages (1Password saves credit card details!), but in this case there isn't really any excuse. The cost of achieving "blind" compat with smaller sites is too high in this case.
This is an example of a common antipattern in software: some piece of software fails to correctly implement something (here, modern HTML autocomplete="cc-exp-year"), and another piece of software goes through all kinds of contortions to work with incorrect or incomplete implementations with the result that it now behaves undesirably with a third piece of software. Specifically, 1Password has to do complicated guesses…
This seems to be particularly common in the web development world, even in the fundamental tech upon which the web is built. Missing the closing tags in your HTML? The browser will just guess where it should be for you. Missing a semicolon in your Javascript? The interpreter will just guess where it should be for you. Invalid CSS? The browser will just silently ignore it. Illegal comments in your JSON? Most parsers will just assume you meant to ignore those lines.
I'm happy to use for storing my passwords and maybe logging in but that's about it.
I wish sites would test their forms with popular password management systems. This kind of thing happens all too often (thought perhaps not with such a high cost). Why not make it easy for people who auto-fill with these programs -- don't fight them. (And I won't get into sites that won't let you paste passwords into their forms.)
I’d settle for login forms that don’t hide the password box until you enter your username/email. I don’t see how they benefit real users in any way, and my password manager can’t understand it, requiring manual copy/paste entry
Earlier quoted context omitted.
It looks like paste and it's almost the same from the user perspective, but the data never makes it to the clipboard, where it would be available to every running application.
From what I can see, KeePass does use the clipboard. [0] [0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/N...
This is an example of a common antipattern in software: some piece of software fails to correctly implement something (here, modern HTML autocomplete="cc-exp-year"), and another piece of software goes through all kinds of contortions to work with incorrect or incomplete implementations with the result that it now behaves undesirably with a third piece of software. Specifically, 1Password has to do complicated guesses…
Now in this situation, it looks like Substack's UI is to blame. The secret form field appears to be heavily modified from its original form state, probably masking the blue background that 1Password attempted to give it.
1Password is in a difficult situation here. If the autofill doesn't work (because the developer of the website they are filling, uses non-standard naming), then users will blame 1Password for "not working", not their browser or the website developer. 1Password therefore has to make it work with as many forms as possible around the web, most of which are built by lazy developers trying to throw up a website during a hackathon, or from a developer that learned to code from a 1 hour youtube video. It's a tall order, from their perspective, to try to make this work with as many forms as possible, while having the fewest (ideally none) false positives.
The one thing I can recommend for anyone who uses any password manager, is that before you click submit on a form that you used auto-fill for, you always look over the entire form again. Now in OP's case, I could see how they could have easily missed the extra amount (again, Bad UI substack), but this is general rule that anyone with a password manager should follow. Double check everything before you submit.