Live data from Hacker News

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

timmyomahony.com

91–100 of 278 posts

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

#91
post #82

Earlier quoted context omitted.

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.

  

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

#92
post #39

What's the point of hidden input there ? A bug ? A feature ?

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 sty…

It is hidden in the HTML form sense.

  
It doesn't become visible to the user until you click the radio button.

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

#94
post #91
post #82

Earlier quoted context omitted.

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.

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

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

#95
post #70

Earlier quoted context omitted.

Yes, password managers are way safer than copy-pasting. You don't want something as sensitive as a password in your clipboard buffer, either.

Mine clears the clipboard after 10 seconds.

You do realize that in 10 seconds your computer can achieve a lot of stuffs right?

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

#96
post #68

Earlier quoted context omitted.

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.

Where are you getting 3% back on all transactions?

Citi double rewards card

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

#98

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 an…

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…

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

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.

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

#99
post #34

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 an…

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.

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.

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

#100
post #98

Earlier quoted context omitted.

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…

> 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. Note that this behavior is defined as part of the `autocomplete` standard. https://html.spec.whatwg.org/mul…

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

Post reply on HN