Full of good sense. They do try to control the terminal to do a secure boot: > We want our devices to only run software that we wrote. This isn't like a perso

Full of good sense. They do try to control the terminal to do a secure boot: > We want our devices to only run software that we wrote. This isn't like a personal computer where the user can install apps or save files – the only software we want to run on our devices is software that we've explicitly built, tested, and signed off on. > The same concepts that go into secure boot on our satellites are also useful on the Starlink user terminals. Even though we know that an attacker with persistent and invasive physical access will eventually be able to defeat secure boot on their own device, the protections of secure boot are still valuable for protecting against remote attacks over the Internet (or over wifi). There is a big difference between being able to take your own device off your roof and attack it, vs. someone else being able to compromise your device without you noticing. But recognize that it's not foolproof: > We expect attackers with invasive physical access to be able to take malicious actions on behalf of a single Starlink kit using its identity, so we rely on the design principle of "least privilege" to constrain the effects in the broader system. We treat Starlink user terminals as inherently untrusted and only expose the minimal necessary information and capabilities to each specific client. The article talks about the researcher "exploring the Starlink network" as if there's a screen on the satellites that will suddenly display "Access Granted" with a blinking cursor now that he's achieved root on his own dish. Getting access to the dish is an important step if the former is to be achieved, but it's by far the easier of the two steps.