tom_newton

What was your issue in the end @5nowman?

You will be pleased to note we do now offer whole of device filtering and monitoring - although I would still recommend applocker, as whole of device filtering is never as accurate as in-browser filtering, where you can get access to all the content.

You can find the odd content filter that's capable of looking in both words, and images i google docs. If your current filter supports regex, you might be able to find a regex to match document share URLs for 365

I think automatic VPN with no split tunneling is probably your best bet. That, I am sure is something forti users do all the time Alternative: use some family filter software like Qustodio. Arguably a bit more work for the DSL checkig an individual's report... but all depends what you have available to you [next time you are renewing, think of us - this would be a 2 min job in the SW filtering world]

In fairness we were a bit slow in making sure everyone had the right response to give people, largely because we wanted to know the facts. In the spirit of "never waste a good emergency", this surge of captures has definitely lead to some great improvements in our process already

As promised things are back to normal: as of this morning there was nothing older than 22 minutes in all bar one category.

Some of you may be interested to try Smoothwall monitor which will pcik up what students have typed into AI (it's a bit more bread reaching than just redirecting gemini to a different frontend... still works if the students find, for example, an AI support bot to talk to)

Haha, we probably would throw that away anyway (very few "long numbers" are actually predictive of... anything really, and some of them are credit cards, social security, bank deets, etc, so we bin a lot of that sort of data!)

I think the fact that folks notice when there are delays is indicative of the fact that normally, there simply aren't! We also have some pretty rigorous tooling to prevent capture of pii.

We have experienced some temporary delays on lower severity categories. But normal service will resume as of tomorrow. The reason for the delays is two fold. Firstly, AI has increased both the volume of complex alerts and the time our moderators need to assess them. Added to this, we are deploying a new, higher-sensitivity rules engine to identify a broader range of risks (including those originating from AI) with greater accuracy. Both factors have driven a rise in alerts, which in turn has created some temporary delays while our capacity scales to meet demand. Critical alerts continue to be handled with urgency and have not been affected. And all level 5 phone calls are being made as soon as the risk is identified, as normal. We have significantly expanded our moderation team and recruitment is actively ongoing. However, this is specialist work and recruiting the right individuals and training them to the standard required takes time. Standards in human review are critical and we will not compromise on this. We expect to see a return to normal service by Thursday 21st May. Happy to answer any other questions where possible.

Re: the CPOMs integration getting time of alert, rather than time of incident - thats going to be fixed soonish, I am told. Understand how that might be frustrating. We have delays at the minute - I'm going to defer to a more formal response, rather than my usual off the cuff responses on here, this is a measure of how seriously we take this.

I would settle on one DNS provider for now, and see if that helps

Very odd. I will have another poke around.

OK, it is devinitely a DNS issue for me with behaviourwatch, although whatever I tell curl to use doesnt help, if I do the resolution manually it is lightening fast

That was from my home ISP, Andrews and Arnold. I've asked a few folks to test from their ISPs but had no repsonse yet

OK, we are almost certainly at that level - is there someone who is a DNS wrangler in your school?

Additionally different people use different DNS servers (most folk just use their ISP) and you get to a different DNS server based on your location due to the anycast nature of their IPs (8.8.8.8 for me is not the same endpoint as it is for you). I would strongly suggest going to 8.8.8.8 in your Smoothwall's DNS page, see if that sorts it. Or it might be upstream DNS in your AD if you are AD and transparent proxy.

If you could lay out your exact issue here @SeeFights or DM me a ticket I might take a stab at working out the issue

OK, I find from different ISPs behaviourwatch has no issue. My home Andrews and Arnold is horror, from one of our boxes in google cloud, no worries. Suspect they have routing issues

@SeeFights there isn't a Smoothwall problem in this thread as I see it so far: happy for you to DM me your ticket number. The arbor/raven issue is 100% DNS. The behaviourwatch issue is, to my mind, a behaviourwatch problem. I am seeing ~15 seconds to download a tiny gif from their site.

Unlikely to be a DNS issue with that one - as here you can see a range of servers give the same answer, and quickly

FWIW I get a minimum 5 second delay getting to gb6.behaviourwatch.co.uk - this is through a non-smoothwall connection, and consistent over multiple runs

@5nowman Smoothwall doesnt redirect to anything - it will use the DNS resolvers you tell it to use. 8.8.4.4 is the secondary to 8.8.8.8. You can also try quad9s (9.9.9.9) as an alternative, although that's a PDNS so will sometimes block stuff Edit - if you have a ticket # I can ask one of our engineers to take a look at yours in the same way as Alan did for @toffee_paul

There's nothing we have particularly changed. One of our 3rd line support engineers suggests there's an issue with virgin's DNS (he referenced this thread, I presume he's working on that ticket, I have been in meetings all aft and not looked jsut yet). I also have a whatsapp from one of our more technically adept partners who suggest that they had a similar issue, and that was down to using cloudflare's DNS over google's.

Bear in mind that if you are using smoothwall as a proxy, the DNS requests will be made by the smoothwall - that could show up dns issues where you believe there are none