4 ms·

Would you trust it more if it required JavaScript instead of Java? Why or why not? Would it matter if the JavaScript code was un-obfuscated and open source?

Would you trust it more if it required JavaScript instead of Java? Why or why not? Would it matter if the JavaScript code was un-obfuscated and open source? Java is now owned by Oracle, which has always been and will always be evil. But there are multiple JavaScript implementations available, so it would be harder for the code to be compromised by a back door in the VM. And the people developing JavaScript interpreters are generally not as shady and untrustworthy as Oracle. (Although one of them is known to be inexplicably homophobic...)

dragonwriter 13y ago
> Java is now owned by Oracle, which has always been and will always be evil. > But there are multiple JavaScript implementations available These are posed as if they are a contrast, but they are not. There are multiple Java implementations available, as well.
- SimHacker 13y ago
  But how many people actually use non-Oracle Java VMs as the default Java VM in a web browser? Or even as a non-default Java VM?
  - stormbrew 13y ago
    To the former, everyone who uses an Android device (Dalvik).
    - lvh 13y ago
      Dalvik isn't a JVM. It's a virtual machine for which someone has written a compiler from JVM bytecode to its native bytecode.
      - stormbrew 13y ago
        I think this is more of a legal convenience than anything else. It probably would be an extended JVM if Google weren't concerned about Sun/Oracle's litigious nature when it comes to extending the JVM. Really it's a VM that runs JVM code, even though it needs an extra translation step. It's not like there's anything else that targets it afaik.
  - tlarkworthy 13y ago
    OpenJDK ships with Ubuntu, its a pain to install the Oracle one
comex 13y ago
Oracle being intentionally malicious is unlikely, but Java has had well publicized security issues lately. (1) I'm not sure that the JVM is actually less secure than JavaScript engines, but it's unnecessary enough in the modern web that many users like to turn it off entirely. Requiring it to be on is a step back. (2) The applet is trusted. So if it's backdoored or exploited, the adversary gets your entire computer rather than "just" your email. This is par for the course for native apps, Java is harder to exploit than native code, and in theory email should not really be much of an attack vector (plain text and maybe basic HTML); but this app is not well-known and is thus more likely to have simple programming errors (not that popular services are immune from those either!), the browser security model is easier to screw up, and webapps are expected to be sandboxed. Again, a step backwards. (3) The choice of Java may be an indicator of inflexibility, thus poor programming skills, thus insecurity. This is speculation, but far from improbable. Off-topic, their claim to be (effectively) protected against rogue CAs is dubious, never mind the claim that they are the only provider with such protection.
bobwaycott 13y ago
out of curiosity, which js interpreter developer(s) is/are inexplicably homophobic? this is news to me.
- bulatb 13y ago
  Brendan Eich, the creator of JavaScript, was accused of homophobia for donating $1000 to the Prop 8 campaign. https://www.google.com/search?q=brendan+eich+homophobia https://www.google.com/search?q=brendan+eich+homophobia
iuguy 13y ago
> Would you trust it more if it required JavaScript instead of Java? > Why or why not? A couple of months ago I started working on a contact form using OpenPGP.js[1]. The idea was that by having the content in javascript it wouldn't need third-party plugins and would send encrypted e-mails to an unknown address. Ideal for something like a drop box or simply to ensure that your granny can securely contact you without understanding encryption. After considerable thought and evaluation I decided against publishing it rather than risk people adopting a solution I felt that ultimately I couldn't appropriately secure. Fundamentally the biggest problems with Javascript cryptography (as far as I can tell, and I'm not a cryptographer, I'm a security specialist) are (in no particular order): * Differences between implementations in different browsers, different Operating Systems, the same browser on different Operating Systems etc. * Sources of randomness across different platforms * Getting the Javascript to the user securely in a trustworthy manner * Caching (which can be both good and bad depending on whether the point above has been resolved) These are just a few of the problems without even getting to the horrible stuff like bugs in JS implementations that could either affect crypto safety or result in exploitable conditions compromising either data or the client system. Java on the other hand is fairly standard across systems (to a point, but a point that can be largely controlled by the applet) and has some fairly robust crypto interfaces and 3rd-party components. That trust issue about getting the code to the target securely is still the same. [1] - http://openpgpjs.org/ http://openpgpjs.org/

dragonwriter 13y ago

> Java is now owned by Oracle, which has always been and will always be evil. > But there are multiple JavaScript implementations available These are posed as if they are a contrast, but they are not. There are multiple Java implementations available, as well.

SimHacker 13y ago
But how many people actually use non-Oracle Java VMs as the default Java VM in a web browser? Or even as a non-default Java VM?
- stormbrew 13y ago
  To the former, everyone who uses an Android device (Dalvik).
  - lvh 13y ago
    Dalvik isn't a JVM. It's a virtual machine for which someone has written a compiler from JVM bytecode to its native bytecode.
    - stormbrew 13y ago
      I think this is more of a legal convenience than anything else. It probably would be an extended JVM if Google weren't concerned about Sun/Oracle's litigious nature when it comes to extending the JVM. Really it's a VM that runs JVM code, even though it needs an extra translation step. It's not like there's anything else that targets it afaik.
- tlarkworthy 13y ago
  OpenJDK ships with Ubuntu, its a pain to install the Oracle one

comex 13y ago

Oracle being intentionally malicious is unlikely, but Java has had well publicized security issues lately. (1) I'm not sure that the JVM is actually less secure than JavaScript engines, but it's unnecessary enough in the modern web that many users like to turn it off entirely. Requiring it to be on is a step back. (2) The applet is trusted. So if it's backdoored or exploited, the adversary gets your entire computer rather than "just" your email. This is par for the course for native apps, Java is harder to exploit than native code, and in theory email should not really be much of an attack vector (plain text and maybe basic HTML); but this app is not well-known and is thus more likely to have simple programming errors (not that popular services are immune from those either!), the browser security model is easier to screw up, and webapps are expected to be sandboxed. Again, a step backwards. (3) The choice of Java may be an indicator of inflexibility, thus poor programming skills, thus insecurity. This is speculation, but far from improbable. Off-topic, their claim to be (effectively) protected against rogue CAs is dubious, never mind the claim that they are the only provider with such protection.

bobwaycott 13y ago

out of curiosity, which js interpreter developer(s) is/are inexplicably homophobic? this is news to me.

bulatb 13y ago
Brendan Eich, the creator of JavaScript, was accused of homophobia for donating $1000 to the Prop 8 campaign. https://www.google.com/search?q=brendan+eich+homophobia https://www.google.com/search?q=brendan+eich+homophobia

iuguy 13y ago

> Would you trust it more if it required JavaScript instead of Java? > Why or why not? A couple of months ago I started working on a contact form using OpenPGP.js[1]. The idea was that by having the content in javascript it wouldn't need third-party plugins and would send encrypted e-mails to an unknown address. Ideal for something like a drop box or simply to ensure that your granny can securely contact you without understanding encryption. After considerable thought and evaluation I decided against publishing it rather than risk people adopting a solution I felt that ultimately I couldn't appropriately secure. Fundamentally the biggest problems with Javascript cryptography (as far as I can tell, and I'm not a cryptographer, I'm a security specialist) are (in no particular order): * Differences between implementations in different browsers, different Operating Systems, the same browser on different Operating Systems etc. * Sources of randomness across different platforms * Getting the Javascript to the user securely in a trustworthy manner * Caching (which can be both good and bad depending on whether the point above has been resolved) These are just a few of the problems without even getting to the horrible stuff like bugs in JS implementations that could either affect crypto safety or result in exploitable conditions compromising either data or the client system. Java on the other hand is fairly standard across systems (to a point, but a point that can be largely controlled by the applet) and has some fairly robust crypto interfaces and 3rd-party components. That trust issue about getting the code to the target securely is still the same. [1] - http://openpgpjs.org/ http://openpgpjs.org/