Re:Manifest v3 Update
by derefr on Friday May 28, 2021 @10:00AM
(#27315407)
> What is “malware”
Things that steal your password, track your information, and show you ads. Y’know, BonziBuddy-esque things. Things that have a registered signature in an antivirus database, with nobody complaining about that.
Let me rephrase my initial statement to make it more clear: 99+% of the usage of the private extension install API — whether you choose to measure by volume of installations, or by variety of software installed — is by malware. Just like usage of the modern POTS phone system is 50+% by scam callers. Both because of the sheer quantity and variety of bad actors, and how automated and wide-reaching their attacks are; but also because of the dwindling valid use-cases, as most users’ needs have since been met by other technologies that meet those needs better.
In the POTS phone case, most people have switched to using email/texting/collab software/IP video-calling, which is why it feels like every ordinary phone call you receive is a spam/scam call. In the browser extension case, most people with more complex needs — e.g. the people who thought Chrome Apps were a good idea, the people who needed their extensions to have a native-library component, etc. — have switched to building standalone apps that have a browser embedded in them, where their “extension” can run un-sandboxed on your OS, not sandboxed within the browser. Y’know, Electron and the like.
(And moving your extension to Electron actually solves a great amount of the problem, because now your functionality itself is considered a base part of an “app” that can be independently quarantined by the OS, installation-constrained by MDM/GPO, sandboxed with a capabilities manifest to just what its use-case needs rather than what an entire browser needs, etc. IT admins love the shift from extensions to purpose-built Electron apps.)
> hardcore authoritarian
I have nothing against having control over your own system. For modern security, though, you truly have to have control over your own system — i.e. not let it control itself, but rather have two systems, where one follows the other’s whims via MDM.
The only truly-secure systems are ones where their choices are out of their own hands, and rather in some other system’s hands. Either interactively, via MDM; or non-interactively, via limited-capability ephemeral immutable-image infrastructure. Such systems have no entrypoint for a rootkit: in the immutable-image case, because the OS itself doesn’t have the physical capability to modify the boot volume (because it’s an NFS/iSCSI mount from a server that’s sharing it read-only; or because the OS kernel is a simplified unikernel that just doesn’t have “write to disk” as an implemented code path; or because it’s running as an instanced VM that disappears if it reboots.) And, in the MDM case, because there’s a chain of trust (signed BIOS → signed bootloader), where the bootloader will only boot a boot volume if that boot volume has been signed by the MDM controller; and where the keys for doing that aren’t on the device.
(If you like, instead of an additional MDM system, you could in theory have your boot-volume signing key held offline in a smart card/hardware wallet. No OS currently has the capability to use that offline signing key during the OS update flow, but it’d sure be neat if they started doing that.)
Is that authoritarian? In the same way as someone on a space station telling you not to open the airlock, perhaps.
Things that steal your password, track your information, and show you ads. Y’know, BonziBuddy-esque things. Things that have a registered signature in an antivirus database, with nobody complaining about that.
Let me rephrase my initial statement to make it more clear: 99+% of the usage of the private extension install API — whether you choose to measure by volume of installations, or by variety of software installed — is by malware. Just like usage of the modern POTS phone system is 50+% by scam callers. Both because of the sheer quantity and variety of bad actors, and how automated and wide-reaching their attacks are; but also because of the dwindling valid use-cases, as most users’ needs have since been met by other technologies that meet those needs better.
In the POTS phone case, most people have switched to using email/texting/collab software/IP video-calling, which is why it feels like every ordinary phone call you receive is a spam/scam call. In the browser extension case, most people with more complex needs — e.g. the people who thought Chrome Apps were a good idea, the people who needed their extensions to have a native-library component, etc. — have switched to building standalone apps that have a browser embedded in them, where their “extension” can run un-sandboxed on your OS, not sandboxed within the browser. Y’know, Electron and the like.
(And moving your extension to Electron actually solves a great amount of the problem, because now your functionality itself is considered a base part of an “app” that can be independently quarantined by the OS, installation-constrained by MDM/GPO, sandboxed with a capabilities manifest to just what its use-case needs rather than what an entire browser needs, etc. IT admins love the shift from extensions to purpose-built Electron apps.)
> hardcore authoritarian
I have nothing against having control over your own system. For modern security, though, you truly have to have control over your own system — i.e. not let it control itself, but rather have two systems, where one follows the other’s whims via MDM.
The only truly-secure systems are ones where their choices are out of their own hands, and rather in some other system’s hands. Either interactively, via MDM; or non-interactively, via limited-capability ephemeral immutable-image infrastructure. Such systems have no entrypoint for a rootkit: in the immutable-image case, because the OS itself doesn’t have the physical capability to modify the boot volume (because it’s an NFS/iSCSI mount from a server that’s sharing it read-only; or because the OS kernel is a simplified unikernel that just doesn’t have “write to disk” as an implemented code path; or because it’s running as an instanced VM that disappears if it reboots.) And, in the MDM case, because there’s a chain of trust (signed BIOS → signed bootloader), where the bootloader will only boot a boot volume if that boot volume has been signed by the MDM controller; and where the keys for doing that aren’t on the device.
(If you like, instead of an additional MDM system, you could in theory have your boot-volume signing key held offline in a smart card/hardware wallet. No OS currently has the capability to use that offline signing key during the OS update flow, but it’d sure be neat if they started doing that.)
Is that authoritarian? In the same way as someone on a space station telling you not to open the airlock, perhaps.