SUPPUASTPDS Episode 1: Bad HTML Could Cost You Millions?

This is a transcript of a podcast I wanted to make. While I didn’t make any episodes past this one, I plan on making a podcast on computer bugs at some point.

Hello and welcome to The Strategically Unnamed Programming Podcast Unnamed As Such To Prevent Domain Swatting or SUPPUASTPDS hosted by me, Farai Gandiya, a chronically unemployed CS graduate with way too much time on his hands. On this podcast, I hope to explore computer bugs, prominent and otherwise.

In this inaugural episode, I’ll share a couple of benign bugs caused by poorly coded HTML which could cost the respective companies millions in lost (or gained) revenue. Keyword could. The people who found these bugs needed some clickbait so they made some speculation of their potential impacts. So, let’s begin!

The first such bug was found by Jason Grigsby, a web developer with hungry parents craving Chipotle. Rushing to pay for lunch before his parents did, Jason hoped to use autofill feature to fill in payment details which resulted in cryptic error messages. He eventually filled in the form before his mother came around with her credit card, giving him more good boy points.

With his good boy points, he decided to investigate. He discovered that Chipotle’s website was built with Angular which used the ui-mask module to limit the characters that can be entered into the payment form. This prevented the date from being entered in properly since the mask was set up to detect just two characters, ignoring subsequent characters. So entering 2023 would enter 20, ignoring the 23.

A rather contrived solution given that HTML5 has built-in validation, relevant to this is maxlength which limits the number of characters can be entered. Autofill is smart enough to realize that it’s a year field and use the last two digits of the credit card expiry date… year.

Jason estimates that Chipotle will miss out on $4.4 million a year from this missing attribute. Given 1 million transactions a week, 0.05% of people who might run away due to the faulty form, that results in 5,000 users abandoning their order.

With an average purchase of $17 an order, that results in $85,000 a week which becomes $4.4 million over 52 weeks— a year. Should probably be slightly more at $4,435,178.57 given that there are actually 52.17857142857143 weeks in a year. Slightly more due to the earth’s rotation, tides and whatnot.

All because of a missing maxlength=2.

That successful clickbait inspired more clickbait. Adrian Roselli, an accessibility expert, used it as an opportunity to make the business case for accessibility. He recalls a time where he was trying to fund a project on Indiegogo only to be met with a screen reader message “edit on autocomplete” and for autocomplete to be impossible since the form’s <label>s had no for attributes to point to the respective inputs, which in turn had no id attributes. That resulted in his name, Adrian Roselli, being used as the Full Name, Country, Street Address, Optional Address Line 2, City, Post Code and Phone Number since the browser was confused. Adrian filed a bug report and it was supposedly fixed…badly!

Now the form was much harder to use due to multiple accessibility issues, least of which was conflicting ids.

Using an even rustier napkin maths due to the difficulty in counting screen reader users, He worked from a base of 2.3% (the number of blind people in the US) and estimated non-visually impaired screen reader users and voice users to get 3%.

With Indiegogo raising about $596 million between April 2018 and April 2019 and the 3% of screen reader users not being able to fill the form, projects missed out on $18 million. As for Indiegogo, they missed out on $921,665 they would have gained from their 5% cut. Again, it’s an exaggerated loss but a loss nonetheless.

So far I’ve mentioned cases where millions could be lost. What if bad HTML could save millions? I’ve got a story similar to this to share. Since it was a support issue, there’s no millions of dollars to lose since that loss is already included in the support team’s budget.

Ba-dum Tish!

Not belittling support— they work hard in spite of poor pay and a toxic work environment. Rather I’m satirizing the glib attitude in the software industry towards “non-essential functions” like support, testing etc.

Where was I? Right, the bug. I was charged $60 for Xbox Live which I forgot to cancel. Needing that money, I went to Xbox’s support page which after doing the whole “we’ve already solved your problem, go away” prompt, there was the option to get called once support had time, but a required field was disabled, preventing me from submitting the request.

Had I been unfamiliar HTML, I’d be SOL but being the overconfident sniveling little smartass I am, I inspected the HTML and removed the disabled attribute and the form worked.

Mmm…

Not sure if they deliberately disabled it and forgot to validate it on the server, but I was glad to get my $60 back.

So there you have it. I’ve provided two cases that show why it’s important to get your HTML right lest you lose millions later on. Then I provided a case in which bad HTML could save millions in support costs. Perfectly balanced as it should be.