Other examples are problems with lock files and file versioning (because programs tried to roll their own when the operating system didn't provide them), and the complexity of parsing "HTML soup" and emails with all kinds of bizarre invalid syntaxes.
I can't offer a general solution, but if password managers simply refused to autofill to any field other than the one with the matching standard autocomplete attribute, web developers might start doing the right thing. (Do Safari, Chrome and Edge already do this? Only they have the clout to make it happen.) The user could still fill out a text box lacking the standard autocomplete attribute by right-clicking and manually selecting the correct field. Password managers should also get cheaper because their vendors would not need armies of developers adding workarounds for popular sites.
Somehow this kind of nonsense has become culturally acceptable in the software industry. If the car industry worked this way you'd have to take your car back to the dealer once a month to be patched to take account of constantly changing fuel formulations. Standards exist for a reason.
I wrote to them pointing out the issue and apparently it was put on their backlog for the following year. I think I received an update about it a couple of years later.
But you're right, browsers would have to become picky on saved credit card auto populate to force a change.
Unlikely. The password managers would just lose users.
I've even caught myself being annoyed at 1Password when it doesn't work while the cause is obviously the website doing some stupid thing.
I wonder how 1Password works on this problem though, do they just accept the crap and keep working on their guessing magic or do they also invest in standardization?
Hopefully hardware tokens can help us get rid of passwords soon.
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.
This is a market problem. All but the last password manager to do this would go out of business, due to reduced utility vs alternatives.
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 caught this when I got the confirmation email. I called the travel website, and they said since it was within 24 hours I could just cancel the tickets for free, or if I liked I could pay an outrageous fee to the airline to change the name on the ticket. Unsurprisingly I chose the former.
So, nor harm done, but if we’d gotten to the airport and my wife couldn’t come on holiday because I didn’t have a ticket for her... could have gone badly. :P
I’m lucky that my status meant it was an automatic approval for the second visa!
I also had a similar experience yesterday, with less expensive purchases fortunately.
The default behavior of 1Password auto-fill is wrong IMO. It should only fill fields after the field that currently has the focus. Not start filling whatever is available from the top of the page.
The air carrier form was not consistent with my country's name nomenclature: First, Middle, Last instead of First (+second and third) and Last name. I filled it wrongly and had to pay $40 at the check-in counter because there was no passenger registered to my name on the flight.
Tried again with my password manager (Dashlane) a few days later and realized that I should have trusted it. Also, I know that it only fills fields after the selected one, not those before.
This will save you any future issues of having to find ways to reword a title to indicate an issue has been resolved while also allowing for a way for anyone who wants to analyse resolved problems an easy [resolved] tag to filter for.
I hope you don't mind this suggestion if it's feasible to standardise.
Edit 3 weeks later: I used that on https://news.ycombinator.com/item?id=26815768. Hopefully will continue to remember.
This seems like another reason. It's not worth it. Keep the password manager in its own app and apply the tiny extra effort of pasting the password from there.
One example is how almost every password manager including the built-in one in most browsers will assume that if there's a type="password" field, then the previous sibling field must be the username. Sometimes they'll even pick a field far away in the DOM like your chatbox input to autofill with the username.
So imagine a form like this:
Amount to transfer: <input type="number">
From account ID: <input type="text">
Confirm password: <input type="password">
<button type="submit">Submit</button>
Password managers are braindead and browsers don't give you any tools to help.
Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/multipage/form-control-infrastr...
> an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state
> New autofill field name: "username"
The intent isn't to pick a field far away in the DOM, though, so any autofill implementation doing that isn't being restrictive enough.
[0] https://git.zx2c4.com/password-store/tree/contrib/dmenu/READ...
Apple's iOS 14 uses the half-solution of notifying the user after an application has read the clipboard. But at that point the end user is already a step behind the attacker, and mitigations may no longer be possible. Nevermind that this solution is dependant on the user noticing and understanding the implications of the clipboard access notification (the novice user is likely oblivious to the security risks)
I do not see a reason to copy paste in any use case at all.
it works from a local file on disk. yes, it's more inconvenient if I am away from the computer it lives on, and I need to update a password, I have to connect the VPN to my home office, ssh to it, and run 'kpcli' (a keepass format command line program), or run keepassx in a vnc-over-ssh session.
but that hassle is worth it in my opinion.
1. It uses placeholder text instead of a label. See "Placeholders in Form Fields Are Harmful" https://www.nngroup.com/articles/form-design-placeholders/
2. It hides the fact that the "$250/year" is actually a text box. See "Long-Term Exposure to Flat Design: How the Trend Slowly Decreases User Efficiency" https://www.nngroup.com/articles/flat-design-long-exposure/
3. The app makes the text box into a button plus text box. As a button, it modifies its parent widget, the radio button. This is unexpected behavior. The app would be better to show the text box after the user selects the "Founding Member" radio button. That would make the text box subordinate to the radio button and reduce user errors. See "8 Design Guidelines for Complex Applications - 6. Reduce Clutter Without Reducing Capability" https://www.nngroup.com/articles/complex-application-design/
(And I won't get into sites that won't let you paste passwords into their forms.)
If a password manager does not work when given clear hints / type description of what is expected, then that is the fault of the password manager.
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
They’re already complex enough that it’s a disaster trying to figure anything out. You say it wouldn’t be difficult to catch this, but either it’ll be a special case finely tuned for this particular site, or it’ll break another site, causing expiry year to no longer be filled out where previously it was and should be.
1. The "autofill" function only fills in the credit number when the user specifically tells it to; it does not proactively fill forms with no user intervention.
2. "autofill" does not automatically submit the form after filling (although certain forms may be implemented to submit automatically once complete); in this particular case, the user still has a chance to review the completed form before manually clicking the subscribe button.
In the example posted here, it happily completed fields for the credit card expiration year TWICE on the same form, one of which was pre-populated with a value that could not possibly have been a year. The apparent cause is because the substring 'year' appeared in the field name. Levenshtein distance of 12 for a 4 letter word? Yep, looks good! I mean, it's a result so certain there's no need to prompt the user, highlight changed fields or anything, right?
This was trained into me over the years as I saw 1Password do too many things that were wrong or even sometimes scary. The nominal benefit you get sometimes when it works properly isn't worth it.
And yes, web providers should give their web forms better names and better semantic information (e.g. `<input type="email">`), but even in 2021 it's just not always the case.
Well, there's no semantic input for "year" or "currency", so there's nothing the form designer could do to stop 1Password from picking the wrong field. This does kinda get to the root of the issue, which is that 1Password has to do a lot of "cognitive" analysis of the page to find the forms it wants which is simultaneously why it does better than most autofillers, and has worse false positives than most autofillers.
I am also a happy 1Password user, and I'll happily let it prefill a complex form for me, but I've caught enough of its mistakes in the past that I will always manually double check before submitting. I could also see myself making a similar mistake as this user on this form though (since it's so simple I might not manually double check).
And auto-fill always insists to fill out fields that have already been filled in - why can´t it just allow completion of a single form field, instead of putting in random information in all other fields. Before auto-fill, the fill-in suggestions for a single field actually used to be useful: start typing three letters and select the auto-suggested value.
Now, every time I fill out a form I use the autofill suggestions as a way to remember the information that needs to be filled in. But I have to watch out like a hawk to not actually let it "fill" that exact phone number I`m typing in, otherwise it'll fuck up the whole form and force me to start over.
So developers started by breaking browser autocomplete, to which browsers responded by ignoring developer preferences, to which developers respond with different tricks...
The control should be inversed: the 3rd party should request payment from your bank and you would be able to confirm it from the bank website or app.
This is already possible in Portugal with an app where you can give a seller your phone number and it prompts you for payment.
(might be something of a privacy issue, but it beats a possible fraud issue)
Code is one time use, valid for 2 minutes - and you can see all the details in the confirmation that comes from your banking app.
you can also use the same system to tie your phone number to your bank acc, letting other people in this system send you money instantly without extra fees between different banks - and you only need to share your phone number.
This is something I only encounter with American companies/sites/processors. When I shop or pay online locally, 3-D Secure is always required.
It's kinda appalling how much of the web/online experience is negatively impacted by US norms.
We already have an industry standard for access delegation: OAuth, which has been battle-tested over 10 years and supports different flows for various applications (browser, mobile app, etc).
Additionally, I don't quite think making a payment is within the problem domain of OAuth. Most often I'm explicitly not trying to give the site access to my account - I'm trying to fulfil one request.
Validating in some other application) website seems reasonable to me.
If the transaction authentication takes place on a separate page hosted by your own bank (so after the amount has been finalised) these kinds of mistakes can't happen. Unless the user neglects to look at the shown amount, but then the user is clearly at fault.
The UI is styled to make it so that a form input is completely indistinguishable from surrounding text, to such an extent that even people who know it's a form input in this thread have incorrectly assumed that it's not manually editable.
I can't comprehend how anyone could defend deliberately misleading UI design in a form that is asking for your credit card information. This is a problem with Substack. 1Password can definitely do better to guard against it happening, but the only reason it did happen is because Substack actively tried to hide important information from users in a payment screen.
and it would probably also fail with tab.
1PW autofills based on common cc form names, year, credit_card[year] etc etc. Substack clearly named the field a name that could hit that, probably amount_per_year.
1PW can't account for every form on every website, just not realistic.
How's the headline not true? It's a UI/UX issue that caused him to be charged that amount?
I do think there are design issues with people being able to set subscription amounts manually without having a confirmation step when doing so.
Maybe it's the same subscriber and/or same publisher as in this blog post? If not, that would either be a very unhappy coincidence or a strong signal to Substack that they need to fix this issue.
It's a good bug.
Both substack and 1password are responsible to some degree, and it will be figured out, though I think 1password has more obligation to take action because it can happen with other websites too.
A couple of takeaways missed by various comments:
The hidden input box can in fact be manually edited, and if the user selects "Founding member" that fact is highlighted (the cursor is inserted into the textbox).
The hidden input's name attribute is "value". The guess that 1Password is basing its guess on the "/year" text is probably accurate.
https://news.ycombinator.com/item?id=13329525
For this reason, never use auto form fill.
I really wish Dashlane would let me disable the reminded to save my credit card details as this is a feature I do not care for
Did 1Password fill in the year twice? That would be a huge bug. Or will a fraud detection system ignore the missing year if everything else is fine?
"Let's follow a trail of really Bad Tech Decisions between Waze and 1Password."
-- https://twitter.com/cpp_delphi_dave/status/13356390392953036... to read more. It's short.
Of the two, 1Password did reach out, but Support emails went nowhere. Waze never reached out at all.
I occasionally would come across declined card receipts from the machine for some 6 figure amount that had been attempted to charge. Was concerned at first but what had happened was clearly the staff member had forgotten to press enter after typing in the amount, the customer still saw the amount - put in their pin, enter, now it says type pin, try again, then panic when their bank declines it. Luckily the only bad thing that would come out of this is that they should go to the ATM and change the pin, after running the transaction again properly.
Also he was able to get a refund, and i think in most places online, you can cancel the order
I keep a small amount of cash in it at any time, and then do an instant transfer from my main account as needed for larger purchases. If that CC# were to get hacked, it would be annoying but not catastrophic.
Inconvenience level is pretty minimal and it’s served me pretty well.
I tried to dispute it with them, tried to dispute with Paypal and itdidn't protected me, even if I had evidence in a way of showing how the UI is not working and the charge - the answer was always "not enough documents provided". Luckily it was only $10, but maybe I should also have posted on HN
Ultimately, though, I think it's two separate systems doing the best they can to work together, and failing. Payments should be handled by the browser, like how mobile phones do it. I loathe giving Google or Apple more power/control, but this is a situation where I'm still genuinely shocked how rudimentary payments online are.
It's like walking over a railroad bridge that's falling apart.
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.
I'm happy to use for storing my passwords and maybe logging in but that's about it.
It is visible to the user, but it isn’t obvious that this is an adjustable value at all (at least on mobile). There are a number of UX issues at play here... but a poorly styled input isn’t an excuse for the password manager.
<input name="amount" type="hidden" value="15000">
It can't create passwords based on random words. If for some reason I can't use the password manager directly, I Can quickly check that the password is staples-horse-battery-correct and type it manually.
(I'm a Firefox user using keepassXC, but it's basically the same situation)
I typically have notes, maybe one-time passwords, a PIN, the email I signed up with, whether they have my address, various URL if they share the login, etc.