4 ms·

Yeah, I wonder what Java got wrong. I still don't know. I'm not convinced it was inherent. Wasm is doing fine. What did Wasm get right that Java got wrong?

mike_hearn 1y ago
WASM in the browser is doing OK but that version of WASM barely exposes any APIs to the code it's running. Meanwhile JS in the browser does "fine" in the sense that the constant stream of bugs isn't a critical problem for the industry anymore, but that requires several things that no previous attempt at code sandboxing had: - Multi-billion dollar budgets, cross-subsidized by other businesses. I'd guess there are at least 1000 people working on Chrome. That scale of subsidization was always going to be tricky. Google made a lot of enemies over the years by virtue of being both very rich (so the left don't like them) and allowing unchecked left-wing political extremism amongst its employees (so the right don't like them either). This budget is really the core pillar of the web, and it looks like it's about to be kicked out from underneath Chrome by the DoJ. - Forced updates, without giving the user any control or even notification that it happened. When Google first started doing this it was radical. At the time it was standard for apps to ask permission to update, this was viewed as important by programmer culture, and there was actually strong internal resistance to this sharp change of attitude towards the user. Larry Page himself pushed it through by sheer force of executive will. - Massive number of publicly available codebases to test against. The danger with doing forced updates is that you ship a regression, stuff breaks, users get mad and they disable the updater leaving you in a worse place than where you started. Chrome doesn't just have 1,000+ very expensive and talented people working on it, they have truly enormous CI farms where they can do things like verify there are no rendering changes against real world apps. - Multi-process sandboxing. In the Java era a lot of users ran on Windows 9x which had no security system at all. Kernel sandboxing only really became plausible in the Chrome era, and Chrome relies on it heavily: if you look at the sheer number of security bugs in Blink, or even just V8, then it would be very risky to use it without the extra kernel sandboxes. - A very incrementally patched together platform that wasn't exposed to any serious competition, so the higher level APIs could be extended very slowly and at a pace that allowed different threats to be handled. There's nothing inherent about this; the web could have faced much stronger competition than it did and on mobile that happened. But by the time the web was taking off the sort of people who built operating systems had been doing it the same way for decades, and were unable to really change their perspective enough to build a compelling web competitor. Even on mobile, designers were only comfortable with a 1980s era metaphor of a main street supermarket. Getting more technical, the Java sandbox had some weak "pressure points" that a lot of exploits zoomed in on. For instance if you could find a way to write to just one private field you could disable the entire sandbox, and there turned out to be a lot of ways to do that. IMHO if the need had been there the architecture could have been improved, defense in depth could have been implemented, etc, but like all the other competitors to the web they hitched their wagon to the browser via plugins. Eventually the browser guys saw their opportunity and used security as a justification to kill off every non-HTML platform, which they did.

mike_hearn 1y ago

WASM in the browser is doing OK but that version of WASM barely exposes any APIs to the code it's running. Meanwhile JS in the browser does "fine" in the sense that the constant stream of bugs isn't a critical problem for the industry anymore, but that requires several things that no previous attempt at code sandboxing had: - Multi-billion dollar budgets, cross-subsidized by other businesses. I'd guess there are at least 1000 people working on Chrome. That scale of subsidization was always going to be tricky. Google made a lot of enemies over the years by virtue of being both very rich (so the left don't like them) and allowing unchecked left-wing political extremism amongst its employees (so the right don't like them either). This budget is really the core pillar of the web, and it looks like it's about to be kicked out from underneath Chrome by the DoJ. - Forced updates, without giving the user any control or even notification that it happened. When Google first started doing this it was radical. At the time it was standard for apps to ask permission to update, this was viewed as important by programmer culture, and there was actually strong internal resistance to this sharp change of attitude towards the user. Larry Page himself pushed it through by sheer force of executive will. - Massive number of publicly available codebases to test against. The danger with doing forced updates is that you ship a regression, stuff breaks, users get mad and they disable the updater leaving you in a worse place than where you started. Chrome doesn't just have 1,000+ very expensive and talented people working on it, they have truly enormous CI farms where they can do things like verify there are no rendering changes against real world apps. - Multi-process sandboxing. In the Java era a lot of users ran on Windows 9x which had no security system at all. Kernel sandboxing only really became plausible in the Chrome era, and Chrome relies on it heavily: if you look at the sheer number of security bugs in Blink, or even just V8, then it would be very risky to use it without the extra kernel sandboxes. - A very incrementally patched together platform that wasn't exposed to any serious competition, so the higher level APIs could be extended very slowly and at a pace that allowed different threats to be handled. There's nothing inherent about this; the web could have faced much stronger competition than it did and on mobile that happened. But by the time the web was taking off the sort of people who built operating systems had been doing it the same way for decades, and were unable to really change their perspective enough to build a compelling web competitor. Even on mobile, designers were only comfortable with a 1980s era metaphor of a main street supermarket. Getting more technical, the Java sandbox had some weak "pressure points" that a lot of exploits zoomed in on. For instance if you could find a way to write to just one private field you could disable the entire sandbox, and there turned out to be a lot of ways to do that. IMHO if the need had been there the architecture could have been improved, defense in depth could have been implemented, etc, but like all the other competitors to the web they hitched their wagon to the browser via plugins. Eventually the browser guys saw their opportunity and used security as a justification to kill off every non-HTML platform, which they did.