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

61–70 of 156 posts

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

#61

Post by fulafel »

StevePerkins wrote: post #59

Speaking as someone who has made their career with Java, "what the JVM ought to have been" is marketed for server-side use from the beginning. It was poorly suited for the browser from the earliest days, and even now the language and runtime have evolved to make it a round peg for that square hole no matter how WASM develops. Yet because students and younger webdevs see it through the prism of trying to be a browser-…

Java in the beginning was standaline on the client side too. The web browser plugin came post 1.0 and the pre 1.0 (Oak) target applications were more IoT, not web

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

#62

Post by quantummkv »

avian wrote: post #58
ksec wrote: post #47

Earlier quoted context omitted.

>I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel. It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems. I think it might have to do with people considering 40 as very old in Silic…

I often wonder why this is the fact in software development and not nearly much so in other fields. Isn't the point of education that each generation doesn't have to learn past mistakes by repeating them? Do computer science curricula not include enough historical perspective? I feel like other fields of engineering don't have such a dismissive approach to their own pasts. Show an electrical engineering class an old…

> Do computer science curricula not include enough historical perspective?

Anecdotally speaking, the average web developer does not have any formal computer science education. Most are self taught or attend a bootcamp or two at most. They have excellent vocational skills, but little knowledge of anything in computing outside of their narrow path of learning.

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

#64

Post by readittwice »

pjmlp wrote: post #17
olliej wrote: post #8

Earlier quoted context omitted.

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.

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

Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all.

IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the language or the specific application. If you want to solve this in WASM, I predict you couldn't just compile all different languages to WASM anymore without significant changes to the codebases. If this would be feasible at all..

Rewriting those huge C/C++ codebases is simply not an option, new applications can be written in safe languages and then compiled to WASM.

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

#65

Post by pjmlp »

TomMarius wrote: post #56
kevingadd wrote: post #26

Earlier quoted context omitted.

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regr…

Using the WASM GC part instead of lieanr memory will solve that, right? I know it's not a possibility for all programs, but overall, it'll help?

Not at all, because a large majority of applications being ported to WASM are written in C and C++, with all security caveats it entails.

Garbage Collected implementations of C and C++ do exist, and only thing that their GC fixes is use after free.

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

#66

Post by IshKebab »

steve19 wrote: post #49
DonHopkins wrote: post #39

Earlier quoted context omitted.

>"WebAssembly has been designed to scale from tiny devices to large server farms or CDNs..." What's ironic is that the "tiny devices" and even "high end professional desktop workstation and server devices" that Java was originally designed to run on when it was started in 1990 were MUCH tinier than the devices considered "tiny" today. How many more times faster is a typical smartphone today (Raspberry Pi 3: 2,451 MIP…

Forget full computers, an official Java subset even runs on every GSM SIM card. It is incredible! https://en.m.wikipedia.org/wiki/Java_Card

People keep bringing this up but Java Card is a really small subset of Java so you can't draw any conclusions. In particular it has no garbage collection, which is easily the heaviest part of Java.

> Many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).

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

#67

Post by pjmlp »

readittwice wrote: post #64
pjmlp wrote: post #17

Earlier quoted context omitted.

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.

> WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking. Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all. IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the l…

Java bytecode requires bound checking and null pointer validation, as per the JVM specification.

CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed.

To load an unsafe Assembly, the host has to explicitly allow it.

Similar examples on IBM and Unisys language environments, e.g. on ClearPath, the admin must allow the execution of binaries tainted with unsafe code.

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

#68

Post by dmitriid »

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…

> WebAssembly has been designed to scale from tiny devices to large server farms or CDNs

Has it, though? What we have now is an MVP, and easily 90% of the features aren’t there yet.

When WASM gets garbage collection, will it still be able to run on tiny devices? We don’t know yet.

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

#70

Post by dmitriid »

e1ven wrote: post #32

Regardless of any technical merit or reasoning, one big advantage is that Javascript/WASM is not controlled by any one large company or organization. This provides substantial differentiation from .Net/Java/Flash/etc. That said, this advantage risks diminishing if Google's influence continues to grow.

> Javascript/WASM is not controlled by any one large company or organization

It’s disproportionally affected by Google.

Post reply on HN