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.)
Whats the solution for the busy engineer? Anyone know a Selenium plug in that let's you run with browser extensions or something? There's too many popular extensions to test manually.
Haven't seen this automated, but I have seen internal issues raised by folks within large orgs when their extension started breaking things. But it's only once you have 50+ to 100's of engineers working on a product, each with a subset of extensions installed, that you can rely on the cross product of engineers and their installed extensions for realistic coverage.
I mean what is there to test, really? Just use the the different input types and mark your fields as "email", "password" and so on. There is nothing to test really.
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.
The problem is that all of these autofillers are already way too complex, because almost no one uses the optimal markup (adding the attribute autocomplete="cc-exp-year", in this case)—almost no one has even heard of the proper autocomplete markup here (I remember being in a conference room with two or three hundred other web developers a couple of years back, and the speaker asked who knew about autocomplete="new-password" and the likes; only three of us raised our hands: I and my coworker, and one other).
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.
I wonder how many of those devs use a password manager and just thought it was magic they didn't need to worry about when they were writing those kinds of forms.
I assumed that kind of markup had to exist, but its not my job to do web development at all, so time being finite, I'd never seen those. But I always assumed that they'd have to exist if I ever went looking. Why do people whose job it is to know these things not bother checking?
The problem is there are too many standards and they are all clutered on too many websites. I mean there should be a website listing the standard in an easy way.
This is (generally) done because they offer SSO functionality, and need to know whether to redirect the user to their corporate SSO page or show the password prompt.
Yeah it seems pretty clear that this was a 1Password flaw and didn't really have anything to do with Substack's UI. And yes, the first paragraph notes that no money was spent, so not really sure why multiple people have downvoted your comment.
If all the password managers in the world fail at this site, it's still a problem with the password managers. The fact that the field was looking as non-editable from the start has nothing to do with the fact that it filled the wrong field.
The user also had a chance to see how it filled the form and didn't bother checking.
I agree, this is awful (I'd really like to know how on earth it decided that this field is where the expiration year belongs. It sounds like some extremely aggressive assumptions are being made).
>The user also had a chance to see how it filled the form and didn't bother checking.
It's impossible to overstate how wrongheaded, unproductive, and, frankly, lazy this sentiment is.
I think the end of the article clearly admits that it's a little bit of both and actually gives really good advice to keep in mind while designing checkout flows.
If your UI can charge me $2023 instead of $250 without so much of a confirmation, your UI is just a minefield. Forget about auto fill, humans make typos in a free entry text box.
Many many years ago I once made a $6900 payment on a $69 internet bill because of a misplaced decimal point, with no confirmation before the amount was debited from my bank account. Definitely partly my fault for missing it, but they also didn’t design that payment flow to stop it from happening or even to autofill the correct payment amount.
(I was super unlucky that it happened when I’d just received a big performance bonus, or the bank would have simply declined the transaction outright due to me not having anything remotely like that much money in my accounts)
It took a surprising number of customer service calls (and then weeks) to get that payment refunded. And more than once I had to explain to a service rep that no, I didn’t want to just leave my internet service account balance thousands of dollars in credit so I wouldn’t need to pay the monthly bill for the next decade. I mean, obviously.
From the user (donator)'s point of view, a confirmation is a good thing. From their point of view, asking someone to confirm if they really want to donate X is a chance to lose legitimately-entered X's.
And obviously from their point of view, OP actually entered $ 2023 and was fully aware of what he was doing (they didn't know about the bug)
If your business’s success depends on charging people money they’ll regret spending once they see a payment confirmation one second later, you should find a new business idea asap.
In Germany, when paying at a restaurant, the machine often asks you to type the tip you want, before your card PIN. The (badly lit) screen also tells that to the user in German, which doesn't help if you don't speak it.
It has happened quite often that I typed my PIN by habit and the machine just refused a tip amount that large, thankfully.
> Yeah it seems pretty clear that this was a 1Password flaw and didn't really have anything to do with Substack's UI
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.
I'd say the Substack UI is messed up if (a) there's a hidden input box that automatically changes the selection, even though the user cannot manually enter information there, and (b) there's no confirmation screen to confirm everything is correct. It shouldn't matter that a password manager exposed the problem.
The use of the word "hidden" in the article is misleading. The field is visible and editable by the user -- it is just styled in a way that does not make it clear it is an editable field. There is a GIF in the article showing the author changing this field value manually.
It's not misleading at all; it's an input with the type set to "hidden". The field doesn't become visible until you select the radio button for that subscription level.
Probably not fair to pin it fully on 1pw or substack.
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?
Looking at the source of the actual page, it's very odd markup.
There's a real input field, and a hidden input field "on top of" each other. I guess one is the stylized user-interactive one of which the value gets normalized into cents into the hidden one?
I think it's both. 1Password shouldn't have filled in that amount and Substack should have had a clear confirmation - "Are you sure you want to pay *2,023 dollars* a year?"
Every single other website I've purchased from has a "confirm your order" page. Instantly charging the customer's card after submitting the payment form is a headache for both customers and merchants, because it's easy to make mistakes.
This is exactly why I don't trust autofill. How many times has it passed along information you didn't intend, but without any obvious errors? Nobody knows.
If it's not 1Password's fault, who's is it? Obviously this story had a happy ending, so it's not a terribly big issue, but 1Password's client ultimately passed along the unwanted data.
Speaking from personal experience -- over about six years at this point -- there are many, many web sites on the internets that 1Password's autofill works perfectly well on, and many others where it doesn't work perfectly but fails gracefully (or at least non-destructively). "Here is one site where it makes a mistake that could be catastrophic if you don't catch it" is just not a slam-dunk proof of 1Password being "poorly designed."
So you want 1Password to check CSS of the form before auto filling? The form itself isn’t hidden it’s styled to be flat. That’s the biggest problem of it.
That exactly correct, which is why the fault is with 1Password's fill mechanism.
A product has a bug when it does not produce output in-line with its stated purpose and process. Nobody would use a refrigerator that suddenly forgets to keep food cold when a carton of milk is placed on the shelf.
It is a visible input field styled not to look like an input field until that radio button is selected, but it is not "hidden" in the HTML sense. It is not a shortcoming of the product's design to not have parsed the CSS and intuited that Substack's designers wanted to cleverly make it not look like an input field.
> It is not a shortcoming of the product's design to not have parsed the CSS and intuited that Substack's designers wanted to cleverly make it not look like an input field.
How is it not a shortcoming? Any human looking at the page can immediately tell that this form field should not be autofilled.
Difficult problem to solve? Sure, doesn't make it any less of a shortcoming.
Similar situation here. I use 1Password every day, but I only trust it to autofill simple login forms. Where something more complex is happening, I tend to copy information over field by field.
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.
> 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).
> 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 is how you mark up the expiry year in a credit card form:
Mock me if you wish, but I tend to use 1Password for what it does best but use Apple’s Autofill for credit cards. It misses stuff sometimes but -fingers crossed - no issues with mis population into amount fields. I also use ApplePay or PayPal wherever possible to avoid data entry and reduce friction.
Exactly. This is also the reason why developers don't want autocomplete - the data is so much lower quality.
So developers started by breaking browser autocomplete, to which browsers responded by ignoring developer preferences, to which developers respond with different tricks...
Autofill is a hot mess. If you have more than one address, and also occasionally fill up info for your partner, or with your work phone, things can really escalate. I think my Chrome has 20 different combinations of 2 names, 2 addresses, 2 phone numbers.
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.
Interesting bug. Appreciate the post and the disclaimer at the top but IMO the headline should be updated too. Right now it’s a bit clickbaity and also inaccurate.
Yikes. I love my password manager, but I decided when I got it that I was never going to use the browser extensions. Putting your password manager anywhere near your web browser just seems like insanity to me (all the exploit write-ups I recall about password managers were related to browser extensions and sandbox escapes).
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.
To counter this: if you happen to find yourself on the phishing domain facebo0k.com and you end up copying your password into that.. Browser extensions guard for this better than we can.
I don't think a webpage can read clipboard without the user manually pasting.
If there's some malicious desktop program running on your machine at the same time as the password manager then you're probably screwed regardless of whether the password passes through the clipboard - but maybe there's some subtleties I'm missing here.
Between Keepass, 1passwword, and lastpass I've never seen a password manager that just shows the password without the user explicitly choosing to reveal it
1password has the option to do so and I do it on my home desktop computer. Obviously on mobile devices it would be a bad idea and on those I leave that option in it's default, disabled state :)
I a simple algorithm to generate a password based on the name of the service you are using, interleaved with a constant master password you remember. You can do the same thing with a password-manager password + clipboard, interleaved with a constant master password you remember, which should be even better.
There are non-browser-extension password managers that still emulate you typing on your keyboard, rather than going through clipboard.
Personally I use rofi-pass to access GNU pass passwords (so just a hotkey and search for password name)
I'd warmly recommend it (or whatever other client you use for GNU pass) but I'm sure you can find similar functionality for any other decent password manager.
Some password managers will type the username/password into the browser (through a virtual keyboard I think), not copy-paste them to protect against clipboard attacks. Eg. Keepasssc
That's something to think about. But I'm not sure how I would end up on fak3b00k.com unless something changed my bookmark for it, or I really mistyped it but if I did that the URL being different is a dead giveaway.
Maybe we should take the best of both worlds then: an extension that only knows which domains you have passwords saved for, but not the account or PW. It just serves as a red flag if the domain is suspect.
This is how the Keepass Helper extension has worked for years: putting the domain in the RHS of the titlebar. Then with autotype set to match that you can autotype from the global hotkey. Keepass 2 can even split the credentials between key presses and pasting.
There are other URL in title extensions for most browsers. And they're simple enough you can audit them or write your own.
this is why I use a password manager that has no network connectivity whatsoever, and no browser integration. keepassx with a v2.0 keepass format file.
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.
Password managers aren't nearly intelligent enough to be used without copy and paste for sensitive forms.
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>
I found that there's no good hackless way to allow a password manager to autofill the password without touching the other fields with a username or some other quirk like just clearing your inputs. Even a fix like opening a modal with the lone password confirmation field doesn't necessarily fix it in all browser/OS configurations.
Password managers are braindead and browsers don't give you any tools to help.
1Password was one of my test extensions and the one I use every day. It works most of the time because username/password combos are the most common autofill configurations.
So common that most password managers don't consider the case where you want to autofill a password without a matching username field on the page. "Password confirmation" being the classic example.
They just don't handle anything other than the main case very well.
Interesting. The weirdest site I use on a regular basis is Mailgun and it has this scrolling form which isolates entry for email/password/2fa (which, as an aside, I hate) and it gets it right every time. I can't remember any instances of it going wrong, actually.
> 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.
Yes, and the point of putting in the standard is so that it's documented how to author your website. Unfortunately, some not insignificant number of UI/UX designers want to push their special flow on users and so we get these incompatibilities.
Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away
The spec is underspecified for basic edge cases, like any spec, and it's very hard to have implementation consensus.
This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA.
How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care.
Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.
Nice note. One problem is that you are left without options, only hacks, to work around this heavy handed behavior. It wouldn't be so bad if you could opt-out with autocomplete="off".
And even if it did work, a spec is always underspecified even for the password manager who wants to follow it 1:1, so even in a best case scenario, you don't have implementation consensus. For example, you would think password manager heuristics wouldn't look outside the current <form> to assume the username field, but some do on some browsers.
The end result is that if you have a need that isn't the general case, you end up having to trade away UX to cater to software.
> Note that this behavior is defined as part of the `autocomplete` standard.
Yes, but it’s my understanding that Chrome ignores this attribute because some website authors abuse it to disable autofill on the login pages because “security”. I’ve also seen some places disable pasting of a bank’s routing and account numbers because “security”. It’s actually more secure for me to copy-paste those numbers than type them because I can’t make a mistake then!
It’s a tough call because I hate when websites do that, but I also want them to be able to disable it in the right places for security.
Lastpass used to have an option for autofill to only fill empty fields, not sure if it is still there as I moved on a year ago but it stopped a little of that annoyance.
You can still use something like passmenu[0] bundled with GNU pass, bind it to a hotkey and it fills it in as if you were typing on your keyboard, no clipboard involved.
I've never encountered any autofill instance where the effects of autofill wasn't immediately apparent (usually it's just the username and password). Having a special hidden fields in your form seems like a Bad Idea, but what is worrying is that there is nothing stopping more devs from implementing something like this. The only reason why we don't see it more often is probably because it takes more effort to make a "smart" form like this.
After learning about how every app in your PC has unfettered un monitored access to the clipboard why in gods name would you do that? I explicitly make a point to never copy any password to the clipboard!
On a desktop, you can use KeePass and its variants to "auto-type". It'll switch focus to the last app you were in and type your username, a tab, your password, and then enter. No extensions or clipboard required. Just hit CTRL-SHIFT-V after highlighting the entry.
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.
That's a different option (CTRL-C). You can copy and paste the username and password. There's a default clearing timeout that's more to ensure the user doesn't accidentally paste it elsewhere. The auto-type option I mentioned is different.
I tried using this but the final "enter" made me too uncomfortable. I really wish it was optional so I could verify where it just typed the password before submitting. After accidentally sending my password in the wrong field/window a couple of times I stopped using it entirely. Now I just copy-paste :(
keepassxc has extra options in the auto-type menu for "username", "username<enter>", "password" and "password<enter>" in addition to the normal "username<tab>password<enter>"
Gfycat already generates memorable URLs so it’s definitely possible. I myself do it manually nowadays (ie generate phrase password to be stored in manager so I can copy it manually if needed)
Use a browser extension. For example, the 1Password extension uses (authenticated) IPC to talk to the app and then injects the password into the DOM directly.
I'm still utterly perplexed about why every major operating system handles the clipboard this way. It's such an obvious privacy issue, and the fix seems really simple: only allow clipboard access when the user explicitly grants access through a system-provided user interface (whether that be a dialogue box, menu item or keyboard shortcut)
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)
There is no way I could have convinced the people I have to use a password manager without the browser extension. So for those people it was either same password on all sites or a password manager with a browser extension.
I use Firefox's own password manager (https://www.mozilla.org/en-US/firefox/lockwise/) inbuilt into the browser. I think it's a better compromise than having to expose sensitive credentials into my clipboard. IT works across devices too, so there's no copy pasting on my Android device which god forbid is probably reading my clipboard too (I know Facebook used to do that).
I do not see a reason to copy paste in any use case at all.
I see replies blaming 1password being downvoted, so I'll ask a question instead. Why would 1password decide to fill out that particular input with the expiration date?
Because that one input had the word "year" in it. 1password confused "expiration year" for "$ / year".
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.
It’s not “hidden” in the HTML form sense. It’s an input that is not styled as an obvious input field. The idea here is that if you want to, you can give the author more money as a “founding member”. You can the set the amount you’d like to give.
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.
That hidden input element contains the normalized value in cents, if that got filled out he would have only gotten charged $20. Right before it in the DOM is the stylized user-input field which does not get hidden (and populates the hidden field via JS)
I've updated my blog post to include 1Password in the title as it contributed to the issue (I can't update the title here). That said, I've never experienced this before, having used 1Password on 100s of other payment forms so something is up.
I do think there are design issues with people being able to set subscription amounts manually without having a confirmation step when doing so.
1password payment form filling works fine so rarely for me, I usually copy just number by hand. I wonder if that's somehow specific to Russia (field names are still in english, but it doesn't seem to help much)
Whoa. That's absolutely insane. And yet now that someone has demonstrated it I can see this turning into a dark pattern that a variety of less scrupulous sites will use in the foreseeable future.
You are lucky. I was trying to get a refund from fax site where they let you enter a value into dropdown and then happily charge you default value.
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
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.
The author knew from the beginning it wouldn't "cost them $2023", but that it would most likely be solved by a simple support request. The title is misleading.
Just because a lot of people are commenting on this without seeing the form, if you go here[1] you can see it in action (no association with the page, it was the first one that turned up on Google).
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.
Why are those fields not overridden in the backend?... If the back-end doesn't check those fields are what they should be for each option then the reverse could also be true (free membership)
What do you mean? The goal of that subscription option is to allow the user to pay a custom amount. I guarantee you the custom amount cannot be less than the yearly membership.
You don't get cash back bonuses with a pre-paid card. In fact, they cost money. I am not going to give up saving 3% on everything I buy just to avoid this rare error that was easily corrected for no lost money.
Presumably on a credit card, which would also have more robust chargeback rights than debit cards typically do. Between that and the likely relatively high value of a customer qualifying for 3% cash back on every transaction, I doubt it'd be more than a minor inconvenience to have the transaction reversed, even if the acquirer declined to refund it - which didn't happen here, in any case.
My bank set up a free sub-account with its own debit card that I use exclusively for online transactions.
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.
You can get a "refund" everywhere, because it's an unauthorized transaction. If the merchant will not refund, you simply call up the card company and explain how you agreed to a charge of $10 and were subsequently charged $2,000. The only reason the article was phrased as "costing" the author money is for clickbait.
It's interesting Substack is getting the blame here rather than 1Password.
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.
I've put "temporarily" in the title because the post now says the money has been refunded. The article is worth leaving up because, unlike the typical riler-upper, it touches on a phenomenon which is interesting in its own right. But I don't think it's fair to leave up a title that implies that there's an uncorrected injustice to get angry about. If anyone has a better solution, we can do that instead.
hi dang, I propose a universal solution for similar instances like when a site was down or when another issue has been sorted out: the use of "[resolved]" appended to the title.
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.
277 comments
[ 4.8 ms ] story [ 361 ms ] thread(And I won't get into sites that won't let you paste passwords into their forms.)
Put in dollars, it probably costs 5-10 million a year (if not more) to test extensions even haphazardly.
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.
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.
https://www.w3.org/TR/html52/sec-forms.html#sec-autofill
I assumed that kind of markup had to exist, but its not my job to do web development at all, so time being finite, I'd never seen those. But I always assumed that they'd have to exist if I ever went looking. Why do people whose job it is to know these things not bother checking?
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
and it would probably also fail with tab.
The user also had a chance to see how it filled the form and didn't bother checking.
I agree, this is awful (I'd really like to know how on earth it decided that this field is where the expiration year belongs. It sounds like some extremely aggressive assumptions are being made).
>The user also had a chance to see how it filled the form and didn't bother checking.
It's impossible to overstate how wrongheaded, unproductive, and, frankly, lazy this sentiment is.
So ... you're saying it's the their own fault and Substack should keep the money?
Whether Substack should keep the money is a matter of goodwill, it's no different from the user fat-fingering an extra zero.
(I was super unlucky that it happened when I’d just received a big performance bonus, or the bank would have simply declined the transaction outright due to me not having anything remotely like that much money in my accounts)
It took a surprising number of customer service calls (and then weeks) to get that payment refunded. And more than once I had to explain to a service rep that no, I didn’t want to just leave my internet service account balance thousands of dollars in credit so I wouldn’t need to pay the monthly bill for the next decade. I mean, obviously.
Making rent was kind of challenging that month.
And obviously from their point of view, OP actually entered $ 2023 and was fully aware of what he was doing (they didn't know about the bug)
It has happened quite often that I typed my PIN by habit and the machine just refused a tip amount that large, thankfully.
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.
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?
There's a real input field, and a hidden input field "on top of" each other. I guess one is the stylized user-interactive one of which the value gets normalized into cents into the hidden one?
This story could have easily been written about a user who fat fingered an extra 0 in the field.
A product has a bug when it does not produce output in-line with its stated purpose and process. Nobody would use a refrigerator that suddenly forgets to keep food cold when a carton of milk is placed on the shelf.
How is it not a shortcoming? Any human looking at the page can immediately tell that this form field should not be autofilled.
Difficult problem to solve? Sure, doesn't make it any less of a shortcoming.
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).
This is how you mark up the expiry year in a credit card form:
So developers started by breaking browser autocomplete, to which browsers responded by ignoring developer preferences, to which developers respond with different tricks...
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.
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.
If there's some malicious desktop program running on your machine at the same time as the password manager then you're probably screwed regardless of whether the password passes through the clipboard - but maybe there's some subtleties I'm missing here.
If I have to do it, I immediately copy something else right afterwards, to avoid an accidental paste later on.
Could be better if it auto-cleared after a paste, but not sure how feasible that would be.
Personally I use rofi-pass to access GNU pass passwords (so just a hotkey and search for password name)
I'd warmly recommend it (or whatever other client you use for GNU pass) but I'm sure you can find similar functionality for any other decent password manager.
Makes them easy to use, with no saved PW.
That would probably be the best of both, no clipboard, and no browser addons.
There are other URL in title extensions for most browsers. And they're simple enough you can audit them or write your own.
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.
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:
I found that there's no good hackless way to allow a password manager to autofill the password without touching the other fields with a username or some other quirk like just clearing your inputs. Even a fix like opening a modal with the lone password confirmation field doesn't necessarily fix it in all browser/OS configurations.Password managers are braindead and browsers don't give you any tools to help.
So common that most password managers don't consider the case where you want to autofill a password without a matching username field on the page. "Password confirmation" being the classic example.
They just don't handle anything other than the main case very well.
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.
Hopefully the specs and expectations will evolve to the point that if your site doesn't follow the spec no one will use it. I can certainly imagine Apple/Google/Microsoft/Firefox having a semi-seamless sign up and failing to follow the standard means you plenty of users turn away
This stuff is supposed to improve the UX. Yet the reality is that even when building basic forms, every website has to test and solve the sort of problems shown in TFA.
How much of the spec does every web developer in the world have to read to know that password managers should or shouldn't try to fill in credit card expiry/cvv in a hidden input? Does the spec even say anything about that? 1Password will ignore a `display: none`, by the way. Can this be quick-fixed by ensuring hidden inputs also have `display: none`? That's something every website trying to consider good autofill UX gets to figure out themselves if they even care.
Unfortunately "just follow the spec" does very little to block off the rabbit holes you'll find if you try to perfect UX on even basic forms, else I might agree with you.
And even if it did work, a spec is always underspecified even for the password manager who wants to follow it 1:1, so even in a best case scenario, you don't have implementation consensus. For example, you would think password manager heuristics wouldn't look outside the current <form> to assume the username field, but some do on some browsers.
The end result is that if you have a need that isn't the general case, you end up having to trade away UX to cater to software.
Yes, but it’s my understanding that Chrome ignores this attribute because some website authors abuse it to disable autofill on the login pages because “security”. I’ve also seen some places disable pasting of a bank’s routing and account numbers because “security”. It’s actually more secure for me to copy-paste those numbers than type them because I can’t make a mistake then!
It’s a tough call because I hate when websites do that, but I also want them to be able to disable it in the right places for security.
[0] https://git.zx2c4.com/password-store/tree/contrib/dmenu/READ...
[0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/N...
That said, the implementation probably differs on different platforms. 1Password, for example, uses a virtual "keyboard" on Android.
It actually falls back to the clipboard [0], in a huge number of situations [1]. Basically, if Windows Forms isn't available/reliable.
[0] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/U...
[1] https://github.com/dlech/KeePass2.x/blob/VS2019/KeePassLib/U...
Paste draws from the clipboard.
Gfycat already generates memorable URLs so it’s definitely possible. I myself do it manually nowadays (ie generate phrase password to be stored in manager so I can copy it manually if needed)
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'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.
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.
I do think there are design issues with people being able to set subscription amounts manually without having a confirmation step when doing so.
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?
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
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.
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.
[1] https://nonlinearproject.com/subscribe
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.
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.
That's exactly what this field was though, a pay-what-you-can field (hidden because its visibility is conditional, possibly)
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.