Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisk: Blockchain development in JavaScript

blog.lisk.io

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#101

Post by AgentME »

woranl wrote: post #91
AgentME wrote: post #15

Earlier quoted context omitted.

The main problem with Javascript cryptography called out in 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…

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 bu…

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.

Re: Lisk: Blockchain development in JavaScript

#102

Post by danek »

chrisco255 wrote: post #90
danek wrote: post #64

Earlier quoted context omitted.

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 pr…

I agree with all your points. I think, if anything, the study should show that JS is not inherently worse than any other language. It's got a bad rap, that mostly has to do with weird quirks in the language (i.e. == vs ===), but those quirks are easy to avoid. I do think testing in general is a good way to build more reliable programs.

Yes, testing along with strict linter settings goes a long way.

Re: Lisk: Blockchain development in JavaScript

#103

Post by AgentME »

bandang wrote: post #61
AgentME wrote: post #15

Earlier quoted context omitted.

The main problem with Javascript cryptography called out in 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…

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 tak…

>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.

Re: Lisk: Blockchain development in JavaScript

#104

Post by AgentME »

protomikron wrote: post #16
AgentME wrote: post #15

Earlier quoted context omitted.

The main problem with Javascript cryptography called out in 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…

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.

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.

Re: Lisk: Blockchain development in JavaScript

#105

Post by UncleMeat »

jsnathan wrote: post #26
flunhat wrote: post #13

> ...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 s…

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…

Yes.

Here is one paper of interest https://www.comp.nus.edu.sg/~loiluu/papers/oyente.pdf.

Re: Lisk: Blockchain development in JavaScript

#106

Post by jsnathan »

UncleMeat wrote: post #105
jsnathan wrote: post #26

Earlier quoted context omitted.

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…

Yes. Here is one paper of interest https://www.comp.nus.edu.sg/~loiluu/papers/oyente.pdf .

Hi, thanks for the link. I've seen this paper, but it has nothing to do with strongly typed languages, as far as I can tell. In fact, there is no mention of types in the paper at all, it's strictly automated analysis.

Re: Lisk: Blockchain development in JavaScript

#107

Post by protomikron »

AgentME wrote: post #104
protomikron wrote: post #16

Earlier quoted context omitted.

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.

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.

> 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.

Re: Lisk: Blockchain development in JavaScript

#108

Post by bandang »

AgentME wrote: post #103
bandang wrote: post #61

Earlier quoted context omitted.

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 tak…

>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 obvi…

>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.

Re: Lisk: Blockchain development in JavaScript

#109

Post by woranl »

AgentME wrote: post #101
woranl wrote: post #91

Earlier quoted context omitted.

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 bu…

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 dev…

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.

Re: Lisk: Blockchain development in JavaScript

#110

Post by danmaz74 »

johnhenry wrote: post #69
danmaz74 wrote: post #47

Earlier quoted context omitted.

* Most accessible language in the planet -> any script kiddie can write dapps right away without even bothering to study what the risks are and what is happening under the hood * dapps manage real money in real time * end users aren't able to evaluate the quality of the dapps they entrust their money to * what could possibly go wrong?

I think you may have inverted the responsibility. > any script kiddie can write dapps right away without even bothering to study what the risks are and what is happening under the hood It's not the contract author's responsibility to guarantee that the contract works properly -- they aren't forcing anyone to use it. Any script kiddie SHOULD be able to write a dapp. Most people don't [understand that they don't] under…

> Any script kiddie SHOULD be able to write a dapp. Most people don't [understand that they don't] understand the complexities our our modern financial system, but we don't require that one has a PhD in order to spend a dollar. A low barrier to entry when dealing with financial transactions is desirable.

I think that simple market approach works well when customers are able to understand and compare what they are buying (or investing into), but it doesn't work when customers don't have the means to do so. That's why the financial industry is one of those that needs to be heavily regulated. So, no, IMHO having lowering the barrier to entry to write complex financial instruments that can trade hundreds of millions of dollars is a recipe for disaster, not for useful innovation.

Of course I understand that, if you're a libertarian, you're not going to agree :)

Post reply on HN