Frequently Asked Questions

TestFiltering.com is an online utility that safely tests whether your internet connection is blocking certain types of harmful or illegal content. Specifically, child sexual abuse material, terrorist related content, pornographic content and pages that contain profanity.

Without our service, the only way to know if your filtering is working would be to try and access webpages you would expect should be filtered (this is NOT advisable). Our service can do this on your behalf through test pages that have been inserted on to the various block lists that are used to block illegal and inappropriate content, automatically and invisibly.

When run from your device, TestFiltering attempts to access these test webpages. If TestFiltering is not able to access the test webpages from your device, it assumes they are blocked and hence filtering is likely to be active.

If, however, it is able to access these test webpages, it concludes that your filtering is not active and displays a warning or failure.  Please note the testing process happens in the background and is not visible to the user.

We currently test against the IWF URL list, and the UK terrorist content (CTIRU) list. These test webpages are integrated into the IWF and CTIRU URL lists distributed to ISPs and filtering providers. If these test webpages are accessible, it assumes that the respective URL list are not active for your connection.

We verify if pornographic websites are accessible through a test page hosted on an adult website. We host a page which contains offensive language to test whether your filter is blocking pages that contain profanities.

Our tests check to see if our test URL's are accessible, this is used as an indication as to whether you have a filtering system in place for each category of test. It does not indicate how effective your system is across all content or locations hosting that content on the internet.

No filtering system is 100% effective at blocking any type of illegal or harmful content, similarly our tests do not test every aspect of your filtering system, or every piece of content it could potentially block.

TestFiltering.com does not require you to enter any details to perform a test. However, by adding your organisations details, testfiltering.com is able to display a certificate for you to download for your records.

Your information also enables us to aggregate results to better understand filtering performance on a national level.

Some of the block lists are HTTP only and browser restriction prevent accessing unsecure pages from a secure source. Therefore the site must be HTTP only in order to be able to access the test pages.

If the tool shows one of the test URLs is accessible, we recommend you run the test on another device on the same connection validate the result. If you consistently receive failures, we recommend you contact your filtering or IT provider to report and discuss the result. 

Our system does not define how a filter should block content, it only checks the test webpages to see if they are accessible. If Test Filtering displays a failure or warning to you, then it is likely that your filter must not be blocking that category of content.

To confirm that the content is accessible, you can access our test URLs directly:

• Child Abuse Content: http://iwf.testfiltering.com
• Terrorist Content: https://ctiru.testfiltering.com
• Pornographic Content: https://testfiltering.pornhub.com
• Offensive Language Test Page: https://swearing.testfiltering.com
• Real-Time Content Filter Test Page: https://dynamic.testfiltering.com

If you can see our test pages, then your filter must not be blocking the relevant category of content. This will enable you to diagnose the issue with your system.

Most Internet Service Providers (ISPs) provide controls to turn on network-level filtering. More details about how to turn filtering on at home or on mobile devices can be found on the Internet Matters website.

For business, or education connections, the same principle applies: any internet connection can be filtered. However, the way this can be enabled varies with the type of configuration you may have in place. This guide for UK schools from the NEN provides an overview of how to apply filtering.

Businesses should consider implementing filtering so that employees cannot access illegal or inappropriate content from a work device. This will, additionally, protect employees from other harmful online content or accidental exposure to harmful content that could lead to legal action.

Content filtering can be applied to devices: at network level, on premise, or cloud-based. Speak to your IT provider for support about activating, or changing, content filtering setting.

You can also purchase on-device protection for your business from Edtesa.

Schools should speak to the ISP and IT support organisation about having network level filtering in place, they can also purchase endpoint protection from SWGfL.

Businesses can purchase endpoint protection from Edtesa.

Filters work in a variety of ways, either through DNS or IP based filtering or through more invasive filtering where the content of your requests is read and filtered.

Content filtering is significantly more difficult due to current and emerging encryption protocols that enable the client to verify the sender before reading content.

DNS or IP based filtering is much easier, but is easier to circumvent, and relies on pre-defined block lists. Incorrectly implemented lists is often where our service finds problems with filtering services.

When a client requests a website, a Domain Name System (DNS) service is used to translate the domain requested (e.g. www.testfiltering.com) to an IP address (e.g. 77.68.10.165). By intercepting those DNS requests and looking up the domains against a pre-defined database of blocked domains, the service can filter the requests and return a different IP for blocked domains.

This is the simplest way to setup a filtering service, but also the easiest to get around, because the client only has to change DNS provider in order to circumvent the filter.

Packets of internet data are sent with a destination address specified as an IP address, this enables the nodes of the internet to route the packets to their destination. By reading the IP addresses before the packets are sent, they can be filtered against a pre-defined list of IP addresses.

Sometimes multiple websites are hosted on the same IP address, often a protocol called Server Name Indication (SNI) is used to identify the specific domain that is requested, even if the rest of the request is encrypted (i.e. sent over HTTPS). This can be used to check whether the request is being sent to any domain you want to block, which can then be filtered.

Where encryption is used and the domain name is not presented using SNI, it can be assumed that only one website is hosted on the IP address, in this case where the IP address matches the IP of a domain on a pre-defined block list, the request can be filtered.

The two previous methods rely on sniffing network packets to determine the server or domain level destination, in order to filter specific URLs the filter needs to be able to see the header of the HTTP request.

For unencrypted traffic (using the HTTP protocol) this is as simple as reading the headers or body of the request and filtering requests as required. For encrypted traffic this is more problematic, as the contents cannot be read without decrypting the request.

Encrypted requests work in a triangle, where there is the client, the destination server, and a root certificate provider. The client requests to connect with the server who sends an SSL certificate, this certificate will be cryptographically signed by a root certificate authority, who’s certificate will already be on the client machine. This enables the client to verify that the certificate comes from the destination website, and has not been swapped for another certificate.

For networks where all the client devices are under the network’s control, a substitute root certificate can be installed on all the client machines. This enables the filter to be a ‘Man-In-The-Middle’ (MITM).

When the client requests to connect to the destination, they are actually connecting to the filter, thinking that they are connecting to the destination as the filter’s root certificate verifies that they are who they say they are. This enables the filter to intercept and decrypt the traffic as it flows across the network, and apply any filtering to the content it finds, such as blocking specific URL’s or pages that contain swearing.

More and more technologies are being proposed and developed to prevent many types of snooping, which filter providers rely on such as:

• Encrypted DNS – Requests sent to a DNS service use an encryption protocol which prevents the domain name or corresponding IP address from being read as it flows over the network
• Encrypted Server Name Indication (ESNI) – Where SNI presents the domain name in the encryption handshake, a public key advertised in the server’s DNS record enables the destination domain name to be encrypted in the handshake

These technologies will improve privacy for users, but hamper the ability of organisations to monitor and filter connections, which also protects users.

The free TestFiltering service enables you to test that your Internet Filter is blocking illegal, harmful, and inappropriate content.

TestFiltering+ builds on this to provide bulk automated and regular testing of your Internet connection to ensure that your filter is always working effectively, provide an audit trail of this, and to notify you if it fails.

The service connects your Chromium based web browser to a TestFiltering+ account, and then sends results from the TestFiltering service back to your account. You can then analyse the data in aggregate to investigate issues and gaps in your filter coverage. You can also export reports for auditing requirements, and setup notification and digest emails to monitor your filter over time.

TestFiltering+ is currently delivered through a Chrome browser extension, so any device or browser that supports installing our extension can be connected. For example, Windows, MacOS devices or Chromebooks will work with the service.

Devices running other browsers such as Firefox or Safari are currently not supported, along with any versions of Chrome that do not support installing extensions such as Chrome on Android.

We are currently working on porting the browser extension to Firefox and Safari, this will enable mobile devices running Android and iOS to use the automated service.

TestFiltering+ offers a number of ways to monitor and view the data that is collected:

• The dashboard gives an overview of results for the past week
• The Device Manager enables you to see the status of individual devices as well as access their test logs and see the results
• The analytics panel aggregates data enabling you to see your results over time, it offers a number of views and filters to segregate the data.

You will need a TestFiltering account, a subscription to TestFiltering+, and at least one internet connected device that has Google Chrome v88 or higher (or other Chromium based browsers that have access to the Chrome Extension Store) to be able to automatically test your internet connection.

All devices are connected to a TestFiltering account, this enables you to monitor the status of your devices and networks and get alerted when tests fail.

Go to the account registration page, and create your login details, select your school, and agree to the terms of service. You will now be able to access your new account.

Once you have registered an account, you will be able to subscribe to the TestFiltering+ service, from your account dashboard you can click the “Subscribe” link in the dashboard, from here you can procure the service, selecting the number of devices you wish to connect.

Our service is charged per device, per year. Access current pricing on the TestFiltering+ page.

Yes, if you want to centrally monitor multiple sites from a single account, then this can be done with the current service. We do not currently offer logins that have a restricted view, or logins that have overview of multiple accounts.

To connect a device, go into the Devices Manager. You must also have the Chrome Extension installed before you can connect a device.

Just click the Add button and enter a device name, the extension will then trigger a toast popup to tell you that the device is connected.

The device will now start collecting telemetry, you can monitor individual results from the Results tab associated with each device in the Device Manager.

There are multiple deployment mechanisms that can be used, depending on your environment (For example Microsoft InTune and Google Admin Console).

When the extension is deployed through your deployment mechanism, you must deliver it with your Account Enrolment Key inserted into the local storage for the extension.

Find out more about auto-deployment and generate your Account Enrolment Key on the Auto Device Enrolment page.

The extension has a different colour icon depending on the status of the service on the device:

• Black – The device is not connected to the service, or no tests have been run
• Green - The last test run was successful
• Orange – One or more of the tests on the previous run was not successful

If you cannot see the status of the extension on the toolbar, you can go into the extensions manager and then pin the extension to the toolbar. You can also click the icon on the extension to see more status information.

To get notified by email of your service status you must setup a notification in the Notifications Manager. There are two types of notification: a Flash Alert, or a Digest Email.

A flash alert will send you an email immediately when an unsuccessful test is recorded. A digest email will send you an overview of your test results either daily, weekly, bi-weekly, or monthly. The email will be sent to you on the selected schedule at the same time as you add the notification.

You can deactivate devices through the Device Manager by clicking on the device you wish to remove, and then clicking the deactivate button on the toolbar. You will then be asked to confirm the device deactivation.

If the device is yet to receive any telemetry, then the device will be deleted, otherwise it will be archived so that you can still access previous results. Deactivated devices do not count towards your device quota.

You can view results in two locations:

• In the Device Manager, you can view the logs from individual results for each device
• The Analytics Report gives you an aggregated overview of your results, grouped by several different metrics

The Analytics Report presents your results grouped by several metrics, and enables the results to be filtered by those metrics:

• Tests – See your results grouped by test, and show results for only certain tests
• Dates – See a list of results grouped by day and specify date ranges
• Networks –results will be displayed grouped into each network, enabling you to see or filter by where the results are coming from
• Devices – See results per device, and refine the interface to view specific devices
• Providers – Group and refine results by the network provider name

We have provided a Network Manager to enable you to specify the IP ranges of your various networks, this will allow you to segregate your results into named locations so you can see where gaps are.

The magnifying glass icon in the top right hand corner of the Analytics Report will open up a selection of controls for filtering the results, enabling refinement by timeframe, device, network, and provider.

A PDF export function is provided in the Analytics Report, enabling you to export the current view as a PDF document. You can also export the raw logs of each device from within the Devices Manager as a CSV file.

Great work! All your devices are passing test on an ongoing basis. Have you got enough devices testing to ensure that all configurations are covered?

TestFiltering is only one tool to help you with your wider safeguarding, clearly if all your devices are passing, you must have a filtering solution in place. But it is also critical to ensure that all the features of the filter are enabled such as decryption, and your have robust monitoring policies in place.

Find out more about best practice with your filtering and monitoring provision through the advice offered by the UK Safer Internet Centre.

Firstly check that you have the extension installed, and that your account has available devices in the quota, also that your device is connected to the internet, and that testfiltering.com is not being blocked by your filter.

If you have the extension installed and when you add the device, the extension presents a toast popup indicating that it could not connect, please contact us through the contact form and we will help you troubleshoot the issue.

There are several things to investigate when a device fails a filtering test, firstly you need to gather some information about the device that will help you understand why it has failed:

• Which device it is?
• Where was the device when it failed (e.g. at home or in school)?
• Who was using the device when the failure occurred?
• Which filtering mechanism should have been applied to the device when the failure occurred?
• How is the device managed (e.g. MDM)?
• Has the device been tampered with?
• Are there other devices on the same network that are also reporting failures?

With physical access to the device, you should then be able to determine where the failure occurred, which could be one of the following:

• The filter is not applied to the IP address or network where the device experienced the failure
• The wrong policy has been applied to the device or user or the default fallback policy is too unrestricted
• The browser extension that is facilitating the on-device filtering is not functioning correctly or has been uninstalled
• The device has been compromised, or a VPN has been installed, causing network traffic to be routed around the filter
• The filter is not configured correctly or has failed