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

Mozilla announces WebAssembly System Interface, what JVM should have been

theregister.co.uk

Post reply on HN
Print view View original

11–20 of 156 posts

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#11

Post by TimTheTinker »

olliej wrote: post #6
neilv wrote: post #4

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article: > ...you can't run Java code in a browser without a plugin... > ...WASM, being memory safe and tuned for validation, also has security advantages over Java applets... > ...explained the difference between WebAssembly and Java thus: "WebAssembly has been…

1. is true 2. Yeah, I read that and was super confused. Literally that was one of the main point of the Java language itself, enforced by the JVM itself. 3. I think this is more a matter of expected level of abstraction, but I agree this is fairly weak. 4. This just seems like standard "the new thing is vastly superior to the old thing", with a valid touch of "the JVM is too heavily abstracted from how computers work…

I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s.

Java was the solution that would provide a robust, symmetric (server+client), secure, highly capable, and portable platform for complex web applications.

Early Java folk weep because Java failed so badly on the client, and something else is stepping in to do what Java could not.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#12

Post by pjmlp »

chubot wrote: post #9

This previous thread covers differences between the JVM and WebAssembly: https://news.ycombinator.com/item?id=19502702 tl;dr - JVM doesn't do enough to separate computation and I/O - JVM doesn't run C code very well, or it requires research-level technology to do so (Graal). This applies to both computation and I/O -- it has a completely different I/O interface than C programs rely on. - Photoshop / Word / Excel / et…

Actually there was an Office like suite written in Java, e.g. Corel Office for Java.

JVM separation between computation and IO can be managed via classloaders and JAAS.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#13

Post by pjmlp »

TimTheTinker wrote: post #11
olliej wrote: post #6

Earlier quoted context omitted.

1. is true 2. Yeah, I read that and was super confused. Literally that was one of the main point of the Java language itself, enforced by the JVM itself. 3. I think this is more a matter of expected level of abstraction, but I agree this is fairly weak. 4. This just seems like standard "the new thing is vastly superior to the old thing", with a valid touch of "the JVM is too heavily abstracted from how computers work…

I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s. Java was the solution that would provide a robust, symmetric (server+client), secure, highly capable, and portable platform for complex web applications. Early Java folk weep because Java failed so badly on the client, and something else is stepping in to do what Java could not.

Java has been quite successful on my client devices running on my pocket, TV and tablets.

Also on client devices running on my credit card, factory management client screens and couple of car infotainment systems.

And on client devices across many corporations still safe from Electron madness.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#14

Post by pjmlp »

Animats wrote: post #3

The JVM in the browser was supposed to be safe, too.

The WebAssembly advocation force will tell you that everything is great and invented by WebAssembly, hand waving over the endless bytecode distribution formats that exist in computing since the 60's.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#15

Post by olliej »

TimTheTinker wrote: post #11
olliej wrote: post #6

Earlier quoted context omitted.

1. is true 2. Yeah, I read that and was super confused. Literally that was one of the main point of the Java language itself, enforced by the JVM itself. 3. I think this is more a matter of expected level of abstraction, but I agree this is fairly weak. 4. This just seems like standard "the new thing is vastly superior to the old thing", with a valid touch of "the JVM is too heavily abstracted from how computers work…

I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s. Java was the solution that would provide a robust, symmetric (server+client), secure, highly capable, and portable platform for complex web applications. Early Java folk weep because Java failed so badly on the client, and something else is stepping in to do what Java could not.

Sorry, which point were you referring to? (I recognize the article as bad, I'm just not sure which problem you're referring to :D )

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#16

Post by olliej »

pjmlp wrote: post #13
TimTheTinker wrote: post #11

Earlier quoted context omitted.

I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s. Java was the solution that would provide a robust, symmetric (server+client), secure, highly capable, and portable platform for complex web applications. Early Java folk weep because Java failed so badly on the client, and something else is stepping in to do what Java could not.

Java has been quite successful on my client devices running on my pocket, TV and tablets. Also on client devices running on my credit card, factory management client screens and couple of car infotainment systems. And on client devices across many corporations still safe from Electron madness.

Java applets are how a depressingly large amount of CC processing happens.

(I think Java Card maybe? is responsible for CC handling in all the magic CC features in phones)

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#17

Post by pjmlp »

olliej wrote: post #8
Animats wrote: post #3

The JVM in the browser was supposed to be safe, too.

The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.

Actually only when one did not bothered to spend any effort with Security Managers, Classloaders separation and JAAS.

All the tools were there.

WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#18

Post by throwaway2048 »

olliej wrote: post #8
Animats wrote: post #3

The JVM in the browser was supposed to be safe, too.

The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.

Web browsers also have all those things.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#19

Post by olliej »

saagarjha wrote: post #10
olliej wrote: post #7

Earlier quoted context omitted.

App Extensions are a really good solution* to the same problem domain, with the additional constraint that you have to support arbitrary compiled code, with all the intentional or unintentional memory safety violations. * I am biased here.

> I am biased here. Haha, I'll defer to you then. But I'm still curious about this: > you have to support arbitrary compiled code, with all the intentional or unintentional memory safety violations But there are multiple barriers here, are there not? First, your code needs to be signed (and notarized, at some point), and then at runtime the app sandbox/entitlements/process separation ensures there's not much you can…

It's not so much a problem of signed vs. unsigned code.

There's the "are you malware that's got through whatever rules exist in the target App Store", but there's also the "is the extension code buggy".

In my experience the latter is the real killer - there are all sorts of things an App Store review process can be used to prevent malware, but they're all dependent on the code doing what static analysis claims it's doing - they can't protect against terrible code -- my experience writing software has taught me that no one rights 100% correct code, 100% time.

Historically GPU drivers have been a terrible source of bugs (it's why WebGL has such tight restrictions on features and shader syntax) not because of intentional malfeasance, but because you're processing arbitrary untrusted content in a trusted environment (my understanding/belief is that the windows driver model has pushed this out of the kernel? please confirm/deny), so functionally forcing that into a restricted execution environment is a win.

Obviously the memory model of WASM still allows for things like use after free, out of bounds access, etc; but at least it's not unbound into the host address space.

Post reply on HN