Zero Networks Labs

The Chrome Bug That Cost Me Two Expensive Meals

Published June 04, 2020 by Benny Lakunishok

There’s No Such Thing as a Free Lunch, Unless You Find a Weird Chrome Bug


  • When downloading a file, Chrome may change the file extension to something different than the original file extension
  • I didn't believe this could be true and made a bet that it was a false positive from our development/QA side
  • I was wrong. It was indeed a bug on Chrome’s side
  • I lost and our VP of Research and VP Customer Success won two nice meals at their favorite restaurant

Programs Don’t Have Bugs, People Do

Things have been pretty hectic around here these past few months. In addition to dealing with a global pandemic, we were racing to complete a new tool, TrustMeter, which helps businesses assess their security posture and see just how exposed they are thanks to excessive network access.

So, it is easy to believe that in all the chaos a typo could have been missed. I was sure that was what I was looking at when I was reviewing the bugs opened by QA during one of our daily meetings (over Zoom). I was sure the notation was a mistake by the dev or QA team. In other words, it had to be a human bug, not a software bug. A simple mistake on our side was the most logical conclusion. I was so sure I was right that I was willing to put my money where my mouth was (which in hindsight may not have been so smart because it ended up costing me not one, but two meals at a high-end sushi restaurant).

But I’m getting ahead of myself. What does one thing have to do with the other?

This Bug Makes No Sense

Without getting into too many details about our tool, let me just say that part of the functionality of this tool is to generate an html report. If the user wants additional details, they can download them directly from the report (behind the scenes the browser is simply fetching a local file). To make the data easily consumable across platforms, we chose to save it in a simple CSV format. That way, any text editor can be used to view this data.

However, during testing, we found out that our innocent CSV file could not be opened correctly from Excel when downloaded from Chrome. A deeper inspection showed that the file was downloaded with the xls extension, instead of its original csv extension. “Probably another bug by the developer” is what I was thinking at the time. But after testing, re-testing (and rubbing our eyes), we realized that this was indeed something that was happening. And it was only happening when using the Chrome browser.

What Is Happening?

Actually, this relates to a “bigger” behaviour that happens on Windows - it is excellently explained in this Stack Overflow thread. In short, browsers don’t decide entirely on their own what is a file type; they also rely on the information in the HKEY_CLASSES_ROOT registry to determine the Content Type of that file. This may override MIME Types specified in the html document or in the HTTP header. Weird right?

But is this a bug? Well, for most browsers not really. They will simply download the file, and keep it as is. What is strange about Chrome’s behavior is that it takes an extra step of saving the file with the xls extension. This will cause Windows to treat the file as an Excel file, instead of a csv file -> which of course fails (miserably).

How to Reproduce?

You cannot reproduce this bug on all hosts, but it is easy to make a host “vulnerable” to such behavior. All it takes is to update the HKEY_CLASSES_ROOT.csvContentType to “application/”. Once saved, You simply:

  1. Create two local files "index.html" and "file.csv" right next to each other in the same folder
  2. Edit the "index.html" to contain:
<a href='file.csv' type="text/plain">click to download</a>
  1. Create any content for "file.csv"
  2. Open the html in Chrome locally, without a server, and click on the link

You will see "file.xls" as the downloaded file.

You can also reproduce this behavior by simply dragging and dropping CSV files into Chrome.

Of course, we reported this bug to Chrome, and they got back to us to let us know they are currently processing it.

Back to the Bet

If you’re thinking WTF? Then you and I were thinking the same thing. Before uncovering all this, I told our VP of Customer Success and QA, Polina, and our VP of Research, Sagie, “If this is indeed a bug in Chrome, then I will buy you both dinner at this expensive sushi restaurant" (top 5 in Israel IMHO). So, now, I am eating crow, while they plan to dine on sushi!

Elizabeth Setton, our software engineer, also joined the party, as she was the one that actually did the workaround for this bug.