September 28, 2018
(If you’re new to the admin console, you might want to start with this intro FIXME.)
This is the first of what will perhaps be a series of posts regarding aspects of the administrator console in GSuite for Education (although most if not all of the options in the Edu version are present in the Business/Nonprofit versions as well.) This installment focuses on some settings related to Chrome device management and user privacy.
Everything described below is set at the user OU level. (Devices -> Chrome Management -> Settings -> User settings.) Therefore, they apply to the user’s Chrome experience regardless of what kind of device they’re using, whether it be a Chromebook, or the Chrome browser on a Mac/PC, EXCEPT where noted (certain settings are user-level, but ONLY apply to the browser-on-desktop context or ONLY to the actual Chromebook context.) Are you already confused? Sorry.
1. Enrollment Controls (applies to Chromebooks only.) In the Enrollment Controls section, there are a couple of options you might find useful when you’ve got a large number of new devices to Enterprise-enroll into your domain:
For example, your OU structure might be
domain.org
- Staff
- Students
- ClassOf2020
- ClassOf2021
…etc. You just bought 50 Chromebooks that are going to be assigned to kids in the 2020 OU. If Device Enrollment is set to “Keep Chrome device in current location,” then the newly-enrolled device will land at the top domain.org OU level; then, you have to manually move it to the ClassOf2020 OU. If, instead, you:
- Select the ClassOf2020 OU
- Set that dropdown to “Place Chrome device in user organization”
- Enroll the new devices with user accounts in the ClassOf2020
Then, the newly-enrolled Chromebooks will already be in their correct OU. This means that, if you trust your students enough to hit the ctrl-alt-e keystroke BEFORE THEY LOG IN THE FIRST TIME, you could have your 2020 students self-enroll the newly-unboxed Chromebooks themselves! (Alternatively, you could create a temporary user in the 2020 OU and use “him” to enroll the devices, then delete him afterward.)
The second option, “Asset Identifier During Enrollment,” allows for the enrolling user to enter an asset ID and/or location information at the time of enrollment. Again, either your students are helpful/trustworthy enough to do this for you, or you do it yourself with the fake 2020 user, but either way, you could pre-sticker the devices as you unbox them, then enter that metadata as you go, vs, doing it afterward. (That said, you may find that it’s less tedious to mass-update after the fact using the free ChromebookInventory add-on and your own spreadsheet skills.)
The third option is already enabled by default, but the other two depend on it — permission for users in that OU to do device enrollments. Back in the day, I believe the enterprise enrollment step HAD to be performed by a domain administrator, but I could be wrong, and it’s moot now anyway.
2. Chrome Management for Signed-In Users This dictates whether or not your Chrome user policies are applied ONLY when the user signs in to a Chromebook, vs. when the user signs in to Chrome on ANY device.
Here’s a scenario where you might care: You have an auditing/filtering tool such as GoGuardian, and you have classroom-only Chromebooks used by students. GoGuardian is enabled through a Chrome extension applied at the user OU level. So, little Jimmy logs in on a school Chromebook, and GoGuardian logs his browsing history, applies content filters, etc. as you’d expect.
Later, Jimmy goes home and sits down at the family Macintosh and opens Chrome. It prompts him to log in, and he does so, using his school email address. All of his Chrome extensions are immediately loaded into that Chrome browser session, including GoGuardian. His activity is now tracked, and GoGuardian filtering policies are applied, even though it’s the family’s personal computer and not the school’s, because the policies follow Jimmy from device to device.
Jimmy finishes his homework and steps away from the computer, without thinking to log out of his Chrome session because why would he, he’s nine and can’t even remember to flush the toilet. His dad gets home and sits down at the family computer, clicks on Chrome, and starts cruising porn. Unless dad first switched Chrome profiles or explicitly logged his son out, he’s still in Jimmy’s Chrome session, so his activity is all getting logged by GoGuardian, under Jimmy’s name.
Note that this is intentional — it’s the philosophy of the product. You’re trying to ensure the student’s safety, regardless of which device they use. Jimmy should learn to log out of Chrome when he’s done, or each family member should have their local own account on the machine (for a variety of reasons), and Jimmy’s dad should learn to use incognito mode. However, you may not be able or willing to fight those battles.
If you change this dropdown to "Do not apply any policies when users sign into Chrome. Allow users access to use Chrome as an unmanaged user”, then your managed Chrome extensions and policies etc. will ONLY apply when the user is on a Chromebook, and will NOT apply when the user is signed in to Chrome on a desktop computer.
Sounds like the perfect solution to the scenario described above; but keep in mind that it also comes into play if Jimmy logs in to the Chrome browser on a school lab Mac — GoGuardian won’t log his activity there either, none of GG’s filters will apply, etc. On a school Mac or PC, logged in to Chrome, your students are all anonymous users, and you will have to fall back on whatever Mac/PC-level security settings, network-based filtering, etc. you have in place to track or restrict their activity. They also won’t have any of the Chrome extensions they might be used to seeing on a Chromebook (e.g. apps, AdBlock, whatever) so you might get some user confusion about that.
3. Multiple sign-in access + sign-in within the browser (applies to Chromebooks only.) The explanatory paragraph kinda says it all.
If you don’t block this option, you could have a scenario along the lines of this: Older sibling logs in to Chromebook first, then hands it to younger sibling who signs in to HIS account without first signing out the big sibling's. Now, the youngster is running under the elder’s Chrome policies, which might be less restrictive than the youngster’s would/should be.
The second option here — Sign-in Within the Browser — should, in my opinion, be disabled for EVERYONE. I wish Google would end it altogether. It refers to the “feature” where you can SORT OF log in to another Google identity from within the first identity’s Chrome session, using the “add account” button that appears if you click your little avatar in the upper right:
This has caused more confusion and frustration for users than any other feature of Chrome. It lets you access the Gmail of the second account, but you’re really still signed in to the original account’s Chrome session. Meaning that if you are in the second account’s Gmail and someone shares a Google doc to that self and you click the link, it will try to access the Google doc using the original account, thus prompting a confusing “you must request access from the owner” message, and resultant messy comingling of two Google identities. CRAP! You should ONLY EVER switch Google identities using the “people” menu or the person picker in the upper right part of the browser title bar. Anyway, this admin setting lets you disable the “inner” account switching capability for an entire OU.
4. Incognito mode, Browser history options, and Ephemeral Mode
The first three apply to the logged-in user’s Chrome experience on a Chromebook OR in the Chrome browser on a desktop computer. Note that if you set “always save browser history” but fail to set “Do not allow clearing of history”, then you’ve only done half the job — you’ve ensured that they must leave tracks, but they can cover those tracks afterward. So you gotta set both to get the result you probably want in a supervised/student context.
Force Ephemeral Mode only applies to the Chrome browser on a desktop OS, and it’s probably a good idea when you have labs/carts of Macs or PCs that are shared by students. It helps prevent them from leaving a trail of forgot-to-log-out sessions, and in combination with desktop Chrome policy management of things like “do not enable remembered passwords", can help protect their account on shared devices.
More to come — the admin interface changes roughly every twenty minutes, so I’m sure this will be stale by the time I hit the publish button. Need clarification, or have a correction? the.bates@gmail.com