10 ms·

> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important rol

> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its speed and security across a wide range of devices. I don't mean to be rude, but that's the worst possible answer you could have given. Security should be your first priority, not an afterthought to popularity. That it isn't tells me everything I need to know about the seriousness of your project.

AgentME 9y ago
The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is that the Javascript is delivered to the user's browser from the server on every view. If someone makes a web app for doing end-to-end encrypted messages between users, it can't be secure from the web server operator: the server operator can update the javascript one day to leak users' private keys to the server. The server operator could even serve that malicious change to a subset of users so that it's even less likely to be noticed. In systems where the Javascript isn't loaded on demand from a server on every use (like a server written in node.js, or an application built with electron), then that issue doesn't apply.
- protomikron 9y ago
  I guess your parent meant security problems due to bugs that could have been prevented using a language that has a stricter type system. This does not mean you don't have to deal with security (your case still applies), but at least you get rid of some known bugs in advance.
  - AgentME 9y ago
    If it was just about type systems, then you'd expect similar outrage over web apps written in PHP, Python, and Ruby. Personally I'm a huge fan of how Flow or Typescript add a type system on top of Javascript and think anyone writing a >500 line web app would hugely benefit from using one of them.
    - protomikron 9y ago
      > If it was just about type systems, then you'd expect similar outrage over web apps written in PHP, Python, and Ruby. Oh there sure is - every discussion about programming languages is prone to typing flame wars.
- bandang 9y ago
  Don't see how that differs from any other language. Any program, no matter what the language its written in can send you bad code from the server you have to download it from. You also have the javascript engine/c compiler to worry about, which can of course also be malicious. Then you have the OS to worry about. Then, given all that, you have people pretending to know what they are talking about and stating they take security seriously to worry about. When clearly, all your base are belong to us.
  - AgentME 9y ago
    >Don't see how that differs from any other language. Any program, no matter what the language its written in can send you bad code from the server you have to download it from. :shrug: Javascript is the one language where for its most popular uses, people download the code from a server on every use, and few if any other languages have that as the popular runtime mechanism. I'd prefer it if the article were more obvious about the issue being the download-on-run mechanism rather than being titled as if the problem were the language itself. >You also have the javascript engine/c compiler to worry about, which can of course also be malicious. Then you have the OS to worry about. ... You could say that in any discussion about security, but I'm not sure it's really useful because it seems the implication is to give up on any security problem because perfection isn't possible.
    - bandang 9y ago
      >You could say that in any discussion about security. Exactly. But no one does. Which is why you need to worry about all these guys pretending to know security. Better to assume you are not secure when you mostly are, than assume you are secure when you definately are not. With baseband processors on mobile, and management engine on x64, all security is currently broken at the hardware level anyway. Major mindset shift needed to fix that.
- woranl 9y ago
  Your browser can auto-update, your OS can have backdoor, drone and satellite can fly over our heads and observe our every moves. The safest way is to hide in a cave and put on tin foil hat. If one does not trust the service provider, then don't use their service. Similarly, if one cannot trust their ISP, then stay offline. Trust is critical in many things in life. If we cannot trust anyone anymore, then we have to build everything ourselves. Shit, is the cup of water in front of me safe to drink?
  - AgentME 9y ago
    There's a huge range of possibilities between "I don't trust anyone and use only a CPU I made by hand and software I wrote bit by bit" and "I execute everything blindly that shadyapp.com sends me daily". Debian for example has people review everything that goes into the package repositories, has policies about what types of things are allowed, and the history of packages on the repository can be inspected. An app developer couldn't selectively deliver a malicious key-leaking version of an application to an individual user running Debian with the application installed from Debian's repository.
    - woranl 9y ago
      If one is paranoid, why trust the "people", while View Source is simply a click away. As long as one is low enough in the overall software/hardware stacks, selectivity is really not that difficult to achieve. Protection comes in layers, there is no such thing as absolute security.
cgmg 9y ago
I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.
- chrisco255 9y ago
  Please read "The Shocking Truth about static Types" by Eric Elliott, which includes links to studies on bug density by programming language. JavaScript is in the middle of the pack, and programs built on JS are on average less buggy than C++ and Java. https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 https://medium.com/javascript-scene/the-shocking-secret-abou...
  - cgmg 9y ago
    I didn't didn't mean to imply JS was more or less buggy than C++ or Java. Regarding the article you linked to, I recommend reading the discussion in the comments section (https://medium.com/@oxymor0n/eric-9f4869bb0ecb https://medium.com/@oxymor0n/eric-9f4869bb0ecb). The UC Davis paper, for example, concludes: "...language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing. "This is strong evidence that functional static languages are less error prone than functional dynamic languages … In order to strengthen this assertion we recode the model as above using treatment coding and observe that the Functional-Static-Strong-Managed language class is significantly less defect prone than the Functional-Dynamic-Strong-Managed language class with p = 0.034."
  - danek 9y ago
    I read the studies he cited and I'm not sure we can conclude anything from them. As far as I can tell, "bug density by language" is not a thing you can measure in a meaningful way. It depends on the specific programmers at a specific point in their career, their skill level, domain knowledge for the project, scope of project, who the project manager is, their culture of testing, etc. For example a great JavaScript programmer will make a less buggy program than a mediocre c++ programmer. There is no silver bullet, though the article tries to pass off TDD as one. Also he does concede that static types can power tooling that might "feel like they make us more productive". Disclaimer: I prefer having types but I also think JavaScript is great and don't shy away from using it.
jsnathan 9y ago
I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Note I'm not saying that tests guarantee bug-free code, or that you can't do both. I'm just wondering about which different kinds of bugs you might catch.
- relyio 9y ago
  >I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. >I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Not sure what you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?). But type checking at compile time makes your code less inclined to showcase a certain class of bugs that are the byproduct of ambiguity in the language semantics and logical mistake in the programmer writing the code. And with formal verification you can actually make sure that your logic meets the specs. You can hardly extract stronger correctness guarantees than that! If that interests you, check out Tezos (https://tezos.com/ https://tezos.com/) and github.com/tezos/tezos. The entire codebase is in OCaml. It was on the frontpage a while back: https://news.ycombinator.com/item?id=15061029 https://news.ycombinator.com/item?id=15061029
  - jsnathan 9y ago
    > Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. Yes, I've looked at some of these projects before. And I certainly think it's a good idea to use automated tools to try to prove properties about programs. But I'm more excited about things like property testing than I am about things like strong type systems. And I'm wondering specifically what is the value they bring. No offense, but all of the answers I've gotten so far are very vague, and don't really address my question. I don't doubt that strong type systems can catch bugs, I am wondering how their capabilities in catching bugs differ from test suites. Let me give you an example, say we have a hypothetical language with a strict type system, and we declare a variable to be of type List[Foo]. Then later we use that variable as if it was really of type Foo. That's not gonna work, and a type-checker would catch that at compile-time. But a test suite (that covers the variable access) is going to catch that as well, because the code won't behave as it should. At which point is a strong type system going to surface a bug that a good test suite would not have? Like, can you give an example? > Not sure what you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?). The line is as variable as the strictness of the type system we would compare it to. I guess one could argue that a type system will force the programmer to satisfy it, while a test suite can be written very sloppily. So maybe there is some kind of signalling value in using these types of languages.
KirinDave 9y ago
> Security should be your first priority, Do you bother folks writing blockchain implementations in C, which is at least as hard to deliver secure code in? Just curious if you're consistent in your unfair standard or if this is an even more unfair standard than a literal reading of the text.
- flunhat 9y ago
  The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be. If they chose C as the language for smart contracts/dapps/whatever I would be ragging on them just the same. They had options, and choose the one of the worst ones.
  - qaq 9y ago
    Paypal, Walmart are doing just fine handling huge amounts of transactions in JS. Majority of security breaches are via targeted emails with attachments and have very little to do with language services are written in.
    - qaq 9y ago
      Not sure what is making everyone upset Paypal is doing 1.7 billion transaction per quarter (100 billion + in volume). 80%+ of breaches at companies are via email as a vector.
      - yorwba 9y ago
        Are Paypal and Walmart actually handling their transactions in JS or is that just the front end? In either case, when they transfer money, they hopefully use a sane database transaction mechanism. AFAIK, that would have prevented the DAO hack.
sandGorgon 9y ago
why would they not use Typescript and only "eventually move to it". The primary focus of blockchain languages should be safety and security. even something like Facebook's https://github.com/BuckleScript/bucklescript https://github.com/BuckleScript/bucklescript or https://reasonml.github.io/guide/what-and-why https://reasonml.github.io/guide/what-and-why would be a great starting point since it is built on top of an Ocaml -> javascript toolchain
kin 9y ago
Would you prefer a different language or just a better answer? From my perspective, I don't see how the language makes a difference. In security, you have way more to worry about before even considering an application's underlying implementation language.

AgentME 9y ago

The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is that the Javascript is delivered to the user's browser from the server on every view. If someone makes a web app for doing end-to-end encrypted messages between users, it can't be secure from the web server operator: the server operator can update the javascript one day to leak users' private keys to the server. The server operator could even serve that malicious change to a subset of users so that it's even less likely to be noticed. In systems where the Javascript isn't loaded on demand from a server on every use (like a server written in node.js, or an application built with electron), then that issue doesn't apply.

protomikron 9y ago
I guess your parent meant security problems due to bugs that could have been prevented using a language that has a stricter type system. This does not mean you don't have to deal with security (your case still applies), but at least you get rid of some known bugs in advance.
- AgentME 9y ago
  If it was just about type systems, then you'd expect similar outrage over web apps written in PHP, Python, and Ruby. Personally I'm a huge fan of how Flow or Typescript add a type system on top of Javascript and think anyone writing a >500 line web app would hugely benefit from using one of them.
  - protomikron 9y ago
    > If it was just about type systems, then you'd expect similar outrage over web apps written in PHP, Python, and Ruby. Oh there sure is - every discussion about programming languages is prone to typing flame wars.
bandang 9y ago
Don't see how that differs from any other language. Any program, no matter what the language its written in can send you bad code from the server you have to download it from. You also have the javascript engine/c compiler to worry about, which can of course also be malicious. Then you have the OS to worry about. Then, given all that, you have people pretending to know what they are talking about and stating they take security seriously to worry about. When clearly, all your base are belong to us.
- AgentME 9y ago
  >Don't see how that differs from any other language. Any program, no matter what the language its written in can send you bad code from the server you have to download it from. :shrug: Javascript is the one language where for its most popular uses, people download the code from a server on every use, and few if any other languages have that as the popular runtime mechanism. I'd prefer it if the article were more obvious about the issue being the download-on-run mechanism rather than being titled as if the problem were the language itself. >You also have the javascript engine/c compiler to worry about, which can of course also be malicious. Then you have the OS to worry about. ... You could say that in any discussion about security, but I'm not sure it's really useful because it seems the implication is to give up on any security problem because perfection isn't possible.
  - bandang 9y ago
    >You could say that in any discussion about security. Exactly. But no one does. Which is why you need to worry about all these guys pretending to know security. Better to assume you are not secure when you mostly are, than assume you are secure when you definately are not. With baseband processors on mobile, and management engine on x64, all security is currently broken at the hardware level anyway. Major mindset shift needed to fix that.
woranl 9y ago
Your browser can auto-update, your OS can have backdoor, drone and satellite can fly over our heads and observe our every moves. The safest way is to hide in a cave and put on tin foil hat. If one does not trust the service provider, then don't use their service. Similarly, if one cannot trust their ISP, then stay offline. Trust is critical in many things in life. If we cannot trust anyone anymore, then we have to build everything ourselves. Shit, is the cup of water in front of me safe to drink?
- AgentME 9y ago
  There's a huge range of possibilities between "I don't trust anyone and use only a CPU I made by hand and software I wrote bit by bit" and "I execute everything blindly that shadyapp.com sends me daily". Debian for example has people review everything that goes into the package repositories, has policies about what types of things are allowed, and the history of packages on the repository can be inspected. An app developer couldn't selectively deliver a malicious key-leaking version of an application to an individual user running Debian with the application installed from Debian's repository.
  - woranl 9y ago
    If one is paranoid, why trust the "people", while View Source is simply a click away. As long as one is low enough in the overall software/hardware stacks, selectivity is really not that difficult to achieve. Protection comes in layers, there is no such thing as absolute security.

cgmg 9y ago

I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.

chrisco255 9y ago
Please read "The Shocking Truth about static Types" by Eric Elliott, which includes links to studies on bug density by programming language. JavaScript is in the middle of the pack, and programs built on JS are on average less buggy than C++ and Java. https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3 https://medium.com/javascript-scene/the-shocking-secret-abou...
- cgmg 9y ago
  I didn't didn't mean to imply JS was more or less buggy than C++ or Java. Regarding the article you linked to, I recommend reading the discussion in the comments section (https://medium.com/@oxymor0n/eric-9f4869bb0ecb https://medium.com/@oxymor0n/eric-9f4869bb0ecb). The UC Davis paper, for example, concludes: "...language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing. "This is strong evidence that functional static languages are less error prone than functional dynamic languages … In order to strengthen this assertion we recode the model as above using treatment coding and observe that the Functional-Static-Strong-Managed language class is significantly less defect prone than the Functional-Dynamic-Strong-Managed language class with p = 0.034."
- danek 9y ago
  I read the studies he cited and I'm not sure we can conclude anything from them. As far as I can tell, "bug density by language" is not a thing you can measure in a meaningful way. It depends on the specific programmers at a specific point in their career, their skill level, domain knowledge for the project, scope of project, who the project manager is, their culture of testing, etc. For example a great JavaScript programmer will make a less buggy program than a mediocre c++ programmer. There is no silver bullet, though the article tries to pass off TDD as one. Also he does concede that static types can power tooling that might "feel like they make us more productive". Disclaimer: I prefer having types but I also think JavaScript is great and don't shy away from using it.

jsnathan 9y ago

I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Note I'm not saying that tests guarantee bug-free code, or that you can't do both. I'm just wondering about which different kinds of bugs you might catch.

relyio 9y ago
>I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. >I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Not sure what you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?). But type checking at compile time makes your code less inclined to showcase a certain class of bugs that are the byproduct of ambiguity in the language semantics and logical mistake in the programmer writing the code. And with formal verification you can actually make sure that your logic meets the specs. You can hardly extract stronger correctness guarantees than that! If that interests you, check out Tezos (https://tezos.com/ https://tezos.com/) and github.com/tezos/tezos. The entire codebase is in OCaml. It was on the frontpage a while back: https://news.ycombinator.com/item?id=15061029 https://news.ycombinator.com/item?id=15061029
- jsnathan 9y ago
  > Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. Yes, I've looked at some of these projects before. And I certainly think it's a good idea to use automated tools to try to prove properties about programs. But I'm more excited about things like property testing than I am about things like strong type systems. And I'm wondering specifically what is the value they bring. No offense, but all of the answers I've gotten so far are very vague, and don't really address my question. I don't doubt that strong type systems can catch bugs, I am wondering how their capabilities in catching bugs differ from test suites. Let me give you an example, say we have a hypothetical language with a strict type system, and we declare a variable to be of type List[Foo]. Then later we use that variable as if it was really of type Foo. That's not gonna work, and a type-checker would catch that at compile-time. But a test suite (that covers the variable access) is going to catch that as well, because the code won't behave as it should. At which point is a strong type system going to surface a bug that a good test suite would not have? Like, can you give an example? > Not sure what you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?). The line is as variable as the strictness of the type system we would compare it to. I guess one could argue that a type system will force the programmer to satisfy it, while a test suite can be written very sloppily. So maybe there is some kind of signalling value in using these types of languages.

KirinDave 9y ago

> Security should be your first priority, Do you bother folks writing blockchain implementations in C, which is at least as hard to deliver secure code in? Just curious if you're consistent in your unfair standard or if this is an even more unfair standard than a literal reading of the text.

flunhat 9y ago
The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be. If they chose C as the language for smart contracts/dapps/whatever I would be ragging on them just the same. They had options, and choose the one of the worst ones.
- qaq 9y ago
  Paypal, Walmart are doing just fine handling huge amounts of transactions in JS. Majority of security breaches are via targeted emails with attachments and have very little to do with language services are written in.
  - qaq 9y ago
    Not sure what is making everyone upset Paypal is doing 1.7 billion transaction per quarter (100 billion + in volume). 80%+ of breaches at companies are via email as a vector.
    - yorwba 9y ago
      Are Paypal and Walmart actually handling their transactions in JS or is that just the front end? In either case, when they transfer money, they hopefully use a sane database transaction mechanism. AFAIK, that would have prevented the DAO hack.

sandGorgon 9y ago

why would they not use Typescript and only "eventually move to it". The primary focus of blockchain languages should be safety and security. even something like Facebook's https://github.com/BuckleScript/bucklescript https://github.com/BuckleScript/bucklescript or https://reasonml.github.io/guide/what-and-why https://reasonml.github.io/guide/what-and-why would be a great starting point since it is built on top of an Ocaml -> javascript toolchain

kin 9y ago

Would you prefer a different language or just a better answer? From my perspective, I don't see how the language makes a difference. In security, you have way more to worry about before even considering an application's underlying implementation language.