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

The Bytecode Alliance: Building a secure, composable future for WebAssembly

hacks.mozilla.org

Post reply on HN
Print view View original

101–110 of 265 posts

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#101

Post by gridlockd »

weberc2 wrote: post #94
stefan_ wrote: post #81

This is historically the kind of thing that people think is very cool and important, but has turned out to not matter at all. "Languages matter" must be the biggest enduring fallacy of computer programming. It has an obvious corollary in believing processor architectures are important.

It matters a whole lot. There's lots of code written in various languages and it's often prohibitive to use it in your own project because making the languages speak with each other (especially if you have performance concerns) is a lot of work. I don't expect WASM to make this trivial, but to say that it doesn't matter is patently wrong.

I think the point is that your laundry list of features in your language of choice does not really matter when it comes to adoption.

For instance, memory safety does not really matter so much that people would stop using unsafe languages.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#102

Post by Narishma »

arendtio wrote: post #97
Narishma wrote: post #93

Are those drawings supposed to be clickable? When I do so, it just opens and immediately closes a new tab or window. Firefox 70 on Windows if it makes a difference.

Works for me. Opens a new tab with an image, e.g.: https://2r4s9p1yi1fa2jd7j43zph8r-wpengine.netdna-ssl.com/fil... FF 70 on Arch Linux.

That's weird. In fact it does the same with your link, though I can open it in the same tab. If I try to open it in a new tab or window, it just closes immediately.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#103

Post by Narishma »

jml7c5 wrote: post #99
Narishma wrote: post #93

Are those drawings supposed to be clickable? When I do so, it just opens and immediately closes a new tab or window. Firefox 70 on Windows if it makes a difference.

Bad adblock filter, maybe?

Yup, that was it. Disabling the ad blocker fixed this.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#104

Post by zzzcpan »

weberc2 wrote: post #94
stefan_ wrote: post #81

This is historically the kind of thing that people think is very cool and important, but has turned out to not matter at all. "Languages matter" must be the biggest enduring fallacy of computer programming. It has an obvious corollary in believing processor architectures are important.

It matters a whole lot. There's lots of code written in various languages and it's often prohibitive to use it in your own project because making the languages speak with each other (especially if you have performance concerns) is a lot of work. I don't expect WASM to make this trivial, but to say that it doesn't matter is patently wrong.

Why high level languages should be able to easily speak with each other? Wouldn't this defeat the purpose of having more than one language, since they would be effectively identical?

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#105

Post by seph-reed »

Been working with web tech since 2000... something about WASM rubs me the wrong way, at least for use in the web. It's probably the lack of human readable source code (I'm not a big fan of minified code for the same reason).

If it wasn't so impossible to work with W3C, I think it would probably make more sense for the web to work towards something like more strict, compilable typescript. Then sites could download the source, compile, and cache.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#107

Post by naasking »

sparker72678 wrote: post #13

Super cynical, I realize, but whenever I see the description “secure by default” for something computer related, and they don’t mean, “we unplugged it,” I assume what they really mean is, “we made the code so complex we can’t find the problems.”

Instead, they mean something sensible: that permission has been linked with designation as per capability security. Adding feature extensions are thus linked with the authorities required to implement those features, and the modules implementing those features can't do anything behind the scenes.

So you would no longer be able to amplify a string value into a file descriptor as you can in systems with ambient authority (which is nearly every system in widespread use today).

So "secure by default" here means, "programs conform to least privilege".

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#108

Post by AgentME »

stefan_ wrote: post #81

This is historically the kind of thing that people think is very cool and important, but has turned out to not matter at all. "Languages matter" must be the biggest enduring fallacy of computer programming. It has an obvious corollary in believing processor architectures are important.

The cross-language interoperability of WebAssembly seems practically like a happy side-effect of its design; I don't think it would look much differently at present if it had originally been built to target only C (in a sandboxable way). Most of the article still applies even if you ignore other language support. The first priority for WebAssembly seems to be making things strongly sandboxed.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#109

Post by [deleted] »

sparker72678 wrote: post #13

Super cynical, I realize, but whenever I see the description “secure by default” for something computer related, and they don’t mean, “we unplugged it,” I assume what they really mean is, “we made the code so complex we can’t find the problems.”

[deleted]

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#110

Post by syrusakbary »

npmccallum wrote: post #64
syrusakbary wrote: post #30

First of all, congrats on forming the alliance! > Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data That's what we are working towards on Wasmer, the server side WebAssembly runtime - https://github.com/wasmerio/wasmer In fact, we already have a lot of different language integrations (maintained by us and the community) and our software is the pione…

Disclaimer: I'm from the Enarx project ( https://enarx.io ) which is associated with the BytecodeAlliance. I think a good analogy is: wasmer is to qemu as BytecodeAlliance is to rust-vmm. Wasmer is a general purpose WASM runtime. But BytecodeAlliance is a place to build tooling for the construction of runtimes (WASM or otherwise), including special purpose runtimes. I think there is a lot of space for both in the gro…

Agreed! (regarding the non-browser WASM market)

Not sure if I got the analogy, but all I can say is that I'm very excited about the Enarx initiative :)

Post reply on HN