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.

Really the only way to know if your filtering is working is by trying to access webpages you would expect should be filtered – this is NOT advisable. TestFiltering works by mimicking this, automatically and invisibly.

When run from your device, TestFiltering attempts to access 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 assumes 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.

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://www.pornhub.com/testfiltering
• 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.