The 8 modes of Chrome OS — which to block, which to use in schools

The 8 modes of Chrome OS

Chromebooks at their core are easy to use. Sign in with your school Google account, and be on your way. But there are lots of other modes that you can use on Chromebooks, and some of them you'll want to make sure are blocked for your students.

1. Affiliated user sessions
2. Unaffiliated user sessions
3. Device Off Hours
4. Guest mode
5. Managed guest sessions
6. Auto-launch managed guest sessions
7. Kiosk mode
8. Auto-launch kiosk mode

Affiliated and unaffiliated user sessions

"User sessions" are just your standard way to use a Chromebook. The Chromebook boots, shows the sign in screen, and a student signs in with their account.

There are some subtleties, though, depending on which account they sign in with. If they sign in with an account belonging to the same domain as the Chromebook, i.e. the Chromebook is managed by "school.edu" and the user has an email address student@school.edu, then the session is "affiliated". If the student instead signs in with a different type of account, e.g. student@gmail.com or student@differentschool.edu, then they enter an "unaffiliated" user session.

Schools almost always want to block unaffiliated sessions for a few reasons:

• If the student isn't using their school account, then they won't have any of the user policies applied to them, e.g. blocking Incognito mode, apps & extensions for web filtering and monitoring, etc.
• A lot of the data you see about a device in the Google Admin Console or in Instinctive is only filled in when an affiliated user signs in. For example, a student's gmail account will not show up in the recent users list. If you've ever seen the dreaded "User not managed by your organization," this is the issue.

To block unaffiliated user sessions, configure the DeviceUserAllowlist policy.

One last note: We know some schools separate emails by subdomain, e.g. students are jane@students.school.edu and staff are john@staff.school.edu. As long as all of the users and devices show up within the same Admin Console, they will be affiliated with each other. If you have an entirely separate Admin Console for managing your users vs. managing your devices, then they will be unaffiliated.

Device Off Hours lets you permit unaffiliated users after school

With most schools now sending Chromebooks home at the end of the day, and some schools allowing parents to purchase school-managed devices, it's common for students and parents to want to be able to use unaffiliated users when they're home. This might allow a younger sibling or parents to use the device as well, during certain hours.

DeviceOffHours is a policy that allows you to set a weekly schedule for times when unaffiliated users are allowed. Chromebooks are smart about managing the transition between "off" and "on". The unaffiliated user will be notified when Off Hours are ending soon, and they'll be force signed-out at that time. Their user account will disappear temporarily from the sign-in screen, but their data will still be on the device so they can pick up where they left off once the next Off Hours begins.

Guest mode

From the Chromebook sign-in screen, a student can click "Browse as Guest". This will bring them to a browser window, without signing in, where they can browse anonymously. You almost certainly want to block this. You can do so with the DeviceGuestModeEnabled policy.

Managed guest sessions (regular & auto-launched)

Managed guest sessions are what they sound like - a sort of hybrid between a guest session and session that you can manage. Similar to guest mode, a managed guest session does not require signing in, and will delete all data on exit. However, unlike normal guest mode, a managed guest session allows you to control policies and extensions, just like you do for your users. Nearly all user policies are available to configure for managed guest sessions.

A managed guest session shows up on the sign-in screen like a user (with an icon and a name), and a student can simply click it to begin their session, no password required.

Managed guest sessions are most helpful for younger grades where students aren't saving data on a day-to-day basis and don't really need to be logged in to anything. They can also be helpful for a lab environment where a teacher is walking students through a single website or application that doesn't require sign-in.

With auto-launch, the Chromebook will automatically boot into the managed guest session. This is most appropriate for a library computer (although even in a library you may still prefer that your users sign in with their accounts).

A common misconception is that auto-launching a managed guest session means that the device can only be used for the managed guest session, but this isn't the case. A user can exit the managed guest session and then do something else on the device (guest mode, signing in, etc.), so you still need to ensure that you block guest mode. And if you prefer that users don't sign in, you can restrict them with the DeviceUserAllowlist policy.

Kiosk apps (regular & auto-launched)

Kiosk apps are apps that can be run full-screen and take over the entire Chromebook. There is no user logged in, and there is no browser. Kiosk apps are commonly used for state-wide standardized testing exams. Kiosk mode is the most secure mode available on Chromebooks because of the lack of browser window. If you want students locked in to a standardized test, you want kiosk mode.

In fact, you probably want auto-launched kiosk mode, where the Chromebook boots directly into a kiosk app of your choosing. Some admins don't realize that kiosk apps also show up on the sign-in screen on the device. If you add a kiosk app, a new menu shows up in the bottom left of the sign-in screen called "Apps". From there, a user can select a kiosk app and enter into it.

REALLY IMPORTANT NOTE: A common misconception is that setting a device to auto-launch into a kiosk app secures the device from being used for anything else. This is not the case!! Users can exit kiosk apps and then use the device for other purposes. Even with an auto-launch kiosk app, you still need to block guest mode, and you probably want to block all user sign-in as well. Otherwise it would be possible for a student to exit kiosk mode mid-exam, sign into a regular user session, search for the answers, and then re-enter kiosk mode. (Generally this would be caught by a test proctor, but why leave things to chance?)

Because securing devices for standardized testing requires multiple policies to be configured properly, we highly recommend creating a separate OU for standardized testing that has all of the settings configured. That way you won't need to remember all of the different settings to change and then change back once testing is over.