Hacker News Reader

Comment by monkin | Hacker News Reader

It’s not 1Password fault, but poor design and implementation. :-)

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.

Clearly Substack. A UI that let's you specify 10X a price with no confirmation is (unintentionally in this case) malicious.

This story could have easily been written about a user who fat fingered an extra 0 in the field.

Unintentional malice? What?

This field should be clearly visible, even if 1Password would mistakenly input data in there.

1Password filled his card expiration date into the dollars field.

Substack. A payment form should NOT allow you to enter any price in text fields, hidden or not.

Why not? It's an arbitrary donation amount.

I don't trust autofill in what I use, either, Firefox or Keepass.

The poor design and implementation of 1Password, you mean.

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

Ths is an appeal to authority. It is a shortcoming of the product's design for it to autofill a hidden field.

It’s visually hidden for us to see, not for 1Password auto fill mechanism.

Which is a problem in the 1Password autofill mechanism. Unless you believe that it should be filling forms which are hidden from humans?

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.

Reply on news.ycombinator.com