The problem comes down to education institutions. I remember when we got Chromebooks in my highschool (8 years ago) admins forgot to turn of developer mode and half the school unenrolled the Chromebook managing to bypass all restrictions. This went on for half a year until one day our school needed to run a state exam (more for measure of schools performance not as a college entrance exam or anything).
The computerized testing program required deploying a specific chrome app accessible when chrome book is logged out (can’t just download from chrome web store). When they tried to push the client since half of Chromebooks were unenrolled it failed. This required the school it to recall pretty much all chrome books to manually re enroll all of them and disable developer mode (prevents unenrolling and prevents sideloading Linux).
Problem is if older Chromebooks are used for Linux in an educational environment there would be nothing stopping a student from whipping up a bootable USB and dumping another distro (bypassing restrictions). I’m also not sure if there is a enrollment mode equivalent Linux (there may be but not sure).
At least that’s my two cents (not a school it admin just a memory from the past 😉).
I never really understood the need for that strickt controll of the hardware… Who cares if Linux is sideloaded or if students unenroll.
Imho I think if you need that strickt controll you are bound to get so many unnesseary issues down the line. Instead let student 6se what ever the fuck they want and for security just make sure they WiFi/ethernet is secure and locked down and any services the students need are behind a secure 2fa login. Treat any device as untrusted is more healthy for your security in the long run imo. If students need special software that they can’t run on their own machines you can lend them a machine for that specific task for a specific time. Problem solved.
The problem comes down to education institutions. I remember when we got Chromebooks in my highschool (8 years ago) admins forgot to turn of developer mode and half the school unenrolled the Chromebook managing to bypass all restrictions. This went on for half a year until one day our school needed to run a state exam (more for measure of schools performance not as a college entrance exam or anything).
The computerized testing program required deploying a specific chrome app accessible when chrome book is logged out (can’t just download from chrome web store). When they tried to push the client since half of Chromebooks were unenrolled it failed. This required the school it to recall pretty much all chrome books to manually re enroll all of them and disable developer mode (prevents unenrolling and prevents sideloading Linux).
Problem is if older Chromebooks are used for Linux in an educational environment there would be nothing stopping a student from whipping up a bootable USB and dumping another distro (bypassing restrictions). I’m also not sure if there is a enrollment mode equivalent Linux (there may be but not sure).
At least that’s my two cents (not a school it admin just a memory from the past 😉).
I never really understood the need for that strickt controll of the hardware… Who cares if Linux is sideloaded or if students unenroll. Imho I think if you need that strickt controll you are bound to get so many unnesseary issues down the line. Instead let student 6se what ever the fuck they want and for security just make sure they WiFi/ethernet is secure and locked down and any services the students need are behind a secure 2fa login. Treat any device as untrusted is more healthy for your security in the long run imo. If students need special software that they can’t run on their own machines you can lend them a machine for that specific task for a specific time. Problem solved.
Federal laws and rules for educational technology:
CIPPA - https://www.fcc.gov/consumers/guides/childrens-internet-protection-act
COPPA - https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa
and to an extent
FERPA - https://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html