This article focuses on the evolution of school-focused web content filtering solutions on the market today.

This is a follow-up on the previous post on School Remote Filtering approaches:

Remote-filtering Technical Deep Dive: Securly’s SmartPAC vs Traditional PAC Files & Apple’s iOS Agents

Evolution of School Web Filtering – A Quick Crash Course

Years 2000 – 2012

To understand the evolution of the school web content filtering industry, we have to begin way back in the year 2000 with the Children’s Internet Protection Act. Between the years 2000 to 2012, many web content filters were used by school districts. These primarily fell into three broad buckets.

1. Commercial web filters that were hardware appliances. E.g. Websense, iBoss, etc.
2. School-focused web filters that were hardware appliances. E.g. Lightspeed Systems’ Rocket, CIPA Filter etc.
3. The only major commercial web filter that was cloud-based – OpenDNS

Year of 2012

As of 2012, the school web content filtering market was split roughly equally between these three categories.

Securly was founded in 2012 based on the fundamental thesis that school content filtering needed to elevate the conversation from focusing purely on filtering to holistic student wellness & safety. 

Several factors were at play:

• Schools were moving to 1:1 devices that didn’t only stay on campus but also went home with the students
• Schools were using YouTube and other heavy video content for instruction that led to high bandwidth needs on campus
• Social media induced anxiety was creating an increased incidence of bullying, self-harm, and school-shooting

Hardware appliances could not keep up with these bandwidth and mobility requirements, while commercial web filters could no longer satisfy school-specific needs.

Years 2012 to Today 

A cloud-based solution was needed to avoid the bandwidth limitations of the hardware appliances, and to allow 1:1 devices to stay filtered even while at home.

There were essentially three ways of achieving this.

• Proxy in the cloud: This is an approach where all of the local traffic along with the traffic from all 1:1 devices is pointed to a cloud-based proxy.

Key Problem: The primary issue with this approach is that  due to the high cost of proxying traffic, such solutions invariably over-time become cost-prohibitive for the school market.

Vendors using this approach: iBoss & ZScaler. GoGuardian uses PAC-file based proxying for Mac, Windows and iPads, and Chrome extension based filtering for Chromebooks.

• Software agents + DNS/Appliance Hybrid: This solution primarily focuses on the 1:1 managed devices where the school IT admin has the ability to install agents en masse.

Key Problem: The large number of unmanaged devices across the school district, BYOD devices that students bring to class and the guest network devices from visitors to the school cannot be served with this approach and these require either an appliance or a DNS-based filter to truly cover all the devices. The appliances once again run into bandwidth issues, while a blunt DNS filter does not allow a unified policy with the agents as it does not support authentication, per-OU policies, deep packet inspection etc. 

Vendors using this approach: Lightspeed System’s Relay platform which still needs its Relay rocket hardware appliance for unmanaged devices, BYOD and Guest Network devices. GoGuardian uses a Chrome extension “agent” based filtering for Chromebooks, while a PAC-file based proxying for Mac, Windows and iPads

• DNS based selective-proxying: To avoid the issues with a clunky hybrid solution that agents require, and to avoid cost-prohibitive proxying, the approach that Securly picked in 2012 was a DNS-based selective proxying approach.

We loved the simplicity of cloud-based OpenDNS for simple Allow/Deny based filtering, and the rich granularity of cloud-based ZScaler’s deep-packet inspection. We set out to build a convergence of OpenDNS & ZScaler in the cloud – a DNS service that can selectively become a proxy when needed.

The Benefits of DNS-based Selective Proxying Technology

• Lighter, faster, cheaper. 99.9% of the traffic is simply allowed or denied at the DNS level, and does not have to pass through the proxy servers. For example, when a student visits YouTube.com, Securly proxies only the text portion of YouTube.com but all the videos that the kid watches are not proxied – and served direct. This allows Securly to block searches and even enforce YouTube Restricted mode via HTTP cookies, but not have to proxy the Giga-bytes of network video streaming a single user session can involve. This leads to a very high-performance and low-latency cloud-based filtering.
• Google, Azure, Active Directory SSO for DNS: While a pure DNS filter can never identify the student as the DNS protocol does not support web authentication, our DNS to web-proxy approach is able to perform full single sign-on web-based authentication using Google, Azure &  Active Directory logins. We therefore provide rich reporting on which user visited what site and can provide granular per-OU and per-student policies as well.
• Unified experience across both in-school & off-school locations, and across devices that can be both managed or unmanaged devices including BYOD & guest network devices: Our DNS technology powers both in school dns filtering and SmartPac take-home filtering for 1:1 devices creating a unified experience for the student as he/she moves from school to home, and from managed to unmanaged devices including BYOD devices. Smart agent based hybrid solutions that involve a blunt DNS filter simply cannot achieve such a unified experience, and leads to awkward policy handoffs and reporting gaps.
• DNS to Everything: We are the only DNS technology on the market where starting with a simple DNS setting, we are able to identify which student accessed what YouTube video with the title and thumbnail of the video right inside our report. Likewise, we are able to detect the sentiment behind what kids are searching for and saying to each other on social media – and preempt the next school shooting or suicide. No software installed, no hardware appliance – just DNS IP addresses entered in a DNS-forwarding configuration textbox.
• Years of battle-hardened scale: Getting 10M+ students and 15000 schools served on our DNS servers has required us to orchestrate our DNS cloud operations for load, burst in traffic, auto-scaling of 100s or 1000s of servers, handling attacks, avoiding IP reputation issues from bots on school networks, working with various services such as Google, Netflix, etc who may not play well with proxied traffic etc – to reach a point where other DNS based solutions will be those many years behind us in that experiential curve. 

Questions to Ask While Picking a DNS Filter

1. Can the DNS-based filter provide a student a unified policy in-school and off-school?

Or

Is the DNS-filter limited only to in-school use, and provides a different policy from the Proxy-based or Agent-based filter?

2. Can the DNS-based filter provide student-safety via monitoring Google searches, YouTube videos, Wikipedia pages read, and Facebook/Twitter posts made?

Or

Is the DNS filter limited purely to just making blunt website blocking decisions?