This is a follow-up to our previous blog that covered the benefits from our SmartPAC technology for 1:1 iPad filtering:

It is the year 2020, and every content-filter is claiming to be “Any Device, Anywhere, Any Browser.” In this write-up we wanted to do a technical deep dive into the various technologies available on the market that provide remote filtering for devices like iPads, Windows and Macs that natively do not support any filtering API the way the Chromebooks do with its ChromeOS API. Our hope is to give a technical reader factual information about the technologies out there to make an informed decision on where these claims may fall short with certain technologies.

As of this writing, all of the top web content filters that focus on K-12 schools rely on exactly one of these technologies.

• Securly uses proprietary SmartPACs technology described in this article
• Lightspeed Systems uses iOS Agents based on Apple’s iOS content filtering API
• GoGuardian and iBoss use standard PAC files 

We will describe these three technologies in the chronological order of their evolution. We use the iPad as a platform to demonstrate how each of these technologies work as it supports all three of them.

PAC File Approach

Used as of this writing by iBoss and GoGuardian.

This Approach is almost as old as the Internet. Originally designed by the Netscape Navigator web browser way back in 1996.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file

The idea quite simply is that all modern devices and web browsers allow a Proxy Auto Configuration file (PAC) that is queried for every website that the browser or device wants to access. This pac file is essentially a JavaScript function FindProxyForURL(url, host) that can look at a given URL or host the user typed in, and decide whether to Proxy the URL or let it through. The function simply returns “DIRECT” for letting the URL through, or returns the network location of the proxy to connect to if the URL needs to be proxied. Proxying is done when either the site is determined to be blocked or there is a need to perform deep packet inspection for example if keywords need to be inspected in a Google web search. 

For iPads, in the past, the PAC file based approach was the only way by which content filters could provide filtering. This was because there was no filtering API from the IOS operating system and a DNS-based filter such as OpenDNS or Securly could not be used as the DNS setting was not sticky across wifi networks. 

Securly started off as a DNS-based technology. Given the limitation with iPads, for the first several years, Securly’s take-home iPad filtering was based on Pac Files. 

Issues Securly ran into with the PAC file based approach for remote filtering:

1. High proxy costs creates unscalable education business: The issue that ultimately compelled us to abandon the PAC file approach towards iPad filtering was fundamentally that no matter how much we tried to avoid proxying high-bandwidth content-distribution networks (CDNs), there was simply way too much traffic getting proxied through our cloud-based servers. This created an upward pressure on pricing where the prices would not be education friendly anymore. How do you let a student stream educational videos from the various social media platforms out there at a price point of $3-5/student/year and still create a sustainable business model? The larger the iPad business grew for us, the lower our margins got.

2. PAC file allow/deny list management is a nightmare: The second compelling reason worth noting here because it was a nightmare for our customers and our support engineers was that with the PAC file approach, students & teachers had to constantly work with IT admins & Securly support to figure out what to allow and bypass from proxying. The typical process would be:
   1. Student, parent or teacher would see an app or site not working and contact school IT
   2. School IT would pass the issue along to Securly support
   3. Securly support would ask for network packet captures, and suggest sites to bypass – which may or may not fix the issue
   4. Rinse & repeat

3. Elusive balance between over-proxying and under-proxying:
   1. Several apps and sites wouldn’t support proxying. These had to be left as allowed to go direct.
   2. Sites marked direct do not get logged and therefore IT admins and parents would have no idea the kids were accessing these sites. 
   3. There was a constant tug of war between wanting to log all sites students were accessing by proxying those sites, but then removing those that didn’t like proxying or were sucking up too much bandwidth

4. Users are required to sign in. iPads are typically used by younger kids, and it is not as easy for IT to expect K-3 kids to handle password prompts well.

5. PAC files on remote-devices pointing to on-premise filtering appliances was always a bad idea.
   1. The school has to leave a port open on their firewall for the inbound proxy traffic creating security concerns. 
   2. Using a PAC file to proxy back to an appliance doubles the bandwidth cost of all the traffic. The request has to go to the appliance and then from the appliance back out to the internet. Most schools can’t sustain the double bandwidth and that results in poor device performance.

Candidly, we could have lived with most issues, but watching our iPad traffic take up 50% of our AWS Cloud Ops bill was a big concern, and the frustration our support engineers and IT admins had with managing PAC file allow & deny lists were the top two reasons we had to explore alternatives.

Current players on the market offering PAC file based approaches towards offsite filtering: iBoss and GoGuardian

iOS Agent Approach

Used as of this writing by Lightspeed System’s Relay product.

Over the past couple of years, Apple introduced an API for iOS that content filtering service providers could use to provide filtering natively “on-device”:

https://developer.apple.com/documentation/networkextension/content_filter_providers

Interesting backstory here. We were thrilled to see this development, and our Principal iOS engineer Mayur Joshi picked this up immediately. Right around this time, our Scale & Performance Architect, David Hinkle, was toying with the idea of making the PAC files smarter using the dnsResolve() function. Our co-founder/CEO, Vinay Mahadik, started an internal “innovation tournament” between these two technologies, and transparently shared his skepticism of the SmartPAC technology even though the approach looked interesting. 

SmartPAC won.

We have since moved not just the iPads, but all our take-home 1:1 Macs and Windows devices to the SmartPAC Technology –  that’s millions of devices being served today 24/7 by this technology for the last couple of years that have been moved over from PAC and pure-DNS approaches. 

Here were the main issues we found with the fully implemented iOS Agent approach:

1. No logging & reporting: The top reason iOS Agent lost was that per Apple’s very deliberate design, there is no way for a cloud-based content-filtering vendor to know which website URL the student accessed or was blocked on. This renders reporting on iPad filtering massively broken.

2. Blunt blocking. No granular safety: Apple’s design does not allow deep-packet inspection of Google searches, or YouTube video titles etc. No decryption of HTTPS traffic. No sentiment analysis, and detection of bullying, self-harm, suicidal tendencies etc.

3. User authentication unavailable: Apple’s current framework prevents any way of allowing a per-student policy to be provided on the devices. All the iPads get the same policy, and the admins really see nothing in the reports around who visited what sites.

Current players on the market offering iOS Agent based approach towards offsite filtering: Lightspeed Relay

The SmartPAC Approach

Proprietary patent-pending technology developed and used by Securly across all of its millions of iPads, Macs, & Windows take-home devices. 

Now this brings us to SmartPAC – the winner of the PAC & iOS Agent vs SmartPAC innovation tournament at Securly. Invented by David Hinkle – who was a founding engineer at CIPA Filter, another content filter focused on schools, where he architected a high performance web proxy orders of magnitude faster than Squid on similar hardware.

How does it work?

1. In a nut-shell, first, a student logs in via SSO (GSuite, Azure, AD) and is given a unique PAC file with user-identifying unique ID number.
2. Second, the PAC file uses the “dnsResolve()” PAC function and a simple custom DNS “A query” of the type user.hostname.ns.securly.com to the default DNS server in use (does not have to be Securly’s DNS server – can be Comcast/AT&T, or your school’s ISP provided DNS).
3. Third, this DNS query traverses the usual DNS chains, and is handled by our Authoritative DNS servers (as only we are authoritative on the subdomains of securly.com) to figure out the policy to use for the user, and the filtering decision to apply for that hostname.
4. Fourth, the PAC file then enforces this decision on the user/device. 

In other words, we use the same PAC file from Netscape Navigator times, and instead of populating it with long lists of allow vs proxy sites, we use the dnsResolve() function to let our DNS servers do this decision making in the cloud – the PAC file just does the enforcement. Furthermore, by using an A-query for the subdomain of securly.com, we do not need the local DNS server to be configured to be our DNS server – the queries magically are routed to us through the magic of hierarchical DNS resolution. By serving PAC files unique to each student, we are able to provide per-student or per-OU policy. Since we get the meta-info around kid, hostname, URL, etc at the DNS server, we can log the access granularly as well. The local client footprint stays minimal. We do not have different code-bases for different platforms. The updates are in the cloud. We can be extremely selective about proxying – so we can choose to granularly decrypt and inspect Google searches, but skip Google videos from streaming through our proxy. This allows us to offer SmartPAC at education-friendly prices while still achieving the granularity of PAC files and appliances. 

To recap, the key benefits of SmartPAC and why it was our chosen approach are:

• Truly Browser & Device agnostic as PACs are supported on all platforms (including Chromebooks where we use Chrome extensions for historical reasons). PAC files that have been supported on all modern platforms since 1996.
• Education friendly pricing & Scalable business model. Performs extremely selective proxying using the dnsResolve() patent-pending approach described above that allows it to provide education friendly $3-5/student/year like pricing while having a sustainable business model
• Allows seamless Google/Azure/AD based authentication.
• Zero-touch authentication also supported where the PAC files can be deployed with embedded user ids with an MDM of choice (such as Securly’s MDM product)
• Minimal local footprint. Under 10KBytes. 
• Portable & easy to maintain code. Single piece of code that works identically on Windows, Macs and iPads.
• 100% cloud. So no software agents that can bring down devices on your network with a service pack update
• Rich reporting. Rich logging with user, url, search keywords, deep-packet inspection and MITM decryption

Current players on the market offering SmartPAC based approach towards offsite filtering: Securly (patent-pending, proprietary technology).