Off Hours Device Profiles - A First Look.

The rumour that Google planned to support Off Hours device profiles for Chromebooks has been around for a while. An earlier post proposed how they might be used to support a Bring Your Own Chromebook (BYOC) policy for schools.

The basic idea was that a student could purchase a Chromebook and then use it in school operating under a security profile, only to revert back to a standard consumer device after 4 PM.  The benefits seemed to be obvious but the details were a bit vague because nine months ago scheduled device profiles didn’t exist - but they do now.

This post gives a brief description of how they work. As with most things Google it’s a simple idea that's been well implemented and the implications for future 1:1 programs could be significant.

The setting is found in the the Chromebook device area of the admin console in a new Off Hours policy.

The information required is pretty straightforward, the time zone for the schedule followed by a series of ON - OFF times.

In this example the policy is set to operate between 7:00 AM and 12:00 PM every Friday.

The dialog informs you that once set “some sign-in restrictions won’t apply”. The wording of the policy is a bit vague and the effect is not immediately obvious because, after saving the policy and rebooting, the Chromebook shows no change at all. Even though the policy should apply according to the time frame the user is still limited to organizational accounts only.

The change is only apparent after the organizational user logs on and then signs out which is a really nice feature. Effectively the Chromebook will only relax the security profile after being authenticated by a organisational account. Therefore if the Chromebook is left on the bus it’s not going to allow Guest Mode after 4 PM just because the policy applies at that time.

However after the organizational user signs in and out, it’s all change.

The organizational account requirement is lifted, guest mode is enabled and the user can log in with a standard consumer account.

Once logged in it's clear that the user session is set by a timer that's controlled by the Off Hours policy. In this case after 1 hour 50 minutes the session will terminate regardless of any internet access. Once the time is up it's goodbye Facebook and back to school for you !

So there you are, Off Hours device profiles. A very simple idea that provides a whole new way of putting Chromebooks into schools and no other client technology can do this.

Game changer is an overused term but in this case I'm not so sure.


Note: tested on a Chromebook running Beta V67.0.3396.57.

Why app licencing is a dead dog for Chromebooks.

Managing Android apps on Chromebooks creates a number of challenges for schools, one of which is licencing.

Software licencing is not really a Chromebook, or even an app issue but a general problem that’s been around for as long as IT admins have been installing packages onto local devices.

Over the years there have been numerous attempts to manage the process including dongles (remember DESkey), key servers, USB devices, block and site codes, up to and including a trust relationship with the customer backed up with the threat of a visit from FAST.

While you have a limited number of machines that can be matched with an equally limited number of software titles the situation can be managed without too much stress. The problems start to emerge when you scale up to hundreds of devices and spirals out of control when you introduce customised application sets and shared device deployments. Unfortunately the majority of Chromebook/Android deployments fall squarely onto the last category - many users, on shared devices, all requiring a custom app set that's linked to the curriculum.

The current model for software deployment onto mobile devices uses the store concept  (Google PlayStore, Apple App Store and Microsoft Store) and while this is well suited to individual with a couple of devices, a personal credit card and a desperate need to play Candy Crush, it quickly falls apart when you apply it to large deployments of shared devices

Apple have gone through a number of iterations to solve the bulk licencing problem while Google tried to adapt the store model with Google Play for Education, only to run into the same predictable set of issues - it was inflexible and it didn’t scale.

To make things worse Google have another problem before they can make Android app licensing workable. The current deployment framework is based on an simple organisational tree which is ideal for general policy control but is entirely unsuitable for paid applications.  For this to work you need to deploy apps against user groups and currently that’s not possible.

So where does that leave us.

I think we have to accept that licencing at the point of install is a dead dog for app deployments onto shared Chromebooks (or any device).  We’ve tried it and it doesn't work - give it up.

I don't understand why local licencing is a problem that we are still trying to fix. It’s like an emotional attachment that we can’t quite shake off, the notion that value of the app lies space it consumes on local storage rather than the service it provides. Perhaps it’s something deeply embedded in the IT psyche from installing applications on Microsoft Windows for the last 20 years. 

It’s not 1998 anymore. The real value of the local app has migrated to backend services such as cloud based directories, remote storage, analytical dashboards and advanced API’s that expose a whole new range of functions that leave local computing in the Dark Ages. Surely a modern app is just gateway onto these processes, a convenient way to consume service through the native UI rather than the core proposition.

So why not make the installation free and charge for the value item - the backend service.

For example;

• You can install the graphics app but to save the output to cloud storage and to gain access to the teacher dashboard you need to licence the Google account. 

• You can install the language app for free but integration with Classroom and the features set that provides student metrics needs a subscription.

• The science app needs a user licence to enable results to be shared with your project team and to work collaboratively.

All the licencing is handled by a supporting SaaS platform, hooking directly into the cloud directory. Providing a backend service adds an overhead but this shouldn’t be too much of an obstacle for a business that plans to sell tens of thousands of units into education. Doesn't everyone want to build a ‘platform’ rather than just an app ?

What are the advantages.

• Deploy the app using a simple whitelist. Users can install and uninstall as required. 
• You don’t need groups and the Google OU model works just fine. A quick check against the directory will confirm user access. If not, you just get the try-before-you-buy option.
• Licences are based on active user accounts rather than device installs and can be automated against the directory service.
• Schools gain analytical data from the app instead of a simple desktop process. Surely this is where the true value lies for education.
• The model works fine in a BYOD rollout while local licencing just creates a heap of issues.

Local licensing for shared devices forces the store model to support a scenario for which it’s completely unsuited. The result makes deployment far more complicated than it needs to be and only succeeds in placing a barrier between the app and the educational consumer.  SaaS  has been using the “freemium” model for years and it’s been very successful, why should local apps be any different ?

I’m concerned that a lot of time and effort is going to be spent trying to make Play for Education V2 work for schools, only to see fail for the same reasons as the initial attempt or simply becoming irrelevant. Without having any data on this I suspect the most popular Android apps installed on Chromebooks are the productivity tools from both Google and Microsoft Office 365 - which use exactly this model.

With everybody on the information super-highway speeding towards on-demand access and subscription billing I have a feeling that the pay-to-install model might just end up as roadkill.