Hi,
The 'blogs' tab is generating just three pulsing circles again. I've tested on home and mobile internet connections, with two different browsers, and I see the same problem.
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.
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.
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.