What are the known limitations with browser addon/extensions that do in browser encryption vs a native implementation in the browser. The addon would expose cryptographic primitives for use in JavaScript.

The browser addon would act as an interim solution to "The web cryptographic API" under development by the W3C.

  • 1
    That may depend on what the addon is supposed to do. Could you maybe describe your "project" or at least give some context to the situation.
    – HamZa
    Aug 14, 2013 at 22:15
  • @HamZa clarified
    – Null
    Aug 14, 2013 at 23:07
  • If the web crypto API is not actually available then which "native implementations" are you referring to?
    – symcbean
    Aug 15, 2013 at 9:56
  • @symcbean the native implantation would be once the web crypto api is available in browser as a native feature. What im looking for in an answer, is what are the limitations of a native feature vs a browser addon. Surely there security model is very different and therefore browser addon would be limited?
    – Null
    Aug 15, 2013 at 10:05
  • I'd rather write the crypto in pure javascript. Only thing you really need the browser for is PRNG. Latest firefox, chrome and opera offer a secure PRNG, for IE and older browsers it's tricky. Aug 15, 2013 at 14:16

2 Answers 2


Browser add-ons are browser-specific, so any answer to your question can only be very general.

Some browsers allow for plugins as any piece of native code, which can, of course, do anything that native code can do. For these, the add-on could provide all the functionality you can wish for. Other browsers primarily enforce Javascript-based add-on logic, so whatever the add-on does, it must do within the constraints of that programming language. Javascript is not good at computing-intensive tasks, and cryptography is such a task. The add-on would be bad, for instance, at decrypting a video file or anything similarly bulky.

Note that when the browser allows for add-ons with native code, the native code will depend on the OS and CPU architecture. This is known to be a source of severe headaches for developers. Javascript-based add-ons are much more portable, but pay for it through much reduced performance and also greater isolation from the local machine.

The biggest problem with a browser add-on is that not everybody has it. If people must install an add-on to use your Web site, then this no longer is a Web site; the whole point of a Web site is that everybody can use it without any prior installation. An add-on is useful only when it provides optional client-side functionality (so your site code cannot rely on its presence), or when everybody already has it (in which case it no longer is an add-on, but a "native feature").

The two "add-ons" which got close to being sufficiently prevalent to be considered as "always there" are Flash and Java, but both are still restrictive (an iPad, for instance, has neither). It would be quite improbable for your add-on to achieve an even similar level of success. This means that whatever reasons which would make doing your browser-side cryptography in a Java applet a bad idea, also apply to the scenario of using a crypto add-on (and Java, at least, has the muscle and existing code base which allows for powerful cryptography).

  • The crypto browser addon would still need to fallback to a pure javascript solution(i.e. Progressive enhancement). If the user wants the added security they could use the browser addon. I was looking to move from a pure javascript solution to the browser based addon direction based on feedback from another forum. Im just trying to widen the discussion, thanks for your answer.
    – Null
    Aug 17, 2013 at 14:23
  • I wonder if Javascript based addons that worked over HTTPS would compress the data, and also be vulnerable to HTTPS-compression-style attacks. Sep 16, 2013 at 11:41

Service providers usually depend on client-side crypto because they don't want to act like a single point of failure from security standpoint. For example if you do encryption on server side, a malicious attacker (or intelligence services) with access to the server will be able to intercept all the passwords or simply disable encryption.

If you use JavaScript for client-side encryption you basically implement host-based security that is not much better than the previous case: users will have to download some scripts from a remote location each time they want to do crypto, and if that host (or the network path) gets compromised, the attacker will be able to backdoor the provided code. This was one of the original problems of CryptoCat. You should also read Matasano's JavaScript Cryptography Considered Harmful that explains why JavaScript is generally a bad choice for implementing crypto.

This is mostly true even if you use browser JS in conjunction with some kind of installed add-on.

Most of the points of Thomas Pornin about add-ons are valid, but I would rather depend on purely native browser add-ons than JS, especially if they make use of well-tested crypto libraries.

  • the article you referenced was my initial reason for going the browser addon route. As this was suggested by the Author of the article in another forum. There are also various critiques of the article you reference, log.nadim.cc/?p=33 blog.jparsons.net/2012/08/…
    – Null
    Aug 17, 2013 at 14:29
  • Well, both authors of the critiques rely on the add-on approach now, I think this fact speaks for itself (aside from the fact that neither response addressed the problem of host-based security). Kobeissi argued that although JS crpyto is hard and hacky, it can be implemented correctly - however his CryptoCat system turned out to be failing badly two months later: tobtu.com/decryptocat.php
    – buherator
    Aug 18, 2013 at 9:30
  • thanks for your time & reply. Do you have any ideas on the host based security issue, or should I rather ask it as a new question?
    – Null
    Aug 18, 2013 at 10:31
  • If you use addons your users only have to trust your server once, when they install the addon (not counting the updates). As the Matasano article says, this is a chicken-egg problem that can only be resolved by making trade-offs.
    – buherator
    Aug 18, 2013 at 10:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .