Poxate

Published June 17, 2026

Why THD Lite is still Down

Hello, it's been 2 weeks and THD Lite is still down and I'm still trying to figure out how to solve it. I've been swinging on this issue every day since my first announcement (14 days ago), but it's proving to be more and more difficult.

Today, however, I'd like to go more into depth on what specifically is causing this, so that you all know why it's taking so long, and what to expect. I also want to explain this and apologize for those who donated recently, as this issue coincided with the moment I started asking for donations (although it's not the cause).

I've split this up into two parts:

TLDR

Home Depot uses Akamai for security and protect against AI and bot scrappers. However, Akamai or HD is buffing up their protections, and THD Lite is unfortunately getting caught in the crossfire, and it's very difficult to get out of.

Brief explanation of how THD Lite works

In order to make a good browsing experience, software engineers must develop for users who have two things:

  1. Slow Devices
  2. Slow Networks

The THD Lite App solves the first problem by being a highly-performant and minimal application. This is why I built an app instead of a website, because mobile apps have finer control of our application's memory and cpu consumption.

However, THD Lite App cannot give you fast internet. So, to get around our super slow networks, THD Lite avoids communicating directly with homedepot.com. Instead, it communicates with the THD Lite Server.

The THD Lite Server solves the second problem. You see, Home Depot returns A LOT of information, and that takes a lot of time to download unto our sluggish 1mbps data plan, but is nearly INSTANT on my 500MBPS ULTRA_LOW_LATENCY gigachad server. So, THD Lite Server will browse the data for you, remove the unneeded bits, compress as much as humanely possible, and send that small little packet back to you

Overall, it looks like this:

  1. You search for drills on THD Lite App
  2. THD Lite App asks the THD Lite Server for "drills"
  3. The (blazingly fast) THD Lite Server asks homedepot.com for "drills", and gets a huge response
  4. THD Lite Server cleans up the response, minifies it, and compresses it into a very small small response
  5. THD Lite App downloads this small response of data, and presents it to you

So why is THD Lite down now? (for non-developers)

Because the THD Lite Server cannot communicate with homedepot.com anymore. That's the main gist of it.

You see, homedepot.com and practically every website in the world is getting inundated with a flood of bot traffic, and this is getting 10 times worse with the advent of AI scraping. Website owners are trying to protect themselves by anti-bot protection systems that verify that you are a real human being using the site.

Real humans (for the most part) are getting by just fine, but not THD Lite, not anymore. As these systems get better, it gets harder and harder to bypass bot detection to keep a service like this up.

There are still ways around it, and I'm currently working on it, but it's involves some reverse engineering that I'm not going to explain now.

So why is THD Lite down now (and why is it so unreliable)? (for developers)

Just like how our chemistry teachers used helpful (albeit inaccurate) graphs of neutrons circling in a perfect orbit around the nuclei, all of the above is a oversimplified explanation of how it works. So let's just get some things straight.

First of all, THD Lite Server doesn't directly call homedepot.com and browse the UI, that'd be monstrously slow and inefficient. No, it directly communicates with HD's GraphQL API.

When I originally started 7 or 8 months ago, just connecting to this API with a HTTP2 transport and little flicking around with your TLS HelloID and Request Headers was good enough to get a successful response from HD.

Then, about 2/3 months later, THD Lite started failing on some requests. I'll open the app and it works, but then I search and it failed, and then refreshed and it worked. It was in and out. HD was saying "Generic Errors", which I learned is key for, "not authorized". I eventually figured out that it now wanted a bm_s cookie.

With a little tracing, I figured this bm_s cookie came from opening the Home Depot's actual website in their response cookies. So, on app initialization and every hour or so, my server would call https://www.homedepot.com, retrieve and save this bm_s cookie. I then used the latest bm_s cookie to fetch products and such.

Couple months later, the errors are coming back up. Sometimes it failed with not authorized, sometimes it failed with a broken protocol or something. The issue turned out be that with TLS communication, you need some HelloID, and I used a random HelloID circling between Firefox, chrome, go, etc. To fix this latest issue, I just stuck with Chrome's latest HelloID.

If you think you know TLS, read this: The TLS Handshake -- everything that happens to get that coveted padlock 🔒

Now! The walls have gone higher than ever before. Insurmountable. In order to have the coveted bm_s cookie, it now requires:

  1. Opening https://www.homedepot.com
  2. Running JavaScript that performs hundreds of tests on your browsers
  3. Sends those test results to an API that decides if it's real human using the page
  4. (hopefully) Retrieve a usable bm_s if that API succeeds
  5. (unfortunately) Get an error page if that API fails

Of course, this happens silently and pretty quickly in the browser. And yes, even if I opened a browser from my code, the script knows how to check if that browser is powered by a bot (puppeteer or playwright).

So now I find myself reverse engineering a massive 440kb script, which will take quite a while unfortunately. But it's fun though!