5 ms·

I have seen people point to using plugins to verify assets delivered by the server, but at that point, why not just do the crypto with the plugin.

• Jach 13y ago
  The benefit of a plugin to verify assets is that it can work with other things besides the crypto lib. As your sibling comment mentions an attacker could deliver other JS that just traces your input or something different. Well, a user could ask a plugin to say "Hey, track the JS on this page. Alert me if any of it changes, any of it is removed, or any new JS is added." After an alert, the user can see a diff, decide to trust the new set of JS (maybe it was just a jquery update), try and run the old set instead, or don't run anything. A cool plugin could even connect with a repository of peer-reviewed changes so that non-technical users can still safely use it, so they might see "This change to blah.js has been marked as OK by X respectable users (see reasons)" or "It's a trap! Foobar.com has been compromised by (feds|anonymous|gary)."
  • tptacek 13y ago
    How exactly do you use a plugin to verify the state of a Javascript runtime? You can't just verify assets; you need to verify the current bindings of every function relevant to your crypto code.
    • Jach 13y ago
      How are the bindings supposed to change without loading different assets, apart from an eval() somewhere?
      • tptacek 13y ago
        List every possible way a browser Javascript application might end up rebinding a function.