What a confused image.
- TiVo complied with the GPLv2 and distributed source code for their modifications to Linux. What they did not do was distribute the cryptographic keys which would allow TiVo customers to run modified versions it on their TiVo devices. This is what motivated the so-called anti-tivoization clause in GPLv3 (the “Installation Information” part of Section 6. Conveying Non-Source Forms.).
- Linux remains GPLv2, so, everyone today still has the right to do the same thing TiVo did (shipping it in a product with a locked bootloader).
- Distributing Linux (or any GPLv2 software) with a threat of violence against recipients who exercise some of the rights granted by the license, as is depicted in this post, would be a violation section 6 of GPLv2 (“You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.”).
Regarding your browser-based thing: what are the specific capabilities of the “threat agents” (in your threat model’s terminology) which your e2ee is intended to protect against?
It seems like the e2ee is not needed against an attacker who (a) cannot circumvent HTTPS and (b) cannot compromise the server; HTTPS and an honest server will prevent them from seeing plaintext. But, if an attacker can do one of those things, does your e2ee actually stop them?
The purpose of e2ee is to protect against a malicious server, but, re-fetching JavaScript from the server each time they use the thing means that users must actually rely on the server’s honesty (and HTTPS) completely. There is no way (in a normal web browser) for users to verify that the JavaScript they’re executing is the correct JavaScript.
If you run a browser-based e2ee service like this and it becomes popular, you should be prepared that somebody might eventually try to compel you to serve malicious JavaScript to specific users. Search “lavabit” or “hushmail” for some well-documented cases where this has happened.