'Blogs' tab is sick again

Hi all,

At time 21:05 UK-time 29th Sep, the blogs tab failed to load again (when using DSL), on my laptop. (EDIT: it's now 21:16, it's failing for ten minutes at least).

As soon as this occurred, I switched off the WiFi connection on the mobile, and tried browsing to the Blogs tab using mobile Chrome. I see the same issue, so it can't be security measure related. 

I used the whatismyip website to confirm I had a very different IP address (86.xx.xx.xx on laptop, and 148.xx.xx.xx on phone).

Please can this issue be re-opened, because it doesn't seem to block on IP. I can supply the IP addresses if it needs to be checked against any log.

Hi all,

At time 21:05 UK-time 29th Sep, the blogs tab failed to load again (when using DSL), on my laptop. (EDIT: it's now 21:16, it's failing for ten minutes at least).

As soon as this occurred, I switched off the WiFi connection on the mobile, and tried browsing to the Blogs tab using mobile Chrome. I see the same issue, so it can't be security measure related. 

I used the whatismyip website to confirm I had a very different IP address (86.xx.xx.xx on laptop, and 148.xx.xx.xx on phone).

Please can this issue be re-opened, because it doesn't seem to block on IP. I can supply the IP addresses if it needs to be checked against any log.

Was failing for me at that time as well.

Thanks for confirming! I guess it can't be the automated defence stuff then. Plus it seems frequent (since it last sick no later than three days ago at least).

Pretty sure it was broken this morning as well, I can’t really remember.

shabaz said:

Please can this issue be re-opened, because it doesn't seem to block on IP. I can supply the IP addresses if it needs to be checked against any log.

I'm also not convinced we've definitely identified the problem, but it's definitely something more server-side related.

Though we cannot necessarily show everything 'behind the curtain' to how the protections determine someone's being sinkholed regarding this, it would possibly work across different IP addresses, there's an element of fingerprinting that goes on.

That isn't to say that people shouldn't complain about it still happening, that's helpful, and to know what dates/times/timezones it happens, so thank you.

I've found you in the logs. I can see what has happened but I can't answer why it has happened.

It's based on a piece of content you both viewed which is throwing a false positive.

It's late now so I won't do it now, but in the morning I'll pull that module.

I've looked again today with a wakeful mind, and I can see what happened here, and made a small tweak.

Can you shout loudly if you get this again shabaz  & Andrew J 

Will do.  Makes us sound a little dodgy actually  : can you not explain more about what the issue is?

Awesome, will do, thanks!

Andrew J said:

can you not explain more about what the issue is?

A piece of content that is being viewed, is being assessed when it's being viewed by protection mechanisms.

Those protection mechanisms, are flagging it as a false positive against whoever views it.

The viewer then gets punished by the protection mechanisms, because it's incorrectly flagged as a false positive, even though it should be fine.

Dudley raised this with the vendor of the protection mechanisms because it shouldn't be behaving that way.

There's not a lot of decent fuzzy logic in these things it seems, in a world of dynamic IP addresses for example, the vendor might say "hey, just whitelist that IP address" and you turn around and go "Have you seen home IP addresses? when are they ever static?" which points out how silly they are.

Similar to false positives in content, "Oh just whitelist that content" Yeah, but, how about you change how it identifies the content instead?

And so it then takes time for the vendor to fix it, and while that goes on, Dudley removes or disables the 'module' in the protection mechanism to prevent the problem, all the while making the site a bit vulnerable, unfortunately, while it's removed.

Dudley had tried to change the settings to prevent it from triggering a false positive, sadly that didn't work on this occasion, and the symptoms of it ended up being pretty bad for anyone browsing the site.