>Now we run automated tests to monitor server uptime and check server for problems every 30 seconds. Unfortunately automated test scripts were happily getting HTTP/200 replies while people using the Chrome browser were being told this is a scam business trying to steal their bank account information.

I was surprised this wasn't part of the lessons learned. But it seems the monitoring basically failed but that wasn't a lesson.

I feel like majority of uptime monitors are falling for this same trap. One of the reasons why for my monitoring service I choose to do full page load monitoring via Chrome instead of just a http request via Curl or whatever. Main reason, people care if the webpage loads or not. People care how long it takes for their webpage to load. Having a website respond in 200ms is great but if it takes 8000ms for all the JS to load and process your website is still slow. I get why sites are just doing curl requests because it's way cheaper but really you're monitoring one part of the stack while really caring about all of it. If your website starts producing javascript errors you want to know, etc.

[1] https://www.ootliers.com (The landing page and everything are terrible and I'm working on improving that)

It's funny you read it that way, you may understand it correctly but I came away with a different interpretation, that they allow-listed the developer's IP and returned good non-phishing-warning responses to the monitoring check, but not to end-users.

They said their test scripts worked but people using Chrome got an error. So I take that as in their scripts weren't using Chrome at all.

To be fair, I've not had this happen yet so I am going to try and find a site that chrome won't let me visit and see what happens when I visit it programmatically.

When that warning page is thrown, is a 200 returned? It could “load” ok, but be blocked by a flag for chrome that isn’t http flag. Total guess. Anyone have any insight on that page showing up?

After a bunch of searching I found a test URL. https://testsafebrowsing.appspot.com/s/malware.html via my Chrome script I get a 500. And when ignoring it in chrome manually it returns a 200 so the web url works.

This is totally an edge case I didn't even think of until I read that blog. Super happy that my monitoring approach picks up on it.

For others wanting to do the same I'm using chromedp. It does take up way more resources tho. I worked out I can do 90 per minute per 8-core 16gb server.

[1] https://github.com/chromedp/chromedp