Hacker News Reader

Comment by petulla | Hacker News Reader

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

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.

  <input name="amount" type="hidden" value="15000">

Ah, I misunderstood. Yup that's pretty bad then!

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 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.

Making rent was kind of challenging that month.

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.

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.

> 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 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.

because it would've probably failed with other password managers and probably browers (if there are people who save their card details to a browser)

and it would probably also fail with tab.

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.

>it filled the wrong field

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.

> The user also had a chance to see how it filled the form and didn't bother checking.

So ... you're saying it's the their own fault and Substack should keep the money?

It's definitely not Substack's fault. They presented the user a form to fill, the user used some tool to fill it and it failed.

Whether Substack should keep the money is a matter of goodwill, it's no different from the user fat-fingering an extra zero.

They were charged, but were able to get a refund from the publisher they subscribed to.

We've added "temporarily" to the title to make it true again, or at least as close to true as it started out.

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?

1Pass can choose not to put CC information into hidden fields.

Looking at the screen cap, it's not actually a hidden form, as much as a form field styled to look like text.

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?

   <span class="variable-amount">
   $
   <input class="variable-amount-input" type="text" style="width: 25px;">
   <input name="amount" type="hidden" value="19900">
   /year
   </span>

I didn't say it is a hidden form, but a hidden field.

Reply on news.ycombinator.com