In this article you'll learn how to configure Smoothwall Browser's Web Content Filter Extension for iPad (Smoothwall Browser v105.0.1 or later) to limit web browsing capabilities within other 3rd party and system apps. For brevity, we'll refer to it as the Filter Extension from here on.

This article is for v105.0.2 or later and is no longer accurate for v105.0.1.

The Problem

Smoothwall Browser is able to apply a rich set of policies to all web browsing done within itself using policies you configure via the Smoothwall Cloud Portal.

For other dedicated web browsers, such as Safari, Google Chrome and Edge we have always recommended that you prevent these apps from being installed or shown on users' iPads at all.

There are however some apps, that while not dedicated web browsers can still show their users a web browsing view directly within themselves. Such use cases include showing a small preview of a link within a word processing document or email, or providing a fully featured web browser alongside other non-web app content. Unfortunately Smoothwall Browser does not see any web content outside of itself and is unable to apply its normal policies in such cases. If such apps are allowed for your users as part of their normal work, then care is needed to ensure that they cannot abuse those apps as a means of displaying arbitrary web content that would normally be filtered when viewed in Smoothwall Browser.

It is for these apps that the Filter Extension provides a solution.

About the Filter Extension

The Filter Extension is an iOS Network Extension that has access to every url request that originates from any web browser view in any app (both 3rd Party and Apple) on the iPad. Whilst it is packaged as part of the Smoothwall Browser app, it operates independently with a different set of filtering rules which are unrelated to any policies that you set in Smoothwall's Cloud Filter portal.

When it sees a new url request coming from a web browser view, it uses it rules to decide if the request should be allowed on a per-app or a per-host basis.

If the Filter Extension decides that the request should not be allowed for the web browser view then it tells iOS to ignore the request. When this happens, the originating app's web view will display a message similar to this:

Unlike the main Smoothwall Browser app, the Filter Extension will not be enabled by default when Smoothwall Browser is installed. It needs configuring separately.

Configuring the Filter Extension

Prerequisites

The iPad must be configured as a supervised device.
Smoothwall Browser v105.0.2 or later is installed and provisioned correctly.
You have an MDM that natively supports creating Web Content Filters or allows the pushing of a manually created profile from Apple Configurator.

Instructions

We will use Apple Configurator for demonstration purposes. For other MDM solutions the concepts will be the same, but they may name things differently.

In Apple Configurator:

Create a New Profile (or open an existing profile to which to add Content Filtering)
In the side panel, select Content Filter.
In the main panel, click Configure. You will be presented with a view like this:
From the Filter Type pop-up, select Plugin (Third Party App). The view will switch to this:
Fill in the Filter Name field with something meaningful to you
In the Identifier field, enter Smoothwall Browser's Bundle ID: com.smoothwall.ios.Firefox
Leave the following fields empty: Service Address, Organization, User Name and Password.
Do not select anything for Certificate.
Ensure that the Filter WebKit Traffic checkbox is turned on.
Turn off the Filter Socket Traffic checkbox.
Do not enter anything yet in the Custom Data section. This will be explained later.
After all that, the view should look something like this:
Save the profile.

If your MDM solution does not provide built-in support for configuring Content Filters then the profile created above in Apple Configurator can be used if your MDM supports pushing a custom profile.

The following MDM solutions are known to have built-in support for configuring Content Filters:

MDM Provider	How to find Content Filter settings
JAMF Pro	Configuration Profiles -> Content Filter
JAMF School	Within an existing profile -> Web Content Filter

Once installed on an iPad, the configuration profile created above provides default filtering rules suitable for many situations where an iPad app displays browser content.

Smoothwall Browser is always ignored and continues to use its own filtering policies that you set up via the portal to decide what to allow or block.
All other apps are allowed to display web content if it is related to signing in with Single-Sign-On from Google or Microsoft. Otherwise web content is blocked.

Customising Application Filtering

Customising On a Per-App Basis

There may be times when you need to alter the rules on a per-app basis.

For example you may use an education app that internally uses a web browser to display all of its content, but that does not provide a means for users to load an arbitrary url into that browser. By default the Filter Extension will block such content from showing. Assuming you have already decided the app is safe to use, you will want to override the rule for that app.

You enter custom rules in the Content Filter configuration view in Apple Configurator or your MDM in the Custom Data section. That section allows you to specify app Bundle IDs and whether to allow or block those apps.

E.g. Suppose you have an app "Maths Quiz" with the bundle ID "com.example.MathsQuiz", then you would create a new entry in the Custom Data section using the + button with a Key of com.example.MathsQuiz and a Value of allow.

If you have multiple apps from the same vendor then you can use a wildcard * character at the end of the Key field to apply the same rule to all apps from that vendor.

E.g. If the creator of "Maths Quiz" also had "Spelling Quiz" and "Cooking Quiz", then you could allow them all by using an entry with Key com.example.* and a Value of allow.

If you explicitly want to block an app from displaying web content that might otherwise be allowed by a wildcard entry, use a Value of block.

So combining all this, suppose the same vendor has another app "Exam Time", with Bundle ID "com.example.Exam", which does not normally display web-based content but has a means to bring up an unrestricted browser view, then these two rules would suffice to allow the 3 quiz apps access to web content, but not the exam app:

Key	Value
com.example.*	allow
com.example.Exam	block

Customising on a Per-Host Basis

As well as creating rules on a per-app basis, you can also create rules based on the host of the url. The host is the first section of the entire url after 'https://'.

E.g. It is the bold section in the url "https://www.apple.com/iphone"

For most situations you should not need to configure rules for hosts. The per-app rules should suffice. However there is one type of in-app browser for which per-app rules will not work on iOS 16 or later. This type of browser is known as a Safari View Controller (henceforth Safari VC) and can be recognised as having this kind of toolbar at the top of the screen:

When an app displays a Safari VC, the Bundle ID seen by the Filter Extension does not contain the main app's ID, but is instead a standard ID used across all apps that use Safari VC. For reference -com.apple.WebKit.Networking. (Note that on versions of iOS prior to iOS 16, the Bundle ID will be the same as the main app's ID.)

As such you can't allow web content within a Safari VC for a specific app, without allowing all apps to display web content within their own Safari VCs.

Instead you can configure which hosts are allowed to have their web content displayed in a similar way as you do for per-app configuration; as entries within the Custom Data section. For the entry's Key, enter the host of the url and for the Value, enter allow or block. As with per-app based configuration, you can also use * as a wildcard, but unlike the per-app wildcard, it must be entered at the start of the Key.

For example, to allow access to any web content at https://support.apple.com without allowing access to other parts of apple.com, enter a Key of support.apple.com and a Value of allow. To allow web content on any part of apple.com, enter a Key of *.apple.com and a Value of allow.

Built-in Per-Host Rules

As of version 109.0 and later of Smoothwall Browser the following built-in host rules were added to prevent unwanted blocking of common innocuous hosts. They can still be overridden if needed.

Rule	Action	Description
*.office.com	allow	Used by MS Office/Microsoft 365 apps during sign-in
*.office.net	allow	Used by MS Office/Microsoft 365 apps during sign-in
inclient.store.office.com	allow	Used by MS Office/Microsoft 365 apps to show Office Add-ins.
hubblecontent.osi.office.net	allow	Used by MS Office/Microsoft 365 apps to show stock images/media.

Rule Matching Order

There is a strict order in which all rules are applied, both built-in and your custom rules. As soon as a rule matches it is used and no further rules are considered.

The app is Smoothwall Browser. No actions are applied and Smoothwall Browser uses its own filtering policies that you set up via the portal to decide what to allow or block.
The URL is related to signing in with Single-Sign-On from Google or Microsoft. It is allowed.
The Bundle ID exactly matches a per-app rule you have created. Its action is applied.
The Bundle ID matches a wildcard app rule you have created. Its action is applied. In the case of matching multiple wildcard rules, the longest one wins.
The host of the url exactly matches a per-host rule you have created. Its action is applied.
The host of the url matches a wildcard host rule you have created. Its action is applied. In the case of matching multiple wildcard rules, the longest one wins.
(v109.0 or later) The host of the url exactly matches a built-in per-host rule. Its action is applied.
(v109.0 or later) The host of the url matches a wildcard built-in per-host rule. Its action is applied
No other rule matches. The content is blocked.

Notes

The order of rules shown in the Custom Data section is irrelevant to the Filter Extension.
Rule changes you make in the Custom Data section will not take affect until the profile is pushed to iPads.
Due to restrictions imposed by Apple, it is not possible to report any information about what the Filter extension allowed or blocked back to customers or Smoothwall itself.

Conclusion

Using the Filter Extension alongside Smoothwall Browser allows you to provide an even safer browsing environment for your users without having to worry about them finding a backdoor to arbitrary unfiltered browsing in other apps.

Addendum - Viewing Extension's on-device Logs

If you have a Mac computer it is possible to use its Console app to view the Filter Extension's decisions about what to allow or block. This can be helpful in diagnosing why any custom rules you have created aren't working as expected. Using Console app itself is beyond the scope of this article, but in short:

Connect the iPad to the Mac via USB.
In the Custom Data section of the Filter's configuration, add an entry with the Key Debug and Value true.
Push that configuration to the iPad that you have connected to your Mac.
In Console, start viewing the logs from the iPad.
In the Search field in Console, enter smw.DataFilter
Visiting websites in different apps will produce logs similar to this:

Note - the 'sourceAppIdentifier' shown in the logs is not the Bundle ID of the app. It does however contain the Bundle ID, which is everything after the first '.'. So in the screenshot, the Bundle ID is "com.google.Docs".

WARNING - Do not leave the Debug option enabled for devices that you are not actively viewing in Console. With it enabled, it is possible for anybody with physical access to the iPad to access all of the logs generated by Filter Extension and hence see the full browsing history across all apps.