Android Content Filter
Android Filtering for Mass Distribution
Why does Comvigo currently use a browser for Android Filtering?
Short Answer: Because a browser the best way, given the current Android mobile carrier technology ecosystem, to make a mass distributable app.
For the detailed answer, please read on…
“Everything should be as simple as it can be, but not simpler” – Albert Einstein
How is internet traffic routed?
When not connected to a WiFi, internet traffic requests (browsers and apps) are generally routed from a mobile device directly to the carrier. LTE, 3G, 4G, browser http requests (website browsing) is going directly from your mobile phone or tablet to the carrier (Sprint, Verizon, AT&T, Vodafone, etc.) and their servers then deliver the page back to your browser.
If you are using WiFi, the traffic goes from your mobile device browser (or App) to the WiFi router. The WiFi router is the device in your home (or at Starbucks, the book store, the internet cafe, etc.) which takes request from your connected device, and then routes the http request to the ISP (internet service provider), who then directs the request to their server, and brings you back the web page you typed in. You can see this gives the router a chance to look at the request, and decide whether to send it along, or to filter it. The same applies to the ISP.
WiFi based Internet Filtering
There are several ways to filter internet requests if your device is connected by WiFi. For example, you can install a router on your internet connection, and use the router software to whitelist or blacklist websites. Most routers have minimum capabilities of doing this, and the user interfaces tend to be geared towards technical people. Also, these interfaces only provide minimal functionality. You can also redirect your home router traffic through an internet based filtering service which could have an interface to filter categories of websites. However, once you are away from your home WiFi, this filtering will not happen on the device. When you leave WiFi range, your device automatically will jump to carrier based internet traffic, and there will be no filtering. So, unless you restrict use of the device to WiFi home internet, there needs to be a solution for carrier based internet traffic.
Carrier Based Filtering
The primary demand for an app like ours (Comvigo Browser) is for an Android device (phone or tablet) that is connecting via the carrier (Sprint, Verizon, AT&T, Vodafone, etc.) without WiFi. Our browser filters just as well with a WiFi connection, but the carrier based internet filtering is our exclusive domain. A Wifi based filter cannot work if the user is connected directly to the telco carrier network. I’m also talking in general terms about providing a usable solution that can be dispensed on a mass basis to the majority of users who want a plug and play solution from the Google Play app store, or similar public download site, or a carrier’s store. This means that the app needs to be easily installed and maintained with minimal instruction by non technical users. It has to “just work”.
One way we could achieve carrier filtering (off of the WiFi Connection) would be to route the http requests (website requests from the browser) and filter the packets from a third party router. This would enable the use of any commercial browser (Chrome, Internet Explorer, Opera, Safari, etc.) to be filtered. Thus we would not have to route traffic from a specific browser, and deny access to other browsers.
What is an APN Setting? The APN (Access Point Name) setting on a mobile device is how web traffic is routed to the internet provider (your carrier) when not on WiFi. The APN gives the mobile device the address of the servers, and other information, to provide an internet request.
Changing APN Settings
So, theoretically, we can change the APN settings on our device to a router of our choice, and filter that way. But wait, not so fast. It’s not that simple. This would require a filtered carrier connection, or a dedicated mobile ISP provider that is also filtered, with a management interface. Not a simple thing, and not available as far as I know. Also, this would involve changing the APN settings, which is also not simple. You need to know the MMSC, MMS Proxy, APN name. It is advisable only for someone with strong technical knowledge, and experience to change APN settings, or you risk making the phone inoperable.
Also, some carriers do not let you make changes to APN settings. The interface is locked, or made invisible to prevent altering the settings.
GSM vs. CDMA and APN Settings
OK, more acronyms here. There are two primary forms of cellular communications. Most phones in the world use a system called GSM (Global System for Mobile Communications)
a smaller number of carriers use CDMA (Code Division Multiple Access). In the USA two of the biggest carriers (Sprint and Verizon) use CDMA. With CDMA type phones, you cannot access the APN settings.
Why do I care about CDMA and APN?, I just want to filter internet…
If Comvigo (or any other company) decides to build an APN based internet filter, which will route mobile web traffic like an ISP, it will only work with GSM type phones. As I write this in December 2014, Verizon has about 110 Million cellular subscribers, and Sprint has about 60 million cellular subscribers. So an APN based solution would ignore these users. If a filtering company distributed a filtering app on Google Play which ignored this large cross section of users, the app would immediately fail, because a large percentage of folks downloading the app would be on CDMA based carriers.
Bad ratings would quickly pile up, despite great pains taken to explain the filter was for GSM phones and not for CDMA phones. Also, it is difficult for the average person to change APN settings manually, despite detailed instructions.
How do I know?
Google Play App Distribution – Acceptable Complexity – The Bloqer Story
In 2011 Comvigo (my company) released an app called Bloqer. It was designed to work at the device APN/Request level. The user would install Bloqer, and change the APN settings to route traffic back to the device itself. The device contained the filtering logic, would inspect the HTTP request (the url request from the browser). Filtering settings were stored on the device itself, and were used to cross check the http requests, before allow it to go out to the original. The app tested well, and was effective. But the actual implementation on Google Play was a bit more problematic. Users (understandably) did not always comprehend the description that it was for GSM only, and the majority of users were from the USA on Verizon and Sprint (CDMA). Of course, a Google Play app has to “just work” with no instructions. So the app exceeded the acceptable complexity of Google Play. We ended up pulling the app from the Play store, and moving to the browser based filtering model. In our estimation, that filtering model exceeded the “plug and play” 1 second install model necessary to succeed on a public download platform, such as Google Play. The same would apply for a “BYOD” or bring your own device corporate device. This type of filtering could possibly work in a controlled pool of devices where a technical administrator could manually configure the devices or create a central Android image with preconfigured APN settings (on a GSM network).
Browser Based Android Filtering
Why is “everything” blocked?
With the Comvigo Browser for Android, we frequently get the question, why do you block my other browsers? Why can’t I use Chrome or Opera, or the native Android Browser?, or (insert name of your favorite browser).
The premise of the Browser based filtering model, currently used by Comvigo, is that the Browser (filter) will route http requests (via the currently configured carrier APN) through our filter, and then send our response (pass through, or filtered) back to the originating device. All other installed browsers will need to be blocked, since they will still send to the original APN with no filtering, and the user could circumvent the filtering. We achieve this through our remotely controlled Remote App Controller (RAC), which lists apps currently installed on the device, and allows the user administrator to block the apps via a remote website. So far this model of blocking has worked well for our users. This, not surprisingly, is the model used by some of our competitors also. We believe we have the best implementation of this model, and that is our competitive advantage.
The primary issues with this model are that the users do not understand why their Chrome, Opera, Safari, etc. browsers no longer work. The answer is that we block them, and this post hopefully explains why. We’ve asked people in the past to take our word for it, but I’ve been meaning to put in writing more detail to support our statements.
I hope this helps, and we’re happy to provide more details if you contact us at our website, www.comvigo.com