Chromebooks vs. iPads in education

Internet filtering and control for education in one-to-one scenarios

Chromebooks and iPads for one-to-one computing are a major topic of discussion at Cipafilter. The engineers at Cipafilter work with both every day, and despite the fact that we don't like to take sides in third party competitions between vendors, Google has really delivered a compelling product when compared with iPads. Here are some things we think you should be aware of if you're considering the jump to one-to-one or switching from one vendor to the other.

Fee, form, and focus

App focus vs. web browser focus are the major differences between the approaches taken by the two ecosystems. iPads use a touch interface; Chromebooks use a keyboard. Both platforms offer apps and the web, but while iPads focus on a great ecosystem of proprietary apps, Chromebooks focus on delivering the perfect web experience. Chromebooks usually have larger screens, and they are cheaper.

What is important to really think about is what these devices are optimized to do. iPads are great for consuming media like videos and games from a couch, whereas Chromebooks are designed to sit on a desk and create content like papers and spreadsheets.

Management and the deployment process

Management could not be more different between the two platforms. Neither platform has fully matured yet, but both platforms are now offering management tools.

Google's Chromebook Management Console1 is web based and does not usually require you to physically touch the Chromebook. Chromebooks are enrolled by plugging the MAC address from the sticker on its box into the web console2 and clicking yes to a question that appears during boot. While the units need to be enrolled for everything to work, much of the management data is actually tied to the user's account and will take effect any time the user logs into any Chrome environment with their school account, Chromebook or otherwise.

Chromebooks can be very tricky for the filter to deal with the first time they fire up, however. Your filtering vendor will need to take measures to make sure they can go online behind the filter without problems.

Apple provides their Apple Configurator3 which requires imaging each device, and settings can only be changed by re-imaging the device. It's a very poor effort, honestly; Apple could do better here, and most schools end up being forced to go with a third party solution or abandoning management of the devices all together. Look to your wireless provider for mobile device management solutions; some of them are quite good and you'll need one if you decide to go with iPads. Most of these third party solutions are capable of changing settings on the device over the air, but each one is different, which can make information about how to solve any particular problem hard to find unless you go straight to the vendor's support.

Proxy and authentication settings

With both systems you're probably going to choose to deploy proxy settings to the devices so they can be filtered when the user is at home. There is a major difference in how this works between the two vendors.

Some choices Apple made here are problematic. iPads force proxy settings on the apps but leave important details like managing keychain access and prompting for credentials up to the app developer. Unfortunately most developers don't have any experience with proxy based ecosystems and major problems are common. You'll find many apps won't work at all because they simply don't load the system keychain that contains the user credentials. Then there's the problem that iOS permanently stores credentials in the keychain and they can't be reset without re-imaging the device.

The result is that most organizations deploy portal over proxy settings. The user logs in to a captive portal page when they try to access the Internet. This solves the problem of the apps not working4 and the keychain being permanent but introduces the problem that multiple users can't be tracked independently behind a NAT firewall5. Most systems also require the user to log in at regular intervals or whenever they change IPs. Cipafilter offers a "Persistent" portal that stores authentication information in a cookie on the device to work around the user having to log back in, but the tracking multiple users behind NAT problem still remains an issue.

Apple also doesn't let standard third party apps interact with the operating system directly. Configuring the proxy settings requires imaging the device with the Apple Configurator or purchasing a third party mobile device management system, and there's no good way for a filter vendor to overcome the authentication limitation above.

In contrast Chromebooks apps run on Chrome under the hood. We can solve all these problems with a Chrome extension that injects a header with an authentication token into each Internet request. Proxy settings work at the OS level and will work properly system wide regardless whether you're using an app or the browser. Because all such settings move with the user from device to device, carts and one-to-one scenarios all work great. The proxy settings can be configured via their management console and will be automatically configured on the device the first time the student logs into it.

Encryption support

Chromebooks are the clear winner here. Chrome and Chromebooks both offer end to end encryption through an extension to the proxy protocol called secure proxy6. This means that, when your users are sitting in a coffee shop with their Chromebooks, all their web activity is protected, not just the traffic to places like Facebook and Gmail that choose to implement HTTPS. This extension isn't universally supported by all filtering products, but it's easy to implement for any proxy server that already does HTTPS. Check with your filtering vendor to make sure they support it before you buy — it's a great tech to have going for your users.

Unfortunately, iPads don't offer anything similar for the web. Theoretically, you could buy a VPN concentrator and build out VPNs for each device7, a solution that will work for iPads, Chromebooks, or even Windows PCs, but we've never actually seen anybody do that. In practice iPads are deployed without any encryption of routine Internet traffic.


Flash has been a major technology on the web for decades. It's now been superseded by the better HTML5, but the legacy of websites that use this tech is still huge. It becomes less important every year, but it's worth noting that Chromebooks support Flash and iPads do not.

Google Docs, Gmail, etc.

Google Docs8 on Chromebooks is a huge advantage of the platform. The apps are fast, and work hands down better with mouse and keyboard input than they do on a touch screen. iPads have good apps for viewing Google Docs, but they're hamstrung by the on screen keyboard.

Many schools like to limit users to using the Google Docs provided by the school domain. This keeps users out of their home e-mail and documents when using the school owned devices. Google offers a technology called Google Apps Domain Restriction9 to facilitate this, but some filtering products have trouble enforcing Google Apps domain restrictions on Chromebooks10. You'll need the capability to do HTML decryption only after log-in, and to inject custom headers to make it work, so ask your vendor.

Enforcing the restrictions on iPads isn't as much of a problem, except you'll need the ability to turn off decryption for certain apps and the App Store, as they use certificate pinning11.

HTTPS filtering

This summer, Cisco, Mozilla, EFF, Akamai and friends are expected to release a free and fully automated certificate authority12. With the advent of this organization, I expect we'll see a migration to a 90% encrypted web over the course of the next few years. In particular, problem sites like pornography providers and proxy services are expected to be early adopters. Look for a blog entry that goes more into detail on this topic soon, but suffice it to say you're going to be forced into decrypting HTTPS traffic sooner than you probably ever expected.

In order for a filtering product to decrypt web traffic, the Chromebook or iPad must cooperate by accepting the filter's certificate. Both platforms have problems with this, and you'll want to make sure your filtering product has solutions.

Chromebooks have a system certificate store13 that cannot be modified and a user store that can be. You'll install your filtering product's certificate in the user's store via the web management console, but the user store isn't active until the user has logged in. To work around this, your filtering product will need to be able to detect the traffic that the Chromebook needs to remain unencrypted while it's trying to log in and let that traffic proceed unhindered, then decrypt everything else once the user login has finished.

Apple's problem is pervasive certificate pinning. Pinning is a practice where an app demands that a specific certificate be presented, and bakes information about that expected certificate into the app. Web requests from such apps cannot be decrypted. Apple's App Store, for example, is one of many important apps on the platform that uses pinning, so any requests to install apps or purchase games cannot be blocked selectively by the filter, and the filtering solution must have the capability to let these requests pass it by — it's all or nothing. Such apps simply don't work behind SSL filtering unless you make exceptions for them, and these exceptions can be problematic. Make an exception for the App Store and you may also be making an exception for iTunes Radio and iMessage.

Which brings us to SNI14. SNI is how the app tells the server what domain it's trying to reach. The point of SNI is so that multiple servers can live on the same IP address. Filtering vendors use it to determine what hostname the app was trying to access when it made the request, which is critical to determining the difference between traffic to/from iTunes and iMessage, or Gmail and YouTube, because many vendors today use wildcard certificates15. Many app developers don't understand the finer points of HTTPS, and don't use SNI, so their traffic cannot be differentiated other than by certificate. Chromebooks, however, use the browser for all web communications, so everything uses SNI properly.

Directory service integration

Directory service integration is a big deal! A lot of customers explore the concept of dropping their LDAP16 server when they decide to utilize Chromebooks, but we do not recommend that approach.

Google does offer a directory service API, but it's not very good if you try to use it as a replacement for your LDAP server17. The biggest problem is that it won't validate passwords directly, which means that third parties like filtering vendors can't build applications on top of it that verify a user's username and password. No proxy authentication, no transparent authentication clients, and portal authentication has to redirect to Google and use OAuth. Other problems include a rather restricted query rate, which means you run into scaling problems rather regularly.

What we do recommend is Google Apps Directory Sync18. This syncs your users from your LDAP server up to Google's cloud, and you get the best of both worlds. You manage your users locally, and all your changes get synced to the school's Google domain.

Apple doesn't offer any way to manage Apple accounts for third parties. That means your users are going to be using their private accounts whenever they interact with the Apple store, but this is mostly irrelevant because the Apple account just isn't important to the School like the student's Google Apps account is.


Here at Cipafilter we offer the best product support we can for our customers regardless of platform, and you'll find industry leading support in our product for both Chromebooks and iPads, but we can't really recommend iPads to the customers that ask. They're expensive, they don't have keyboards, and Google Apps and the larger web in general are the real sweet spot for education in our opinion.

  1. ↩︎

  2. ↩︎

  3. ↩︎

  4. As long as you always remember to log into the web before you try to fire any apps up. ↩︎

  5. Two kids at home behind their family router, or a group of kids at a coffee shop, will all access the filter from the same IP. Portal based solutions can not differentiate users other than by IP, unlike proxy auth based solutions. ↩︎

  6. ↩︎

  7. ↩︎

  8. Google changed the name of this offering to "Google Apps", but in this context using the new name seems very confusing. ↩︎

  9. ↩︎

  10. See the description of the problem below in the section on HTTPS Filtering. ↩︎

  11. Certificate pinning is when an app bundles information about the certificate it expects with the app instead of relying on the OS certificate store. This allows the app to detect decryption. For example, Apple has decided it doesn't want to allow decryption of App Store traffic, so the App Store implements pinning, but often the app developer in question just doesn't understand the implications of the choice and breaks their app in decryption scenarios without good reason. ↩︎

  12. ↩︎

  13. ↩︎

  14. ↩︎

  15. Google, for example, puts all their services behind SSL concentrators. Gmail, YouTube, Translate, everything goes to the same concentrators. ↩︎

  16. Generally meaning Windows Active Directory, Novell eDirectory, or Apple Open Directory. ↩︎

  17. Explained by the fact that Google isn't trying to develop this product as an LDAP server replacement. ↩︎

  18. ↩︎

Modern browser recommended

This site makes use of modern Web technologies which are not available in the browser you're currently using. Some aspects of the site may appear strange or not function at all. For the best experience, please upgrade your browser or install another modern browser such as Google Chrome or Mozilla Firefox.