ibpalle

The cloud filter is indeed just filtering for the browsers that have the extension installed. Chrome and Chromium Edge are the 2 current ones on Windows. In order for it to be as effective as possible, some admin controls have to be implemented like the ability to run incognito or private modes for example. The documentation lists more examples of what needs to be disabled in order for the filtering to be more effective but at the end, only browser traffic gets filtered. Applications won't be. The trade off here is ease of use and configuration for external filtering, rather than having proxy settings enforced on a system, which also could be bypassed is users have any sort of privileged access on their device. You are not confused at all, the limitations you describe are real worries and needs to be addressed as much as possible. Once you have decided if the trade offs are worth it, you can decide if the cloud extension or another solution (forced proxy settings, enforced VPN etc) are better options for your use case.

I see. The link is part of a page, some resource getting loaded in the backend when the page is displayed, like a picture or advert in a section. Since this link was generated to fit a specific page, the link does not work on it's own, which is why you are seeing the result you see when you click on the link. The link does not make sense without the main page that requested that link. You can exclude the domain from generating notifications by running the report in the safeguarding section, find the link and click the exception button that shows when hovering over the link. Exclude the full domain, not just the specific URL. Depending on the amount of instant alerts you get it may be an idea to not have instant alerts for the Adult section. Often adult content reports give better context when looking at longer time periods to see if there is a pattern of behaviour. Adult content can generate a lot of hits so instant alerting may generate too much noise as it were. In general, if you have a lot of instant alerts coming in, I would recommend doing daily notifications for all categories but only instant alerts for bullying, suicide, abuse and radicalisation. Edit: To get a better idea of what was requested around the time the alert was generated, run the report in the web UI and click on the time and date. This will load a window where you can see what was requested before and after the alert was generated.

How are you getting these reports? Is it email from the safeguarding notifications or from the MMS system? How are you viewing them?

HTTPS inspection is needed if you need to block based on full URLs and keywords. Without HTTPS inspection all the filter can see is the domain. It could be you have an exclusion for the BBC in your config. Not certain where that would be on a Netsweeper.

Good idea to check if the user is actually logged in by looking at the user activity page in authentication. Often some content is excluded from auth in older setups so even if a user is banned, they would be able to access that content.

The temp ban does override the users group membership and places the user in the 'Banned Users' group so a block for the Banned Users group need to be in place. This also means that the web requests have to be authenticated so make sure it's not because the user is browsing unauthenticated.

I'll see what I can do.

The cloud filter clients are configured so traffic from the client is not intercepted by the onn-prem Smoothwall - ie, no double filtering. Smoothwall does see layer 2 but the web filter does not. Any device not on the same subnet as the Smoothwall wouldn't be visible re MAC address so it's not the right tool for the job when it coomes to Guardian. Logs can be viewed immediately on the client and generally after about 5 mins, on the on-prem or the cloud interface.

Best option for Chromebooks is our new cloud filter extension. It is part of your license so have a chat with your account manager and he'll set you up with a license and help for installing and configuring.

Not yet, currently still, the best way forward is to use Windows NPS with supported certificate setup for auth and Smoothwall for accounting.

This is the raw code that should be displaying the alert - for some reason the viewer is showing the raw text rather than interpreting it.

According to our blocklist team the method used for allowing a channel back then, no longer works. Instead the list of video or playlist IDs needs to be allowed like in the KB: https://kb.smoothwall.com/hc/en-us/articles/360002030930

Not to my knowledge I'm afraid. The channel front page can be allowed by using url patterns but once you click on a video to watch, the URL is just like any other video with no apparent way to tie that into the channel.

You need to enable SMTP auth and SMTP TLS. Use the full username as well so '[email protected]' instead of just username. Also be sure to save the settings before you try to send a test.

Try making sure QUIC is blocked at the firewall level - outgoing access to UDP ports 80 and 443. https://en.wikipedia.org/wiki/QUIC

Save settings on the DNS page - that restarts the DNS proxy.

This is the main reason for iDex, login scripts or RADIUS on BYOD. By making the identification/authentication of users happen in a separate process than the actual browsing to avoid issues with apps not understanding active proxy auth methods.

By software I mean anything that isn't a browser, using HTTP(S) - Things like Microsoft Office 365 apps that can't reply to a NTLM request. Microsoft updates. iTunes. The listgoes on an on.

The 407s are normal - basically when there is a request that needs authenticating, there will be 2 407s before the request is then again seen as a 200. 407s are proxy auth required. First one is 'I need to know who you are', 2nd is 'This is who I am' and then the request will be served. However in your case, a lot of these 407s are due to the fact that the software cant respond to a NTLM request. The correct way to fix those is to move away from using active proxy auth methods i.e. NTLM or Kerberos - these days it's not just browsers that use HTTP(S), everyone and their grandmother writes apps that use HTTP(S) but none of those apps are likely to have any support for active auth methods on a proxy. I would recommend using our iDex system instead for domain user identification. Raise a case with support or get your Smoothwall account manager to request an auth rework so we can assist in configuring this.

This may be due to QUIC traffic - QUIC is a protocol supported by Chrome which use UDP instead of TCP for streaming some web traffic. I would try blocking outgoing access to UDP ports 80 and 443 at the firewall level and also implement a content modification policy to remove QUIC header for eveything.

No changes on functionality - it was a backend issue that caused the pull and that has been corrected. Thanks for being patient.

The extension should work like before the pull. You will not need to do anything.

Correct. If you do not have a cloud filter serial (The one starting with UNC) contact your account manager and they will issue you one.

Connect For Chromebook Update: we've resubmitted an amended version of the pulled extension to Google. Awaiting their review process.

It is a pain, we are looking at what we can do. Would have been nice with a heads-up from Google but ...