I think you should say "unproven" instead of "clunky". I don't know any paper that has been published on how to unambiguously verify JS content from a browser p

I think you should say "unproven" instead of "clunky". I don't know any paper that has been published on how to unambiguously verify JS content from a browser plugin. I took a quick look at your code for this. I think you'd be more honest to say that the security of your plugin rests on the inability for an attacker to evade your regex. In particular, the functions apphash_hostile_check() and apphash_split() could leave a route for attackers to smuggle in hostile data without changing the hash. This comment is troubling: // Do we need to check all frames // What happens if tab loads in background? Do we need to run this when tabs switch? Also, using a hash instead of an HMAC leaves you open to length extension attacks. More importantly: why leave a potential door open by taking on the hard MitM problem of parsing and hashing JS from your browser plugin in a way that is unambiguous with how the browser will render it? Instead, ship the encryption code in the plugin itself. Now a user who has downloaded a correct plugin one time has assurance that it won't be swapped out from under themselves for a trojan. However, I'm guessing that would violate your actual business model which divides users' trust into two categories: unaware and unwarranted. The unaware will happily trust your claims of "host-proof security" and not use the plugin. The more technically informed will have unwarranted trust that the browser plugin is difficult to evade. I expect that the latter problem is the "software obfuscation problem" combined with the "vantage point problem". That's not something you want to make your lynchpin of assurance. I hope this convinces you to drop the misnomer of "host-proof security".