Filtering Rationale

Opendium systems use multiple technologies to categorise websites, including, but not limited to, our proprietary real time content analysis engine and a large database of web addresses. A selection of predefined categories are included, which receive hourly automated updates. Our customers are in complete control of their filters and are able to modify the predefined categories or create new custom categories from scratch.

Customers can choose which categories of website are blocked, how sensitive the filters should be, whether to disable the web access for repeat offenders, if Safe Search should be enforced on common search engines and a wide array of other options. These settings can be applied globally, to specific networks or locations, user groups, workstations / devices, individual users, or any combination of the above through our unique Virtual Groups system.

Rather than relying exclusively on a database of known websites, our proprietary content analysis engine provides protection even for dynamic sites and social media - vital to safeguarding on the modern web.

The filtering rationale for each category is shown in the category's description on the Opendium system's Filtering Categories page.  We are always interested in feedback such as whether a category's rationale meets expectations, and what our customers hope to achieve through the use of each category.  Any comments should be directed at our support team.

HTTPS decryption

Active HTTPS decryption provides protection even for encrypted web services and allows more detailed safeguarding reports.  Where full decryption is not appropriate, a "zero configuration" passive HTTPS inspection mode can be used which offers a reduced level of filtering and auditing.

To provide the best balance of privacy, safety and compatibility, several predefined overrides are included and receive hourly updates (e.g. Disable HTTPS Decryption and Essential Services). These disable HTTPS decryption for certain types of web service and at their discretion, customers can exclude additional web sites from being decrypted.  Services not decrypted by default include:

• banking services, online payment gateways and other services which require enhanced privacy;
• services required for core software, such as software updates, anti-virus updates, certification authorities, etc.; and
• web services which are incompatible with decryption, for which filtering is not significantly impacted.

"App:" overrides

We believe that applications that schools would like to block should be blocked by virtue of being in an appropriate Filtering Category, rather than because of compatibility problems. To this end, when we discover a compatibility problem, we try to add suitable criteria into our pre-defined overrides, such as Disable HTTPS Decryption and Essential Services, to allow that application to work.

However, there are some applications for which maintaining compatibility would significantly impact the system's ability to filter other content. To allow these applications to be used, we provide overrides which have names prefixed with "App:" so that schools can make a decision on a case-by-cases basis as to whether or not to accept the associated impact to filtering in order to allow the application to work. These overrides can be applied globally, to specific networks or locations, user groups, workstations / devices, individual users, or any combination of the above through our unique Virtual Groups system.

Our decision making process is:

• If the application itself can be filtered, it should work by default.
• If the application cannot be filtered, but allowing it to work does not harm the system's ability to filter other content that would normally be filterable, it should work by default.
• If allowing the application to work would harm the system's ability to filter other content that would normally be filterable, the rules allowing it to work should be shipped in a separate override.

For example, users who access Twitter through a web browser are protected by Opendium's real time content inspection, but the Twitter app is designed not to allow systems to inspect its content. In order to allow the Twitter app to work, content inspection must also be disabled for the Twitter website. Since this harms the system's ability to filter content that would normally be filterable, the rules to allow the Twitter app to work are shipped as a separate "App: Twitter" bundle, which is not enabled by default. Schools can therefore read the description of the bundle, understand the impact of enabling it and make a decision for themselves.

Reporting miscategorised websites

Our predefined categories are designed to be most accurate when their sensitivity level is set to 5 out of 10.  Sensitivities can be raised or lowered at the customer's discretion.  However, customers should be aware that using high sensitivity levels significantly increases the risk of over-blocking.

When a web page is blocked, the user is given the option to report that it has been miscategorised and the reports are manually reviewed by our staff. If our staff determine that the reported web page should not be considered to be part of the category:

• Where possible, we will exclude the web page itself from the category.
• We will review the website with a view to exclude the entire website from the category where appropriate.
• Regardless of the sensitivity set by the customer, if the miscategorisation would still have happened were the sensitivity have been set to 5, we will review the real-time content analysis which was performed, with a view to adjust the filtering criteria to reduce miscategorisations.
• If the miscategorisation was the result of the category's sensitivity having been set excessively high, we will usually not adjust the real-time content analysis filtering criteria.
• We may choose to add the web page, or the entire website, to alternative filtering categories.

We are always interested in feedback regarding web pages which have not been correctly categorised and encourage our customers to report any such problems to our support team. If our staff determine that a reported web page should be considered part of a category:

• Where possible, we will add the web page itself to the category.
• We will review the website with a view to add the entire website to the category where appropriate.
• Regardless of the sensitivity set by the customer, if the miscategorisation would still have happened were the sensitivity have been set to 5, we will review the real-time content analysis which was performed, with a view to adjust the filtering criteria to reduce miscategorisations.
• If the miscategorisation was the result of the category's sensitivity having been set excessively low, we will usually not adjust the real-time content analysis filtering criteria.
• We may choose to add the web page, or the entire website, to alternative filtering categories.