15 ms·
Mozilla announces WebAssembly System Interface, what JVM should have been
- olliej 7y agoIt's kind of true -- it's designed with a recognition that computers are real things, and shouldn't be abstracted out in terms of a specific programming model. The JVM approach (somewhat by design) limits the easer of interaction with other systems. The biggest drawback in WASM to me has alway been the memory model. While it is memory safe, it's currently opaque to the host environment which means that the general implementation is to over allocate address space and essentially implement pointers as integers. That results in pointers that can't be trivially shared between environments. That said, I think that if I /were/ to be making an app that had plugins, or an OS from scratch, etc I would define an interface via WASM. Screw loading unbound untrusted code into my process. My code is 100% bug free, I don't want to other people to break it. This is not remotely true :D
- saagarjha 7y agoHow do you feel about the app extension model, i.e. loading bound semi-trusted code into a sandboxed process and communicating via XPC?
- olliej 7y agoApp 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.
- saagarjha 7y ago> 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 do even if you're running arbitrary code. Sure, the first "barrier" isn't necessarily all that restrictive or thorough, but the other one should ideally stop anything horrible?
- olliej 7y agoIt'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.
- saagarjha 7y agoI guess you're assuming that the platform/runtime that's doing the isolation is close to being correct, which we both know isn't quite true ;) The only benefit I see is that you're adding an additional level of abstraction (namely, you're executing a vetted selection of native code rather than arbitrary native code), which makes reaching the point where you can actually break things harder. Was this the point you were trying to make?
- olliej 7y agoThe idea is to reduce the ability of the untrusted code to go wrong and compromise the host. Going wrong can mean “exploited by malware” through to “extension code trawls the host process address space to provide ‘features’” The latter of these two used to happen all the time with “haxies” on OS X. The run on security benefit of providing a semi-virtualised environment for third party/untrusted code is that if the VM is exploited you are able to fix and ship a fix for the VM. You can’t fix the untrusted code.
- afiori 7y agoIn the future wasm can add more memory flexibility, for now you can only use one big byte array but the standard can be extended to allow for many of them and for some dynamics or special host semantics. That was my impression in reading the standard, that a lot of restrictions are of the form "we still do not know the best way to standardize this". Like RISC-V 128 bit
- Animats 7y agoThe JVM in the browser was supposed to be safe, too.
- olliej 7y agoThe 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.
- pjmlp 7y agoActually 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.
- kevingadd 7y agoIn 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 regret letting type safety and other features slide.
- TomMarius 7y agoUsing 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?
- pjmlp 7y agoNot 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.
- neilv 7y agoNo 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 designed to scale from tiny devices to large server farms or CDNs... > ..."That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link... > ...But a write-once, run anywhere binary represents a worthwhile effort...
- olliej 7y ago1. 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" 5. Yeah, this was also weird.
- TimTheTinker 7y agoI 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.
- pjmlp 7y agoJava 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.
- chubot 7y agoThis previous thread covers differences between the JVM and WebAssembly: https://news.ycombinator.com/item?id=19502702 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 / etc. were never ported to the JVM. The browser actually has better equivalents of them.
- pjmlp 7y agoActually 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.
- viraptor 7y agoOpenOffice / staroffice were also partially Java based for a while if I remember correctly
- squarefoot 7y agoThey could use whatever JVM one has installed, but the dependency became optional and can be turned off (Tools->Options->LibreOffice->Advanced on LibreOffice). I keep it turned off as I don't have Java installed anywhere and probably I lose some features in the process, but I don't recall having any problems in normal use. I'm definitely not an advanced LibreOffice user though.
- threeseed 7y agoThat last one is really stupid. The reason they weren't ported is because they were legacy codebases with some code going back to the original versions including lots of assembler. It was always going to be a monumental task to rebuild them from scratch.
- chubot 7y ago
- tus87 7y agoIf you want to pull the chain on this diarrhea: https://github.com/stevespringett/disable-webassembly https://github.com/stevespringett/disable-webassembly
- dang 7y agoPlease don't post name-calling dismissals of other people's work to HN. This is in the guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. The article you've linked to is much better than this and deserves a better representation than that.
- ChrisSD 7y agoNote that: > To be fair, many of the threats above also apply to Javascript
- virgakwolfw 7y agoRe-read the articles about Java written twenty years ago... same promises.
- manigandham 7y agoI wonder what new standard we'll come up with 10-15 years from now that'll be titled "What WASM should have been".
- asdkhadsj 7y agoIsn't that what the goal of software should be? Solving problems with older implementations? Do people think WASM is not better than the JVM for streaming browser based usage? Did it learn nothing from the JVM? The sarcasm in these threads always confuses me.
- pjmlp 7y agoYes, because WASM is basically politics due to the refusal of other browser vendors to adopt PNaCL, and it doesn't provide any security for memory bound and null pointer exploits inside the sandbox.
- asdkhadsj 7y agoSo where were JVM targets for all my favorite languages, or any browser support for that matter? I'm not going to debate any points against the JVM, but all I know is that I can compile languages I want to all browsers today. Why can't I do that for the JVM? Something must be a massive, gory failure of the JVM and/or the companies involved with the JVM for it to be an equal to that of WASM, and yet have zero traction for modern languages and browser targets.
- pjmlp 7y agoDepends on the language I guess, I can compile Java, Kotlin, Scala, Clojure, TCL, Python, Ruby, Common Lisp and any other one able to produce LLVM bitcode on the JVM. Also 86% of the mobile OS market runs on Java. Additionally smartcards, a big portion of electricity meters, factory automation, smart copiers, M2M gateways, Bluray Players,... run on Java. Alongside JavaScript and .NET, it rules software development across the corporations of the world. Hardly a failure, only for naysayers.
- e1ven 7y agoRegardless 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.
- dmitriid 7y ago> Javascript/WASM is not controlled by any one large company or organization It’s disproportionally affected by Google.
- ashleyn 7y agoExactly, did we ever move beyond monoliths dominating a standard or did they simply evolve to calling something "open" while exerting disproportionate influence on the standards body?
- vorpalhex 7y agoGiven that Mozilla has done tons of WASM work, and that one of the earliest implementors was Rust, comparing WASM to Oracle's iron fist over the JVM doesn't seem to jive with reality...
- dmitriid 7y agoI didn’t say Mozilla, I said Google. I didn’t say iron fist, I said disproportionately affected.
- BubRoss 7y agoAnd it isn't true, because Mozilla is very involved, and every browser engine will have to get on board.
- dmitriid 7y agoFirst and foremost Chrome has to get onboard. Hardly anyone cares if Mozilla implements anything. A few people will care if Safari does. Edge is out if the picture and is being replaced by Chromium (aka Chrome). On WebAssembly specifically. Here’s WebAssembly working group: https://www.w3.org/2000/09/dbwg/details?group=101196&order=org&public=1 https://www.w3.org/2000/09/dbwg/details?group=101196&order=o... I count 18 people from Google, and only one from Mozilla. The second largest representation is from Microsoft (8 people), but their input is now Chrome/Chromium input.
- ilaksh 7y agoIs there a link to the WASI spec?
- TUSF 7y agoThis seems to be the current documentation: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-documents.md https://github.com/CraneStation/wasmtime/blob/master/docs/WA...
- deleted 7y ago[deleted]
- Thermolabile 7y agoIsn't most of the work done already with LLVM intermediate representation? Stick to POSIX (and Qt if necessary) in the code, distribute the IR with a compiler which compiles and installs it, and job done.
- 0815test 7y agoThere's no such thing as a single LLVM IR. It's actually a family of IR's where the actual representation is always dependent on target architecture.
- ragerino 7y agoKind of funny. WebAesembly is basically like a pre-installed Java Browser Plugin.
- tracker1 7y agoWithout all the bugs and security holes.
- mooman219 7y agoEverything was intended to be secure but no one writes perfectly secure code, same goes for WASM. Java exposed a lot of system access (files, devices, I/O) that you just don't have in WASM. In that aspect it's more secure, but it also does less. If you're going to include the browser APIs, you can argue they're just as insecure as Java given their less than stellar history.
- tracker1 7y agoName any technology that loads and executed remote content with a better track record than browsers and JavaScript. At least anything with even 1% the capability.
- snazzycalynx 7y agoI see nobody's mentioned that Kotlin can compile to WebAssembly (in addition to Java bytecode, native binaries and JS). Kotlin is a beautiful language and hopefully WebAssembly will help it to gain traction outside the Android world.
- afiori 7y agoWhat Kotlin is now has no bearing on what JVM was then or even what JVM is now
- StevePerkins 7y agoSpeaking 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-side solution, it taints the brand for people who lack business application experience. Java is thought of as "insecure", even though the OVERWHELMING majority of security patches are for the browser applet plugin, which hasn't been widely used in twenty years and now being retired. Instead of being "a thing that makes large-scale business server applications more performant, and more tenable for large teams to work on", it is often seen by newbies as "a failed React.js alternative" where it comes up short. Actual Java developers stopped thinking of it that way decades ago, but the history unfortunately persists.
- fulafel 7y agoJava 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
- blitmap 7y agoI wish JS made it easier to sandbox itself with existing mechanics - like simply unreferencing a system API. I am looking forward to this.
- cmiles74 7y agoThe quotes from the Web Assembly team at Mozilla and Solomon Hykes read like these people are suffering from some kind of late 1990s amnesia. Till Schneidereit is saying exactly the same thing Sun said when Java was announced. Acting like they are breaking new ground strikes me as unhelpful and it's not clear to me how it will help the cause. Maybe WebAssembly will enjoy more success than Java, I truly hope that it does. IMHO, the success of these products has very little to do with how good they might be technically. It's all about sales and marketing and, eventually, politics. Perhaps that's where the motivation to re-write recent history is coming from.
- otabdeveloper1 7y ago> It's all about sales and marketing and, eventually, politics. Not in this case. Java failed because it sucked from a technical point of view. It traded better 'OO purity' in exchange for worse security, portability and performance. The end result is that users got something that was slower and buggier for no gain.
- btlr 7y agoWhere did you get this "Java failed" idea? Java is one of the most widely used languages in the whole world...
- otabdeveloper1 7y agoJava failed as a portable language-agnostic VM for user-facing apps. You know, the use-case it was originally designed for. (I read the hype for Java 1.0, I was there.) Nobody at the time could imagine that Java would eventually become the enterprise COBOL replacement.
- cmiles74 7y agoI'm not so sure it failed. I use IntelliJ IDEA daily, people in my office use WebStorm for Javascript development. There are Swing applications out there that people use, admittedly the ones I've seen are mostly business software. And of course all Android applications are leveraging Java. It's argued that only IDEs use Java, but Java + Swing strikes me as the most popular cross-platform language and toolkit currently in use.
- openfuture 7y agoJava is a language backed by the JVM it tried to do two things: Be _the_ language (Java) Be _the_ platform (JVM) Wasm is a compilation target, it's better to compare it to the JVM than Java. The thing that has me excited is that _every_ language will be write once run everywhere not just some new and unproven language (like Java was at the time).
- newen 7y agoWhy do they call it webassembly if it doesn't even have goto.