Mouser Electronics confessed by email that they block Linux users. Then I found the same Akamai Bot Manager block on Home Depot, Hilton, Marriott, Macy's, and counting
Over the past several weeks a bunch of major retail and travel sites started throwing 403s and "Access Denied" pages at me. Stock Firefox on Linux (X11, amd64), no VPN, no automation, no scraping -- just trying to load a product page or log into an account I pay for. I use uBlock Origin, Privacy Badger, and DDG Privacy Essentials, but disabling all of them changed nothing. I presumed something was corrupt in my Firefox profile and built a clean one, but same result. It's not the extensions, or the profile.
It's Akamai Bot Manager scoring my browser as a bot.
After I filed a complaint, Mouser Electronics -- whose entire customer base is engineers -- told me in writing that
>the access was denied because the request originated from a Linux-based system, which triggered our security controls. These measures are in place to protect our platform from potentially unusual or unrecognized traffic patterns.
Their recommended fix was to "try accessing the website from a standard desktop environment (Windows or macOS)." OMFG, I was so livid!
Linux. An "unusual or unrecognized traffic pattern." From the OS running essentially all of their backend, Akamai's own edge, and most of the internet.
Why I care beyond annoyance
These aren't sites I'm scraping -- they're places I'm a paying customer:
- Home Depot: ~$6,500 across 101 orders over 7 years. I was 403-ed from the product page of an item I had already bought.
- Mouser: ~$2,275 across 23 orders since 2018.
- Hilton: roughly $7,000 over the last two years as a multi-year Honors member -- locked out at the homepage.
That's over $15,000 across these merchants, and the reward is getting treated as a bot and told to use windoze.
What's actually happening (technical)
Every one of these blocks carries the Akamai signature:
server: AkamaiGHost(orAkamaiNetStorageserving the canned denial page)- the Bot Manager cookie suite:
_abck,bm_sz,ak_bmsc,bm_s/bm_sc/bm_so/bm_ss,akacd_usbeta, etc. -- the full set varies by site config - my
_abckcookie scored~-1~ … ~-1~-- the "not validated / flagged" state
The scoring keys on signals a normal Linux desktop browser emits: TCP/IP fingerprint (p0f), TLS handshake (JA3/JA4 -- Firefox's ClientHello is distinct and far less common than Chrome-on-Windows), and the JS sensor payload. A residential Linux/Firefox session with an ad-blocker and no Windows-shaped fingerprint apparently crosses the bot threshold as a false positive.
This is also why toggling my privacy extensions changed nothing: uBlock, Privacy Badger, and DDG operate at the content / HTTP layer -- blocked requests, stripped trackers. The TLS ClientHello and TCP fingerprint Bot Manager scores me on go out identically whether they're on or off, because they live below the layer those extensions touch. The block fires before a single byte of HTML is exchanged -- before any extension could act on it.
The tell that it's identity, not behavior: on at least one of these sites, switching from Firefox to Chromium cleared the homepage 403 outright. Same machine, same IP, same human -- different browser fingerprint, instant access.
The sites I've found SO FAR (all reproduced, all with Akamai reference IDs)
| Site | Where it blocks | What they show you | Akamai reference |
|---|---|---|---|
| Mouser | search + product listings | admitted in writing (above) | -- |
| Home Depot | product pages | fake "Oops!! Something went wrong. Please refresh" | 0.ca25c017.1782592112.6aa539d |
| Hilton | homepage | "Hilton Page Reference Code" | 18.c925c017.1782596529.c66de76 |
| Marriott | homepage | "Access Denied" | 18.c925c017.1782593791.bd8d744 |
| Macy's | homepage | "Access Denied 403" | 0.c825c017.1782593557.15b9317b |
Worth noting: the Hilton and Marriott reference IDs share the same middle field (c925c017) -- that's the Akamai edge region serving my area, so the same edge node is issuing both chains' blocks. This is an Akamai-layer behavior, not these companies independently deciding to hate Linux.
For contrast: Best Buy, which isn't behind Akamai, works perfectly from the exact same browser. Same shopper, no Akamai, no block. That's the control.
How to check if it's happening to you
curl -sI -A 'Mozilla/5.0 (X11; Linux x86_64; rv:152.0) Gecko/20100101 Firefox/152.0' \
https://www.example.com/ | grep -i '^server:'
server: AkamaiGHost means the site is Akamai-fronted. But a curl -I of the homepage often returns 200 -- the bot rules frequently fire on deep links (product pages) or a full browser navigation, so the real test is hitting an actual product/account page in your normal Firefox session and watching for the 403 + _abck=…~-1~ in devtools.
What I'm doing about it
- Complaining to the site operators, not Akamai -- they're the Akamai customers, they can pressure Akamai to fix their shit, or drop them -- money talks. Quoting the Akamai reference ID lets their engineers pull the exact request from their logs, which kills the "we can't reproduce it" deflection.
- Filing data-subject access requests where I'm locked out of my own account data.
- Documenting the pattern publicly and getting it in front of the Linux community.
And to be blunt about the part that isn't technical: I'm fucking pissed. I've handed these companies five figures, on the OS their own servers run on, and a kernel I've spent countless personal hours contributing to, and the thanks I get is a 403 and a note telling me to go buy a Windows machine. If enough of us complain -- or move our money to vendors that don't treat Linux users as bots -- this gets fixed. That's a big part of why I'm posting.
If you're on Linux and you've hit unexplained 403s, "Access Denied," or "something went wrong, please refresh" loops on big retail/travel sites in the last month or two: check the server header and your _abck cookie before you blame your browser. I'd like to know how widespread this is -- drop the site and the Akamai reference ID if you've got one.
Appendix: the full Mouser email
(Personal address redacted; corporate addresses left intact.)
> From: Customer Support <support@mouser.com> > To: my.email@address.com > Cc: web.experience@mouser.com > Subject: Fwd: Customer Akamai Form > Date: Wednesday, June 24, 2026 11:36 AM > > Hi, > > Thank you for reaching out to us. We apologize for the inconvenience you experienced while trying to access our website. > Based on our review, the access was denied because the request originated from a Linux-based system, which triggered our security controls. These measures are in place to protect our platform from potentially unusual or unrecognized traffic patterns. > > To resolve this issue, we recommend the following: > > * Try accessing the website from a standard desktop environment (Windows or macOS) > * Use a different browser or open the site in incognito/private mode > * Ensure your browser is updated and supports cookies and JavaScript > * Avoid using any automated tools, scripts, or uncommon configurations while accessing the site > > Sincerely, > Web Experience Team, > Mouser Electronics, Inc.
EDIT: Fixed the original email (was missing bullets) and corrected my user agent -- it's vesion 152