Safe Content Filter Testing
Test URL and internet content categorization safely without using potentially harmful websites.
Avoid risky testing methods
There is danger in testing content filters. It is a common occurrence to add or update content filters, firewalls, proxies, Secure Web Gateways, or other web traffic categorization systems. Or one may turn up new clients on such, or add new users or workstations to the content filtering system. During those occasions it is important to test.
Sometimes this testing must occur around other people, in lobbies, at other peoples' desks, or in classrooms and libraries. Often the approach to ensure categorization is working is to attempt access to some well known disallowed site. However, if the filter is not working for some reason, you risk quite a bit when that website loads. It may be embarrassment or complaints, it may be innocent eyes, or it may be your job.
We offer safe simulation of an adult content site, but without any of the content. We have both a "Good Test Site" and a "Bad Test Site". The Good Test Site has no affiliation with, nor keywords or metatags that would get it caught by content categorization as a forbidden site. The Bad Test Site however, does have both metatags as well hidden keywords in the HTML source that should have it denied by content scanners. This truly tests the categorization of the system rather than having to manually set some unfortunate web site in your blacklists. Should you still need or desire to use blacklists though, you can know that neither of these sites will be used by your users for business or personal needs.
These two sites are small (less than 100k in size), and fast (linux, lighttpd, and php). Each site has a different background color that should also be colorblindness friendly. The background loads first and quickly so one can immediately see success or failure even if the images and words are slow to load. This is particularly useful in virtualized lab environments like Eve-NG or CML where latency can get rather high. There are also no external references (like CSS or an image server) so that everything comes directly from the server you are accessing, and is in the HTML on the page. This makes it easy to allow in firewalls if a testing environment is locked down, or NAT exclusions need to be hyper-specific.
The Cache-control HTTP header is set to "no-store" so if proxies and caches are playing right, these pages and images should never be cached. To verify that, the date and time are generated down to the second by PHP so that each request should present a completely new page rendering. To further test that, images are randomly pulled from a directory of about 300 images on each site.
These sites can also be useful for other testing schemes like general connectivity, load-balancing, etc, and work with both HTTP and HTTPS.
Contact Us
Contact us for all your inquiries