Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An HTML attribute potentially worth $4.4M to Chipotle

cloudfour.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: An HTML attribute potentially worth $4.4M to Chipotle

#21

Post by derekp7 »

chrismorgan wrote: post #4

I have still never encountered a perfect masking implementation for the web. I don’t believe that they exist. If you think you know of one, please tell me and I’ll see how many seconds it takes me to find bugs in it. Normally it’s less than ten. I’ll be mightily impressed if someone can present me with one that I can’t find bugs in. Masking is generally surprisingly user-hostile. It’s better to instead take arbitrary…

Do you have a list of issues with various masking techniques, and / or sample input actions? For example, something wanting a North American telephone number in the format (999) 999-9999 often has issues if the user tries to enter parentheses or dashes. A proper solution is to allow the user to enter punctuation, and accept it if it is expected there, and to remember it for backspace purposes (so a backspace will either stop at, or skip over a "-" depending on if the user entered it).

It would be a fun programming exercise to take a long list of inputs and write some javascript that properly handles every one of them (or to point out where there are mutually exclusive requirements).

Re: An HTML attribute potentially worth $4.4M to Chipotle

#22

Post by slg »

Side question, does not displaying the credit card number and CVV provide any real security value? An overwhelming majority of sites that accept credit cards don't do that and I can't say I have ever been worried about that fact. At least the expiration year is displayed to the user so it is possible to notice if something is entered incorrectly And considering the expiration year masking issue only impacts people who use autofill, likely a small minority of users, I wonder if not displaying the credit card number leads to an even higher number of lost sales.

Re: An HTML attribute potentially worth $4.4M to Chipotle

#23

Post by fortran77 »

My bank in the U.S. (BOFA) has some weird autofill problems. When I try to log out of one business account and log into another, often at the last second the autofill will re-fill in the other account (and clash with my LastPass!) and I find myself logged back into one account when the form had the other login info right up to the time I pressed submit.

Re: An HTML attribute potentially worth $4.4M to Chipotle

#24

Post by jibolso »

There are several issues with this. Narrow thinking as regards the sort of input to expect from users. But asides from the input and what sort of data to expect, I'd like to think they have some sort of analytics which shows drop off rate and what actions occurred before these drop offs, this should have made the problem obvious.

Re: An HTML attribute potentially worth $4.4M to Chipotle

#26

Post by stickydink »

There was a much less juicy bug in the previous iteration of Chipotle's website. Due to demand, the pickup time would often be several hours away from time of ordering. But there was no server validation of the time being sent. A little manipulation of the dropdown picker, and you could send any time (or indeed, any text at all), and it would be printed on the ticket at the restaurant.

It was so easy that half our office was able to figure out that you can right click the picker, "Inspect", then type in any time you like.

Re: An HTML attribute potentially worth $4.4M to Chipotle

#27

Post by latortuga »

ldoughty wrote: post #9

An interesting read, but the dollar figure is author guesswork. I appreciate this kind of digging into web behaviour though.

"but the dollar figure is author guesswork" any figure presented would be guesswork. It's impossible to measure how many users left your site because they thought it was broken.

The estimate provides meaningful context. Without an estimate, this article amounts to complaining about web standards. With an impact estimate, it is actionable. We have a problem, we know roughly how bad it is, we have a solution.

Maybe it's off by an order of magnitude or 2. If it's costing them $44k/year, it's still worth fixing.

Re: An HTML attribute potentially worth $4.4M to Chipotle

#28

Post by tomp »

chrismorgan wrote: post #4

I have still never encountered a perfect masking implementation for the web. I don’t believe that they exist. If you think you know of one, please tell me and I’ll see how many seconds it takes me to find bugs in it. Normally it’s less than ten. I’ll be mightily impressed if someone can present me with one that I can’t find bugs in. Masking is generally surprisingly user-hostile. It’s better to instead take arbitrary…

This.

This is particularly terrible for addresses. The only acceptable solution (that nobody uses) is as follows: allow FREEFORM addresses. Like, I'm OK with the website or the server doing some post-hoc validation, and suggesting to the user "This address doesn't seem right, are you sure it is correct?" But the amount of time I have to enter "county" (or whatever) for my London address (and sometimes it's Greater London, other times just London, or probably something else as well...) is ridiculous, doubly so because mail in the UK arrives without problems with little more than just a postcode.

Re: An HTML attribute potentially worth $4.4M to Chipotle

#29

Post by aapeli »

slg wrote: post #22

Side question, does not displaying the credit card number and CVV provide any real security value? An overwhelming majority of sites that accept credit cards don't do that and I can't say I have ever been worried about that fact. At least the expiration year is displayed to the user so it is possible to notice if something is entered incorrectly And considering the expiration year masking issue only impacts people wh…

Yes, most browsers treat password boxes as sensitive input which has implications to a lot of things. For instance if a blind person types in their CVV using assistive tools on Firefox on macOS, making it a password stops it from being read out loud like other input (it's probably the same on an iPhone, and in some cases this would be annoying if you're in public, etc).
Post reply on HN