roze.ma

What I found when my daughter’s school said “just install this Chrome extension”

My 16-year-old’s high school recently rolled out LanSchool Air as a classroom management pilot. The parent letter was clear: BYOD devices would use “an extension via the Chrome browser.” The principal confirmed by email that the software was IP-locked to the school network, time-restricted to school hours, and that no keystroke data was collected. School Chromebooks were available if families didn’t want to install it.

I teach undergraduate cybersecurity. I’ve built phishing simulations to thousands of users, I’ve published academic research on cybersecurity, and I run a research lab that would make some many IT departments jealous. I’m also a parent who tries not to be that parent. So I read the letter, asked my questions, got reasonable answers, and told my daughter to go ahead.

Then she showed me her screen.

That’s not a Chrome extension

What I was looking at was a full native macOS application sitting in her menu bar. Not a browser extension. An application, with its own status window showing “LanSchool Air Status” and three red indicators: Not connected to server, No valid token, Device not provisioned.

Chrome extensions live inside Chrome. They can see what’s happening in the browser and nothing else. They’re sandboxed. That’s the whole point, and that’s what we were told would be installed.

What was actually on her machine was something very different. So I did what any reasonable cybersecurity professor with a free evening would do. I wrote a forensic audit script and ran it as root.

The school notice

For context, here’s what parents were told. The school sent a letter on March 19, 2026 announcing the LanSchool Air pilot for English and Modern Language classes. The letter specifically stated: “This pilot will involve school issued devices and BYOD devices. The BYOD devices will use an extension via the Chrome browser.” It also stated: “Classroom view will not be possible outside of school hours.” School Chromebooks were offered as an alternative.

I missed this Skyward notification initially (my fault), and when I emailed the principal to ask questions, he was responsive and helpful. He confirmed the IP restriction, the time restriction, and the absence of keystroke logging. All reasonable answers. All technically accurate descriptions of how the LanSchool Air admin console was configured.

The problem is what was actually deployed to the device.

What the audit found

The script swept the entire filesystem, computed SHA256 hashes of every discovered file, preserved copies of configuration files, queried the macOS privacy database, checked for management profiles, and dumped the full process list.

Here’s what was actually installed:

The full LanSchool Air native macOS client, deployed as a system-level package (com.lanschool.lsair.Client), installed as root into /Library/Application Support/LenovoSoftware/LanSchoolAir/. It included six application bundles: the main Electron-based client, a client approvals app, a network monitoring client, a network monitoring server, an uninstaller, and a debug tool.

At the time of the audit, seven processes were running on my daughter’s personal MacBook Air. A Privileged Helper Tool running as root from /Library/PrivilegedHelperTools/. The main LSAirClient running as an agent. A renderer process, a GPU process, and a network helper. And lsanmserver, a local server running under her user account.

Three LaunchDaemons were installed at the system level, all running as root. One of them runs a /verify command every 30 seconds to make sure the installation hasn’t been tampered with. The main client LaunchAgent is configured with KeepAlive: true and RunAtLoad: true, meaning macOS will restart it automatically if it’s killed and launch it every time she logs in.

The renderer process was started with --enable-features=ScreenCaptureKitPickerScreen,ScreenCaptureKitStreamPickerSonoma in its command line. That’s the macOS screen capture API, compiled in and feature-flagged on. It’s there, ready to use the moment permission is granted.

And the Chrome extension that the parent letter described? Not installed. No LanSchool files anywhere in Chrome’s extension directories. No managed Chrome policies. No force-installed extensions. The thing they told us would be on the device doesn’t exist. Only the full native agent.

What was communicated vs. what was deployed

The parent letter said: “The BYOD devices will use an extension via the Chrome browser.”

What was deployed: a full native macOS application suite with a privileged root helper, three persistent system daemons, an auto-updater, and screen capture capabilities baked into the renderer.

The principal confirmed by email: “LanSchool is tied to the IP address of RHS, so it is only usable when on RHS wifi.”

What the documentation shows: the IP restriction is a toggle in the admin console. A Site Admin can disable it with one click. LanSchool’s own setup guide describes this exact process for enabling remote monitoring. The same is true for the active hours restriction.

I want to be fair here. I don’t think the school was being deceptive. I think the administrators communicated what they were told by whoever set up the pilot, and that person may not have understood the difference between the Chrome extension deployment path and the native client deployment path. LanSchool Air supports both. Someone in IT chose the native client installer for Mac BYOD devices, and the parent-facing communication didn’t reflect that choice.

But intent doesn’t change what’s on the device.

Why this matters beyond my kid’s laptop

Every security control the school described to me, the IP filtering, the active hours, the restriction to the school network, is a configuration setting in LanSchool Air’s cloud admin console. They are not hardcoded. They are not immutable. They are policy settings that live behind a login.

If an attacker compromises the Site Admin credentials, they can disable IP filtering, expand active hours, create an instructor account, and start viewing student screens on personal devices from anywhere. The agent is already installed. It doesn’t need to be redeployed. It’s sitting there, provisioned and waiting.

This district experienced a ransomware attack in May 2024. Attackers had deep enough access to push ransom notes to printers in every building. That level of network penetration almost certainly means credentials were harvested during the dwell period. Adding a tool that can view student screens on personal devices raises the stakes of the next compromise.

A request to the district

I’m asking the district to notify all parents of students in the LanSchool Air pilot that the BYOD deployment for (at least) Mac users involved the installation of a full native monitoring agent, not the Chrome browser extension described in the March 19 parent letter. Parents deserve accurate information about what software is running on family-owned hardware, and they deserve the opportunity to make an informed decision about whether to continue with it or switch to a school-issued Chromebook.

A corrective communication doesn’t need to be an apology. It can be as simple as: “We want to clarify that Mac BYOD devices received the LanSchool Air native client rather than a Chrome extension. Here’s what that means, here’s what it can do, and here’s how to switch to a school Chromebook if you’d prefer.” That’s honest, it’s straightforward, and it’s the right thing to do.

What other parents should do

If your kid’s school rolls out classroom management software on personal devices, ask three questions: What exactly is being installed? (Get the specific product name and deployment method, not marketing language.) What data does it collect, and who can access the admin console? And what happens to the monitoring capability if the school’s network is compromised?

If you have the technical chops, run an audit. I’ve published the forensic script I used on GitHub. It runs on any Mac, uses only native macOS tools, and produces a hashed evidence log with SHA256 integrity verification. It takes about five minutes. What you find might surprise you. Five minutes with your favorite large language model and a little bit of forensics training, and you could have the same one for your PC or even your Chromebook.

The bottom line

Schools are in a tough spot. Students are distracted by devices, and teachers need tools to manage that. I get it. I live it on the other side of the desk every day. But when a school asks a family to install monitoring software on a personal device, the communication about what that software does needs to be accurate. And the security posture of the environment it’s deployed into needs to match the trust being asked of families.

The tool selection was reasonable. The configuration was solid. The communication missed, and the security baseline has some gaps that matter more now than they did before this software was in the picture.

I’ve offered to help the district get this right. That offer stands.