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

WebAssembly 101: A developer’s first steps

blog.openbloc.fr

Post reply on HN
Print view View original

121–130 of 153 posts

Re: WebAssembly 101: A developer’s first steps

#121

Post by thingification »

AriaMinaei wrote: post #95

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code safely, because in such a system, all objects – from whole programs to an object as small as the number 4 – would be safe and sealed off from each other on a hardware level. I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984), motivated b…

'Sandboxing' within single processes would still be necessary, at least (and I suspect at many other levels too, practically). I think it is necessary now, but that is not (yet?) appreciated.

If you haven't seen it already, I and many better educated people recommend http://www.erights.org/talks/thesis/ (a pleasant read, even if I don't judge it by comparison with other theses) - focuses on distributed computation and language-level capabilities

Re: WebAssembly 101: A developer’s first steps

#122

Post by livingparadox »

toni wrote: post #110

Is there any about:config flag in Firefox to disable WASM all together?

Why do you want to do that? afict, this shouldn't be increasing the attack surface any more than almost any new language feature. Its spec-ed to run in the same VM as JS is currently.

Re: WebAssembly 101: A developer’s first steps

#123

Post by flukus »

thingification wrote: post #118
flukus wrote: post #117

Earlier quoted context omitted.

Have capability based systems solved the "user clicks yes to everything" problem? Until then they solve nothing.

Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the f…

> and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know.

I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have to prompt the user or does it have to have to be granted the access at install time? As far as I'm aware those are the only two options.

> The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the first place. That idea will be better tested if they ever take off in more than the isolated areas they're currently found of course.

It sounds like it has to prompt users to get permissions:

> This includes a KDE-based PowerBox scheme allowing sandboxed applications to request user-driven file open using standard dialogs.

Re: WebAssembly 101: A developer’s first steps

#124

Post by thingification »

flukus wrote: post #123
thingification wrote: post #118

Earlier quoted context omitted.

Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the f…

> and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have…

> It sounds like it has to prompt users to get permissions:

Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place.

As long as the thing that is being granted access is isolated and nothing else grants it access, problem solved.

It's a very neat idea, and it works.

This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority".

Here's an old talk with demonstrations by Marc Stiegler, who I believe came up with the concept:

https://www.youtube.com/watch?v=vrbmMPlCp3U

More recently I hear essentially the same idea has been used in mobile phone security (I don't have that kind of mobile phone). The capability ideas that surround it are not widely known or understood, though.

Re: WebAssembly 101: A developer’s first steps

#125

Post by thingification »

flukus wrote: post #123
thingification wrote: post #118

Earlier quoted context omitted.

Ha To be honest: Yes? I would say that is the conventional wisdom in the (small) capability community. I'm sure that oversimplifies carefully-nuanced opinions of course, but, yes. An example is mentioned here ('angels', 'Power Boxes'): https://www.cl.cam.ac.uk/research/security/capsicum/ The idea is that capability-based user interfaces do not need to ask those "Yes, get my work done/No, be secure" questions in the f…

> and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have…

> I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x?

If you're interested in more/different examples than the Stiegler talk, google ka ping yee capability ui patterns

Re: WebAssembly 101: A developer’s first steps

#126

Post by flukus »

thingification wrote: post #124
flukus wrote: post #123

Earlier quoted context omitted.

> and in part I think because of a failure to communicate the ideas to the best and most influential implementers - exactly why I don't know. I agree here, that page is the perfect example, all I see is a page full of academic buzzwords and not a "How this works in practice". So we limit what resources an app has access to, that's easy enough to understand, but what happens when an app needs resource x? Does it have…

> It sounds like it has to prompt users to get permissions: Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place. As long as the thing that is being granted access is isol…

Thanks for the video, I'll give it a watch when I'm not at work, so apologies if any of the below is covered by the video.

> Well, in some sense, yes, but really no: The idea of a PowerBox is that the very action of opening a file already demonstrates the user's intent to grant access. Normally one does not conceive of opening a file as a prompt for permission, because it is necessary to designate a file in the first place.

That's fine in simple cases, windows store apps already work this way, but what about something like an IDE where you want to open many files? I suppose granting permission at a folder level is possible, but then what about something like vim where I want to switch between files and there is no file open dialog? What happens when I want to install an a different file browser that needs global read/write abilities?

> This goes along with the capability slogans "No ambient authority", and (stronger) "No designation without authority".

How does that work with something like an IDE? You have to pass the compiler a bunch of files names and you'd have to pass the access permission with them, then compiler has to create a new executable with the ability to run and pass the access back to the IDE. And that's just for the simple case. For that matter, how does it work with command line tools that pipe file names between them? Every demo and implementation I've seen appears to be under the impression that apps are self contained.

Re: WebAssembly 101: A developer’s first steps

#127

Post by lacampbell »

ThePhysicist wrote: post #78
BenoitEssiambre wrote: post #59

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

For me the main potential of asm.js/WebAssembly does not lie in the fact that it is faster, but in that it provides us with a way to run native C/C++ code inside the browser without adapting it (much), and doing this at a speed which is not (much) worse than the speed of the original code. This in turn makes functionality that was traditionally very hard to get in a browser/JS environment suddenly very easy to get: -…

This is the exciting new world I am thinking (hoping?) might happen. If this web assembly thing ends up being a success, the web is going to start taking an even larger slice of the development pie.

There will still be a place for native apps of course, but that place will IMO be much smaller.

Re: WebAssembly 101: A developer’s first steps

#128

Post by angersock »

buu700 wrote: post #64
Houshalter wrote: post #38

Earlier quoted context omitted.

Bullshit. Wasm can't do anything js can't. Especially with asm.js. Don't try to argue that minified or transpiled js is somehow more readable than wasm. At least it's easier to decompile in theory. It's absolutely not a "tool for surveillance". How exactly are you going to surveil anything with it? It's not even a replacement for js, or at least it shouldn't be used that way. No GC for instance. And if you are doing…

Yep. WebAssembly today is literally just a better/faster asm.js. The argument against it linked above is nonsense. Most arguments like this that I see tend to fall into one of these boxes: 1. Using wasm as springboard to argue against something else they don't like. — e.g. disliking closed source code / source obfuscation / minification is a fair position, but it's not helpful to anyone to pretend that wasm introduce…

And asm.js wasn't the correct answer either. Nor is minification, as is pointed out in my original comment.

On (1), you're ignoring the fact that asm.js/wasm/low-level languages are in general harder to reverse than uglified high-level stuff. You can see the details perfectly, sure, but emitted compiled code (say, from Duff's device or something) is a lot harder to back out of than the equivalent minified source code--especially when you see crazy shit like "-O 3" would make. tl,dr; compilation != minification, and acting like they are is at best incorrect.

Your (2) fails to address the entire complaint about wasm (aka asm.js) leading to bad things and ecosystem bloat. You just say "well we can kinda already do it", but fail to address any of the substance of the actual argument I made.

Your (3) misses the point completely about "write in native code" and not "write in something that gets run in an interpreter". Like, you've missed the whole point that if you need performance, you need to be writing something outside the browser, and if you don't need performance existing JS is sufficient.

Re: WebAssembly 101: A developer’s first steps

#129

Post by pitaj »

kebolio wrote: post #112
ThePhysicist wrote: post #19

I'm trying to use asm.js to port Python to JS as a shared library, which would allow us to load and run arbitrary CPython modules (compiled for JS) in the browser. I generate code using emscripten, which is also able to generate WASM (which I'm not using at the moment though). My experience so far: Emscripten is quite mature and compiles even very complex C/C++ code without complaining. Statically linking code works…

Slightly disconcerted that the first thing webdevs are rushing to do with wasm is to port massive language runtimes to it, continuing the web tradition of piling shit upon shit upon shit. Personally believe that this is totally the wrong idea; compilation or transpilation from intermediate forms is far more interesting and sensible in my view

It's not like people are planning on using these in production. It's just some fun hobby projects that are useful for, say, online Python tutorials and stuff.

Re: WebAssembly 101: A developer’s first steps

#130

Post by Ace17 »

reedlaw wrote: post #40
almostdigital wrote: post #9

I recommend anyone wanting to experiment with WASM to check out https://github.com/dcodeIO/webassembly which takes a lot of pain out of setting up the toolchain and lets you produce much leaner binaries as well. Also keep an eye on https://github.com/dcodeIO/AssemblyScript :)

How about https://github.com/WebAssembly/binaryen ?

Knowing that LLVM has a wasm backend ; could someone explain what role binaryen plays here?
Post reply on HN