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.
