> That’s pretty much how Chrome OS works.

And that's the problem. Signing onto a remote account is a request to access a remote resource, and should not be interpreted as granted the remote actor control over local resources. That Chrome OS works this way implies that Chrome OS is fundamentally flawed.

Yeah good luck getting a company to give you VPN access to their network without demanding you've been keeping your operating system patched. BYOD without such policies is a great way to make the network support staff quit and maybe slash your tires on the way through the parking lot.

It's called _attestation_ and Windows has been doing it for some time now with VPNs and domain credentials. Attestation actually makes it possible for BYOD to be done in a way that's not going to simply repeatedly expose one's network to every kind of malware known to man.

Isnt this the same way Windows works? If I sign into a work Windows account and they want to set my default browser or something, thats absolutely something they can do. ChromeOS isnt doing something particularly new in that regard.

On a Windows account, a user can change the default browser for their own account. Therefore, a user can delegate the choice of default browser to the remote management. A user can record which sites their own browser visits. Therefore, a user can delegate that authority, allowing remote management to record which sites that user visits. A user does not have the authority to record which sites are visited by another user. Therefore, they cannot delegate that authority to remote management, because they themselves do not have it.

On ChromeOS, you can filter your own access to websites. You cannot filter other users' access to websites. But signing in to a remote management can filter other users' access to websites. This grants the remote management privileges that the user doesn't actually have.

>On a Windows account, a user can change the default browser for their own account.

Not if they lock down that setting via GPO and let the default behavior of remote > local. There's a lot of settings that can't be undone in the GUI and take diving into the registry to undo when set by GPO but then they'll just get re-applied on GP refresh anyways. Talking about who can do what is immaterial to how domains and remote management actually work if they're not designed how you think they should be. The remote admin will always have more control than the local user in this situation, it's been that way for a very long time now and is unlikely to change.

As a normal user, on a Windows box, if you log into say a corporate Microsoft 365 account with your corporate credentials that device may get managed by the domain (pending any admin approvals needed on the management end) in some fashion because by default the local user/MS account user is a local admin and the services and processes that handle all of this run as SYSTEM thus the user has the authority to delegate that authority to remote management at-will.

Like, this is all basic stuff for BYOD and MDM policies if you've worked anywhere with a halfway competent IT staff. OP didn't read the fine print probably. Wouldn't be the first parent to not do so and freak out over nothing.

> As a normal user, on a Windows box, if you log into say a corporate Microsoft 365 account with your corporate credentials that device may get managed by the domain (pending any admin approvals needed on the management end) in some fashion because by default the local user/MS account user is a local admin…

The parent owns the device and would have the local admin account. They aren't joining the device to a managed domain where something like GPO would be relevant (unless configured by the parent, naturally). The student would only have a non-admin local account, and would be incapable of granting device administration privileges to the school. The school could still manage their browser profile, of course—if the browser itself is actually signed in to the school account, which is something you can disable while still logging in to the account on the web—but they would have no access to or control over other user accounts or anything else requiring local admin privileges.

This is with the presumption that the filtering here is device-level and not user-level. The fact that they were able to wipe and reset the device AT ALL probably means that the device isn't fully enrolled into device management (only the account is) and that the blocking and monitoring is just for that one specific account/profile. That is to say, none of the blocking is breaking the privilege rules on the system.

This isn't to give them extra credit. GoGuardian is still spyware and you should be, at the very least, wary of it if you have a kid with that software running around. But this behavior is consistent with the design of ChromeOS and isn't shocking or special if you've been paying attention to what ChromeOS has been built for over the last couple years.

Group policies on Windows, applied at logon, give the admin control over what the user can or cannot do. If the admin wants you to use Chrome not Edge, then that is what you'll be using, and you won't be able to change the default.

To my knowledge, that group policy only applies to the user who is logging in, not the other users on the computer.

There doesnt appear to be any claim that this undesired software was being run on any other account besides the managed one.

Depends. In the Active Directory world, policies can be applied at the user or computer level. Not sure about Chrome OS, but computer level policies absolutely can effect other users. I bet if OP signed into a normal, non-Google Classroom/organization affiliated account after they reset the device, they wouldn't have found GoGuardian running. This seems like if you connected an arbitrary device to a Windows domain over say VPN, then got surprised when user level policies were applied to the profile created on the local machine resultant from the process of connecting a machine to a domain. This is very much by design of ChromeOS as other commenters point out.

On Windows, settings and software can be enrolled remotely the moment you hook your machine up to an MDM portal, just like on chromeOS. Windows doesn't include some of the functionality ChromeOS includes, but your employer can definitely manage settings like your standard browser if they choose to. The can also enforce that all software you run is signed, is run from specific locations on the system that you may no longer have access to and they enable Bitlocker with a specific backup key.

Most companies either choose not to implement any of this, or simply do not know they can implement this. Do not sign into your personal devices with your work account on anything but an isolated browser (modern Windows has a sandbox built in!) or you might discover the hard way what kind of possibilities remote AD allows for.

Windows does prompt you to accept that the account can manage your device, but so does ChromeOS. Denying MDM may cause the login to fail if they automatically rescind any tokens that don't get MDM access on your device.

It is not fundamentally flawed, it just isn't a general purpose computer. It's a thin client to your cloud services. The "local" is not a primary compute environment, but just a cache. Once you think about it this way, Chromebooks are absolutely amazing little physical manifestations of a remotely managed browser. As they are intended to be.

Maybe there should be more of a notice, but when I tried it with my son’s account I got some notifications.

Having said all that the default will be for most school accounts… all or nothing. Don’t allow them to manage it and you won’t get in.

My issue isn't about the notification, but that this doesn't work at all within any reasonable model of user permissions.

Fundamentally, authority cannot be delegated authority that you yourself don't have. I can agree to a contract promising to do some particular work, because I have the authority to direct my actions. I cannot agree to a contract promising that you will do some particular work, because you haven't granted me that authority. I cannot grant to another what I do not have for myself.

With regards to user permissions, a non-administrator doesn't have permission to monitor another user's activity. Therefore, they cannot delegate permission to a third party to monitor another user's activity. That this is possible means that ChromeOS has a fundamentally flawed model of user permissions.

Windows does this as well, and I would expect other management solutions to as well. You can build your own PC and be local admin on it, but the second you sign in to an active directory account (using a VPN for work) that account will be locked down and can run scripts that the AD owner chooses. I imagine that is what is happening here as well, where the user has signed into the school Google Workspace account (or whatever it's called these days). To avoid this, they could sign in to Google Docs and Google Classroom in a browser. (Although to be fair, Chrome does aggressively ask if you want to sign into Chrome with your account, and probably if you want to sign into the user profile on ChromeOS if I had to guess)

Can't speak for OP, but generally this is mentioned during the sign in process, so it should be laid out. It is effectively all or nothing.

> This might just be a good lesson that you want to maintain device / role boundaries.

This is the teachable moment here. Better for the poster and their child to learn it now rather than in the workplace.

It doesnt make it right, but the 90's and 00's with work browsing and email full of porn, dickpics and assorted filth were not right either.

A gaping security hole is fine if it’s been introduced on purpose?

> A gaping security hole

What is that?

“the system installed GoGuardian monitoring software on the Chromebook without notice or permission.”

When I logged in with my son’s school account on chrome OS it had some notifications about who owns the account and so on.

I don’t think it is as much a mystery as implied.

In the end there’s no getting around that mixing device uses like this doesn’t work. It works less and less as the history of computers goes on.

Can the managed account actually access files from the unmanaged account or control which processes are active while the unmanaged account runs?

Because, if yes, this absolutely does sound like a security hole:

1) Set up an organisation and add a managed account. Set up policies that install a backdoor on first login.

2) Get hold of victim's Chromebook.

3) Log into the Chromebook using the account from (1)

4) Chromebook will execute the policies and run the backdoor.

5) Use the backdoor to snoop victim's files.

You've successfully gained access to the victim's files without knowing their password. Profit!

This would work even if the victim is fully aware of the issue and never intended to mix managed and unmanaged accounts on their own.

Does a chromebook allow you to have more than one user account? It sounds like a factory reset was necessary to allow enrollment

Chromebooks do allow more than one user account, yes. The factory reset mentioned by the OP was necessary in order to undo the enrollment, as no application of Administrator/Owner privileges would undo it otherwise.

I think you misunderstand the original post - the parent didnt have some sort of local administrator account (which isnt really a thing on ChromeOS). They signed into a managed account run by the school district, didnt like the policy, then reset the device, signed into the same managed account again, and noticed the same policy was applied.

> local administrator account (which isnt really a thing on ChromeOS).

The first user to sign in on a chromebook has limited special powers. I don't think they involve reading other people's data though.

>In the end there’s no getting around that mixing device uses like this doesn’t work

Surely this is the entire value proposition of ChromeOS - you sign in to your account, and the laptop magically becomes yours? It seems like a serious hole if a single sign-in is able to compromise other accounts.

It's tied directly to the remotely managed account, that's how the account works. If you don't sign into the account, the software won't be installed.

Students don't get to decide what software to install when it comes to logging in to school accounts. Generally the laptops are provided by the district, but it seems OP was trying to add another personal device to their system.

You can't participate in their system without the software. So I guess the alternative would be to block personal devices from logging in like this at all.