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.
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.
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.