Substack's UI and 1Password temporarily cost me $2k

This is an example of a common antipattern in software: some piece of software fails to correctly implement something (here, modern HTML autocomplete=&quot;cc-exp-year&quot;), 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 of what to fill where because many sites don&#x27;t set autocomplete properly, so inevitably it will guess wrongly sometimes.<p>Other examples are problems with lock files and file versioning (because programs tried to roll their own when the operating system didn&#x27;t provide them), and the complexity of parsing &quot;HTML soup&quot; and emails with all kinds of bizarre invalid syntaxes.<p>I can&#x27;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.<p>Somehow this kind of nonsense has become culturally acceptable in the software industry. If the car industry worked this way you&#x27;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 had a similar 1Password moment. I was buying airline tickets; entered my name, my wife’s name, address, declined insurance, declined hotel offer, scroll scroll scroll... Then I let 1Password fill in my payment details, which it did perfectly fine. But... what it ALSO did, on a field now well off the top of the screen, was change my wife’s first name to my full name.<p>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.<p>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&#x27;ve put &quot;temporarily&quot; 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&#x27;t think it&#x27;s fair to leave up a title that implies that there&#x27;s an uncorrected injustice to get angry about. If anyone has a better solution, we can do that instead.

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).<p>This seems like another reason. It&#x27;s not worth it. Keep the password manager in its own app and apply the tiny extra effort of pasting the password from there.

That order form has poor usability.<p>1. It uses placeholder text instead of a label. See &quot;Placeholders in Form Fields Are Harmful&quot; <a href="https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;form-design-placeholders&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;form-design-placeholders&#x2F;</a><p>2. It hides the fact that the &quot;$250&#x2F;year&quot; is actually a text box. See &quot;Long-Term Exposure to Flat Design: How the Trend Slowly Decreases User Efficiency&quot; <a href="https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;flat-design-long-exposure&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;flat-design-long-exposure&#x2F;</a><p>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 &quot;Founding Member&quot; radio button. That would make the text box subordinate to the radio button and reduce user errors. See &quot;8 Design Guidelines for Complex Applications - 6. Reduce Clutter Without Reducing Capability&quot; <a href="https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;complex-application-design&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;complex-application-design&#x2F;</a>

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&#x27;t fight them.<p>(And I won&#x27;t get into sites that won&#x27;t let you paste passwords into their forms.)

Just wanted to add some detail on how the 1Password extension operates here, since the term &quot;autofill&quot; can be ambiguous:<p>1. The &quot;autofill&quot; function only fills in the credit number when the user specifically tells it to; it does not proactively fill forms with no user intervention.<p>2. &quot;autofill&quot; 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.

This is exactly why I don&#x27;t trust autofill. How many times has it passed along information you didn&#x27;t intend, but <i>without</i> any obvious errors? Nobody knows.

The abominable UX in this situation is that users need to give free access to their credit card for payment, at the promise that the other party will play nice. This is backed by strong laws, but still absurd.<p>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.<p>This is already possible in Portugal with an app where you can give a seller your phone number and it prompts you for payment.<p>(might be something of a privacy issue, but it beats a possible fraud issue)

That&#x27;s one of the reasons I don&#x27;t want to use 1Password and instead I&#x27;m just using old KeePass. KeePass fills what field I&#x27;ve selected. 1Password does its own magic and I don&#x27;t like magic. KeePass might be slower, but I&#x27;m not filling those forms every day, so I can live with it. Basically KeePass does simple thing and does it well. 1Password might be good at doing complex things, but it does not have AI.

I see a lot of comments blaming either substack or 1password, but to me it seems the archaic transaction method of credit cards deserves most of the blame for these kinds of problems.<p>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&#x27;t happen. Unless the user neglects to look at the shown amount, but then the user is clearly at fault.

Seems more accurate to say that 1Password not Substack did this? Also headline is not true?

I&#x27;ve updated my blog post to include 1Password in the title as it contributed to the issue (I can&#x27;t update the title here). That said, I&#x27;ve never experienced this before, having used 1Password on 100s of other payment forms so something is up.<p>I do think there are design issues with people being able to set subscription amounts manually without having a confirmation step when doing so.

Here&#x27;s another report today of someone wrongly paying $2023 per year for a Substack newsletter: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;jessesingal&#x2F;status&#x2F;1374019267147018243&#x2F;photo&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;jessesingal&#x2F;status&#x2F;1374019267147018243&#x2F;p...</a><p>Maybe it&#x27;s the same subscriber and&#x2F;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.

I see replies blaming 1password being downvoted, so I&#x27;ll ask a question instead. Why would 1password decide to fill out that particular input with the expiration date?

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).<p>A couple of takeaways missed by various comments:<p>The hidden input box can in fact be manually edited, and if the user selects &quot;Founding member&quot; that fact is highlighted (the cursor is inserted into the textbox).<p>The hidden input&#x27;s name attribute is &quot;value&quot;. The guess that 1Password is basing its guess on the &quot;&#x2F;year&quot; text is probably accurate.<p>[1] <a href="https:&#x2F;&#x2F;nonlinearproject.com&#x2F;subscribe" rel="nofollow">https:&#x2F;&#x2F;nonlinearproject.com&#x2F;subscribe</a>

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&#x27;t go through an unnecessary error-prone user-facing interface. (Yes, Apple etc. are oligopolists, but so are Visa&#x2F;MasterCard)

An article on HN a few years ago on how easy it is to steal data using auto form fill.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13329525" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13329525</a><p>For this reason, never use auto form fill.

This is why I don&#x27;t have my credit cards stored for &quot;easy&quot; input and submission and instead always enter them manually<p>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

I don&#x27;t doubt the story, but if the expiry year was in the wrong field, why did the payment go through?<p>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?

It was not expensive, merely inconvenient, but 1Password and Waze combined to give me a two hours of frustration in December. At the end I went back to the beginning and reported the experience here. I wrote on twitter,<p>&quot;Let&#x27;s follow a trail of really Bad Tech Decisions between Waze and 1Password.&quot;<p>-- <a href="https:&#x2F;&#x2F;twitter.com&#x2F;cpp_delphi_dave&#x2F;status&#x2F;1335639039295303681" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;cpp_delphi_dave&#x2F;status&#x2F;13356390392953036...</a> to read more. It&#x27;s short.<p>Of the two, 1Password did reach out, but Support emails went nowhere. Waze never reached out at all.

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.

My guess is that 1password filled it with the year because it saw the “&#x2F;year” part of that input box…

This story reminded me of my experiences working in a bar (in the UK, chip-and-pin was a thing but contactless was only just rolling out) It was mainly a student bar so basically every card was a debit card...<p>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.

I use a prepaid card online, which would have been a good safety net against things like this<p>Also he was able to get a refund, and i think in most places online, you can cancel the order

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.<p>I tried to dispute it with them, tried to dispute with Paypal and itdidn&#x27;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 &quot;not enough documents provided&quot;. Luckily it was only $10, but maybe I should also have posted on HN

It&#x27;s interesting Substack is getting the blame here rather than 1Password.<p>Ultimately, though, I think it&#x27;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&#x2F;control, but this is a situation where I&#x27;m still genuinely shocked how rudimentary payments online are.

Ironically, the founder of my company and I spent over an hour breaking apart this exact page yesterday talking about its UI. There are a lot of really good things that this page does right (shows tradeoffs between different tiers in a way that&#x27;s not confusing at every tier), but... yikes. Sorry to hear about this.

One of my utilities likes to add an extra bit of login confirmation with a question, like, &quot;What is your favorite sport&#x27;s team?&quot;. Every time, my password manager prompts me to overwrite my site password with answers to those questions.<p>It&#x27;s like walking over a railroad bridge that&#x27;s falling apart.

It&#x27;s been a while, but a similar thing happened to me. The delivery address form was on the same page as the cart, and my autofill put my zip code into the article amount. A little shocking at first to see a bill of 65,000€ instead of 12€, but at least it took less than an hour to resolve.

Great to hear that this got resolved and fair play to Substack for that, but this is inarguably a 1Password bug. If there had been any issue with resolution, they&#x27;d be the party I&#x27;d be chasing.<p>Other commenters here have bemoaned the need for these kind of heuristics in dealing with compat with bad HTML form implementations, but there&#x27;s an easy fix to that: origin-based compat lists. Browsers do this for quirksmode&#x2F;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&#x27;s no reason 1Password couldn&#x27;t do the same.<p>There isn&#x27;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&#x27;t highly sensitive pages (1Password saves credit card details!), but in this case there isn&#x27;t really any excuse. The cost of achieving &quot;blind&quot; compat with smaller sites is too high in this case.

Did anyone try to set -100 Dollar? ;-)

1Pass definitely needs to add some kind of notice or alert when it fills in hidden fields. And it really needs to not overwrite a field that’s already been filled in. It’s really frustrating when it decides to h do everything you typed in.

After seeing 1Password&#x27;s automatic form filling behavior in action almost a decade ago I decided not to use it just in case of this sort of thing.<p>I&#x27;m happy to use for storing my passwords and maybe logging in but that&#x27;s about it.

Whoa. That&#x27;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.

Why are those fields not overridden in the backend?... If the back-end doesn&#x27;t check those fields are what they should be for each option then the reverse could also be true (free membership)

I only let my password manager fill in passwords. It’s less efficient for sure but my cc details are in muscle memory and filling out my name and address doesn’t really bother me too much.

What&#x27;s the point of hidden input there ? A bug ? A feature ?

OSs need to provide credential management with APIs to let users choose their password manager, and then browsers can use OS support. Only then can we stop the madness.

Nevermind that, does that mean that their billing has an exploit and I can buy Substack Founder for $1? Or can I convince their system to bill me -$1 for that matter.

Has anyone noticed that NameCheap&#x27;s login page makes the newsletter field get filled in when you use a password manager to autofill the login page?

That&#x27;s why your credit card should be using 2FA for authorizing payments (via App or SMS-TAN). Visa Secure Code or MasterCard Identity Check.

It may not convert as well, but this is why I really appreciate the payment confirmation type screen before the charge is actually made.

Honest Question: Why do you guys use PW and not just Chrome build-in pw ? Assuming you neutral or not anti-google in the first place.

I&#x27;d say it&#x27;s more like 1Password cost you $2,023.

any security issues with using browser&#x27;s inbuilt password manager when compared to dedicated password managers?

Similar experience on Firefox mobile

Why do browser need to guess at autofill? Isn&#x27;t it to everyone&#x27;s advantage for forms to just tag their fields explicitly?

Ohhhhh nooooooooo! (facepalm)

The author knew from the beginning it wouldn&#x27;t &quot;cost them $2023&quot;, but that it would most likely be solved by a simple support request. The title is misleading.