This article explains how the Smoothwall Filter can prevent users from accessing objectionable content through a search engine, and how they can be modified to force SafeSearch.
Search engines allow users to search for multiple sites. They can return content that was not initially searched for (through search suggestions). They also often load a snippet of each website, which may trigger the content filter. A user’s search terms may also be useful for identifying users trying to bypass the web filter by using similar, but non-objectionable, search terms.
Search Term Extraction
The Smoothwall supports extracting search terms from URLs. These are analyzed by the dynamic content filter in the same way that regular web pages are. This allows searches to be categorized and reported upon. This is applied to all major search engines (Google, Bing, Yahoo), and certain other services (for example, Flickr, Shutterstock, Liveleak). It is also not a feature that needs to be enabled, however it can be disabled by either whitelisting a domain, or due to it being served over HTTPS without a decrypt and inspect policy in place.
A blockpage will be displayed if a user’s search term is categorized against a blocked policy, as it would with regular web content. If a search term is not blocked by a policy, the results page is still scanned by the filter, and a block page may be displayed as a result of this.
To ensure that search term extraction is working on a search engine:
- Ensure the domain isn’t currently the target of a whitelist policy.
- If the domain is served over HTTPS, then ensure that a HTTPS decrypt and inspect policy has been enabled.
- Search terms should now be showing up in the search term reports. To see these in realtime, go to Reports > Realtime > Search terms.
Force SafeSearch
Users browsing via the can be forced to use SafeSearch by default. There are two content modifications available which will achieve this:
- URL Modification
- Cookie Modification
URL modification works by appending a short string to the end of each query to a given web service. Each service uses a different flag to check if SafeSearch has been enabled. Bing for instance, appends &adlt=strict to a request. In the web filter logs this will show up as:
https://www.bing.com/search?q=dog&go=Submit&qs=n&form=QBLH&adlt=strict
There are two ways in which search engines use cookies to identify users that have requested to only see filtered content. This is either done by a cookie containing a user ID or a cookie containing an explicit reference to the SafeSearch.
Unfortunately only the second scenario presented here can be effectively modified by the . This is done by rewriting a cookie to show that the user has requested not to see inappropriate content.
Both of these methods are included in the content modification Force SafeSearch.
SafeSearch via CONNECT header
Google provide a method to force SafeSearch across all their domains. By rewriting any requests to google.* to forcesafesearch.google.* all requests are treated as though SafeSearch is enabled. This cannot be unset by the user as well. Finally, it does not require a HTTPS decrypt and inspect policy to be enabled. This content modification works for: Google, Bing & Pixabay. To learn how to enable SafeSearch, see our knowledge base article, Activating SafeSearch on All Major Search Engine Websites Using Content Modification.
Instant Results Removal
Certain search engines provide search suggestions on a per character basis. These cause problems as these search suggestions aren’t necessarily what the user was searching, and this can lead to the user being flagged in safeguarding reports. This can be rectified by blocking the URL from which instant results are loaded.
To remove search suggestions from Google:
- Create a new web filter policy, where the What is Search Suggestions, and the Action is Block.
- When typing in the search bar in Google now, you should no longer see suggestions appearing underneath the search bar.