Post #3848390

2026-07-16 02:28 UTC

@soatok@furry.engineer @azonenberg@ioc.exchange @hazelnoot@enby.life if defending from your instance admins, a fully client-side js frontend hosted on a different domain would be enough, no? and then, like. if you're defending from the authors of that frontend, they're just as likely to push a malicious update to the extension, which autoupdate for most people. so the only practical thing the extension would be more secure against, is other extensions? (which, to be fair, lots of people install a bunch of questionable ones)

Replies (1)

@soatok@furry.engineer 2026-07-16 02:43

@ww@xyzzy.link @hazelnoot@enby.life @azonenberg@ioc.exchange An extension would be secure against any instance being compromised unless the author of the extension is also compromised. If furry.engineer got pwned after this is all rolled out, there's nothing I could do to stop JS served from furry.engineer from stealing my private keys, etc. However, a browser extension that does all the encryption, signing, and key management outside of the Fediverse domain's DOM entirely would be impervious to malicious JS. The downside is, as you say, the extension authors could also be compromised. But at least now we're talking about "the evil government needs to push malware onto the endpoint" rather than "passively just snoop on what the server receives for years". The cost of the attack is much, much higher. (Also, y'know, binary transparency, reproducible builds, and open source software can help!) https://defuse.ca/triangle-of-secure-code-delivery.htm cc @DefuseSec@infosec.exchange

Open ##3848386