Goodbye PNaCl, Hello WebAssembly
blog.chromium.org
blog.chromium.org
Some examples of specialized apps I use all the time that would require a native app otherwise:
- Signal Desktop
- TeamViewer
- Postman
- SSH client
- Cleanflight drone configuration tool
It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure.
Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions.
It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay.
It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller.
Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?
> We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions.
Where do you see that chrome apps are being discontinued? Otherwise this is FUD.
The only upside I can see is that CrOS is soon going to support running Android Apps which may save it, but even then... Maybe they'll figure out a way to run Electron/NWJS apps on ChromeOS?
Postman aside, I don't understand why anyone would want any of the apps you listed to be installed as a Chrome App. Why would someone want an SSH or TeamViewer client to be tied to their browser? You're installing an application either way; Chrome internalizing the process as an attempt to offer convenience is a strange idea. Chrome is a browser, not an operating system - let the OS do what it does best. Chrome Apps were an unnecessary and proprietary mess - a failed experiment I am happy to see dismissed.
- unblockable advertising
- stronger DRM
- Bitcoin mining that regular user can't detect
- etc..
It will be good and bad, but, more bad than good.
We could choose not to run .exe .bat and the rest
So far, webassbly doesn't look optional.
Ad blockers primarily look at domains, so blocking will continue to be possible at the request level. They aren't interpreting or parsing JS to begin with.
> - stronger DRM
If sites were going to ship Web Assembly-based DRM, they would already be shipping Web Assembly along with the Emterpreter. Remember that wasm has a polyfill already. I haven't seen that happening, so I see no reason to believe it'll happen in the future.
> - Bitcoin mining that regular user can't detect
A regular user certainly would notice the 100% CPU consumption. And anyway, bitcoin mining in a WebGL shader would be more profitable than anything wasm-based.
Moreover, though, surreptitious bitcoin mining on consumer PCs would be ludicrously unprofitable no matter what. Here a Stack Overflow answer from last year that calculates how much a site with 2M daily visitors would make if they could all somehow run the fastest C implementation [1]. It was less than 50 cents a day back then, and in the meantime the hash rate has grown by nearly an order of magnitude [2]. Good luck.
[1]: https://bitcoin.stackexchange.com/a/42413
[2]: https://blockchain.info/charts/hash-rate?timespan=2years
One cool idea that is also gaining traction is in-browser proof of work to prevent DDOS attacks. Basically you have to perform a lengthy computation to get past the (fast, ultra-high bandwidth) firewall. Doesn't slow down the individual user much, but makes an attack much more difficult. I could imagine people using malicious JS to get these proof-of-work tokens.
But yeah, computing power in the cloud has become fairly cheap, it's really hard to see how criminals could benefit from secretly serving WebAssembly to people.
I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of concern to your company maybe an automated CPU usage monitor could alert the team to anomalies.
[1] I was running a test today when the program being tested ran into a very tight loop and the fan really kicked in. I was curious if it would finish and let it run for several minutes until all went quiet and the screen went dark. It had shutdown to prevent heat damage.
A laptop overheating from few minutes of 100% CPU is not normal.
First, I don't see why you think WASM-based ads will be any less blockable than JS already is.
Stronger DRM on the web [is already a thing][1], but that has nothing to do with WASM.
Bitcoin mining on the web is already possible with JS and so far that hasn't been an issue. If it does start becoming a widespread problem though, browsers will start taking steps to combat it, like they [already have][2] for pages that needlessly consume CPU in the background.
[1]: https://www.w3.org/TR/encrypted-media/
[2]: https://developers.google.com/web/updates/2017/03/background...
That's actually a great idea for funding content creation online. If a site is open source, then it would even be possible to prove that only a reasonable share of the client's resources are being utilized. I'd take that funding model over the advertising-driven model that exists now.
I don't see how this necessarily follows from WASM.
I just cannot see this not happening.
The reason people don't do this, is because ad companies want control. They want to know exactly how often the ads are served and they don't trust you to serve their ad all the time and to all customers. Also they want to rotate it quickly. Finally, they want to track people. So the solution is to use remote javascript. 99% of ads work this way, even mayor news sites don't sell their own ads anymore.
In this scheme, you'd probably still have ads served from a third party server. And even if they obfuscated the domain name, you could still probably identify their blob and block it.
So I'm not to worried about unblockable ads. But you're right, they will try, and I am worried about sites becoming unusable because they will emulate browsers using canvas, poorly.
As for the site owners - unless it's someone large enough to care, I think the usual choice between "letting a few disabled persons access the site" and "getting a few more bucks from advertising" would be quite obvious. If that question would even arise.
It makes very little sense to mine on anything other than ASICs.
CPU mining hasn't been viable since 2011 when bitcoin difficulty was below 1,000,000, and today it's near 600,000,000,000.
What do you mean?
Google could have allowed Chrome to be used as a cross-platform GUI library (THE cross platform GUI library), but left it to Electron (lagging behind and requiring distribution); think XUL runner. I don't see the sense in that. I'd absolutely love a modern XUL runner.
Electron is really just Chrome with a separate JS engine that can run native code if the developer chooses to do so.
Personally I'd argue that the "nativeness" of an application depends on how much the developer actually uses that ability to run native code. If you just throw a bunch of standard webapp CSS, JS and HTML in a folder and wrap Chrome around it, it's no more "native" than any other webapp. If on the other hand you have a whole bunch of native code doing, for example, media editing and the HTML and such is just the frontend UI, I'd say sure, that's a native app.
Oh, the tragedy /s
eg: I'd like to build an expense tracker with html/css/js/sqlite but I want it to be offline and the user can choose to save their db file in their dropbox/gdrive folder.
It would be more accurate to say it was the best thing to happen to your use of Linux in a long time, and it looks like even that is only because you're trying to use a bunch of closed source, non-cross-platform stuff.
I also disagree that it makes users less secure. The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app". There's no way would I trust a web based SSH client, for example.
And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM.
The web based SSH client is published by Google themselves and they use it internally.
> The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app".
The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.
---
Off topic remark about Linux distro security: I really like Arch, but security isn't their strongest suit. For example, they still haven't enabled full-system ASLR, citing unfounded performance concerns, when other distributions did so years ago. Even Windows with all their third party apps has a higher percentage of ASLR binaries than the average Arch system.
They also have no central build system and instead rely on volunteers who build the packages on their personal systems and sign them using their personal GPG keys.
I really want ASLR in Arch so I'll keep complaining about it publicly until it finally happens :-)
I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Further, since Chrome is such a huge attack surface, I would expect it to be less secure than a smaller, more specific application.
On that note, I can go look at my Linux distro's security and bug tracking systems and see all of the known security issues and bugs affecting almost all of the software on my system. Does anything like that even exist for Chrome Apps?
> If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.
Isn't that the case whether it's a Chrome App or not? Chrome has a huge attack surface, so it seems there's an even bigger chance of hitting a bug or being affected by an exploit.
The bigger problem seems to be that you're running apps that you don't trust, while I can trust my Linux distro to have safe software in their repositories. Barring bugs, I generally don't have to worry about installing malicious applications.
I'm not sure Google does any kind of vetting for Chrome Apps, but I'm not sure I'd trust them even if they did. They are the largest ad tracking company in the world after all.
> I have a hard time believing that. With a ton of stuff
> all running inside of Chrome, it's much easier for them
> to access each other's data than if they were standalone
> apps.
If you're using X11, every command with access to the display server (which is usually everything you run) can read all keyboard and pointer input and screen output and inject arbitrary input.
The only reason that's even a concern is because you can't trust Chrome Apps to not be malware.
On the other hand, when I "apt-get install <some app>" I know it's not listening to all X keystrokes unless that's a legitimate part of its functionality, because I trust the Debian team to only add trustworthy software to their repos.
Chrome apps are subject to sandboxing, and regular native desktop apps (besides apps installed through OS X's app store) generally don't have any sandboxing enforced on them at all.
Taking Soundcloud as an example, Clementine (and probably most media players) can stream it just fine. Having a Chrome App is nice, but it isn't providing anything that isn't already available. I'd even say the Chrome App is a step backwards, because with Clementine I don't need a separate app for every music service.
With a Chrome App, it sits in a (really strong) sandbox and would need to escape the sandbox first.
With a native app, it's game over.
Chrome Apps were great because they worked on all (desktop) platforms.
Is that true? Executables and shared object files are supposed to share (code) memory.
So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?
Different version - different DLLs
I will disagree, you can install most of these from the official repository of your distribution, without the use of electron. They are also very secure if you run them as an unprivileged user.
1.) Port it to Electron and keep nearly the same code base
2.) Rewrite the whole thing as a native app in such a language as C++ without the use of Electron
You can't possibly tell me that most developers won't choose #1 instead of #2 in a heartbeat (the switching costs are orders of magnitude more for #2, for one thing). Which is not a Good Thing.
And it's also very obvious that #2 isn't nearly as secure as #1, which runs in a sandbox and so does not have direct unchecked access to users' files like #2 does.
Seriously? There are like 12389127381789 how to guides about how to do it, and it is literally like 3 steps.
Do you really think the person who has problems starting putty is going to thrive in a CLI environment?
10/10 developing for the web on windows is finally tolerable
Cygwin has ssh as an optional install.
Msys2 too.
Of course, you need to have windows first. MS give away 30-day win 10 trial VM images with git bash installed, or at least they did.
The idea that software is secure if it only runs on your own user account is stupid IMO. I'd rather that software had access to everything on my computer EXCEPT my personal files.
https://chrome.google.com/webstore/detail/secure-shell/pnhec...
It's useful outside of Chrome OS if you have a security perimeter based on TLS with ACLs and auditing already in place and you want to use it for SSH as well:
https://github.com/zyclonite/nassh-relay
https://chromium.googlesource.com/chromiumos/platform/assets...
Google uses a similar setup internally.
I know, I know. It's crazy talk....
So it was just kind of a snarky joke because the parent said that to be a "Linux Desktop" you had to be able to get ssh running (presumably they meant openssh). And while that's not GNU, GNU is what the vast majority of "Linux Desktops" will use to get you there -- so the implication really was that "Linux Desktop" == "GNU/Linux Desktop".
I thought it was funny, but probably I was being too obscure. Also, I should know better than to dive into politics for no good reason.
Say what? Do you know what GNU means or what it includes? Here's a link so you can learn more:
https://groups.google.com/a/chromium.org/d/msg/chromium-hter...
But "if everything aligns" == "only if you're inside Google".
Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.
Google also has goobuntu, which I'm being is what's provided to engineers.
I tried it for a while, but I'm too used to the Mac to have made the switch more easily, so I moved back. But I know quite a few folks who use and love them. Opinions, as I'm sure you can guess, vary widely. It was surprisingly not-bad, even for a diehard mac user, and that was on a model from two years ago.
https://mikecborg.wordpress.com/2017/03/22/securing-clouds/ (search for all occurrences of 'chromebook')
I still listed it for completeness, I do use it, after all.
Any operation, like 64-bit adds/muls/divs/etc would have to call emulation functions. It'll be orders of magnitude slower.
PNaCl vs WebAssembly was all about letting everybody run sandboxed native code in the browser without any extensions or prompts.
Native Client (the portable version known as PNaCl) was an open source project by google to achieve native performance with sandbox security.
Mozilla wanted a more open web which led to Web Assembly.
"As I mentioned elsewhere, there haven't been any full time mozilla devs on PDF.js for quite awhile. I'm not sure I actually see the whole maintenance cost savings argument since PDF.js has practically cost Mozllia nothing the last few years. A lot of bug fixes have come from unpaid contributors in that time. Initially, PDFium was pitched as a freebie if we added support for chromium's flash and then we'd also get improved PDF printing and form support. However, the amount of effort that has gone into supporting PDFium is already far beyond what it would have taken to improve PDF.js form support and help improve Firefox's printing (which would have benefited the web in general). Though, this is my very biased opinion as I was tech lead of PDF.js."[1]
And this has been borne out--Project Mortar was announced about 9 months ago, and if you look at the relevant bugs in bugzilla, they are still pretty far away from getting it into production. They could have used a fraction of those resources to get pdf.js at parity with pdfium.
PDF.js is at a very comfortable nexus of compatibility and efficiency, and I kind of wish I could use it for non-web-PDFs as well (but not so much that I want to put it in an Electron wrapper).
I'm not personally familiar with those internals, but from my past life in the print industry it took decades for print controllers to reliably handle native PDFs. And it's still not a sure thing[0].
And it's not a stationary spec, it's in Adobe's best interest to keep throwing in new features so they can license new versions of their software. It's literally a rehash of the old school office suite document formats.
Google is willing to cover those development costs because they need it for Android, ChromeOS, and Google Docs. So let them pay for it. This is doubly true if (as I suspect) this becomes the de-facto FOSS PDF implementation.
0: https://arstechnica.com/information-technology/2017/05/micro...
Mozilla put together a small team and did asm.js to show that you could port C/C++ apps to the Web and get good performance while reusing the JS engine and all the existing Web platform APIs.
Now we have WebAssembly, which uses existing Web platform APIs and which browser vendors are implementing by reusing the guts of their JS engines. It's obvious who won.
In a way it doesn't matter "who won" because as you say Web developers are the ultimate winners. But it does underscore how much the Web continues to owe to Mozilla.
(It's also an illustration of how powerful companies can commit massive blunders and get away scot-free in the marketplace and in PR.)
That's a strategic victory for Google.
I am referring to the initial offering of Native Client for inclusion into FireFox.
Since this did not happen, Native client did not see the uptake it needed— and the team was destaffed.
Since it was a working platform that actually existed and let you use a modified version of LLVM, it was quite usable.
We could of have powerful native sandboxed apps quite a long time ago if FireFox became PNaCl compatible.
Instead, Mozilla envisioned that the JIT could eventually bridge the native performance gap.
Mozilla defended this ideas such as ASM and emscripten. And now Mozilla is coming close to a more open and performant web.
Should you even be slightly successful in the use of an API, you always have to worry about deprecation when someone is no longer interested in doing the maintenance any more.
I am sure there were more than a few game developers that are are livid today about this announcement.
These things will go in cycles and I expect there will be an native-application cycle coming soon from browser-api-fatigue.
A good rule of thumb seems to be to use what everyone else uses, and make sure you're always ready to ship another version. People expecting compiled apps to survive unchanged for years are out of luck.
https://en.wikipedia.org/wiki/Sodium_chloride#Miscellaneous_...
Of course, it's understandable for those who are hit by a deprecation to be annoyed, but overall I think the tradeoff is worth it. It's definitely better than have unchanging APIs and having browsers becoming less relevant over time.
I think the Web is moving in this direction, though I don't know how well.
0: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
In the end, this all is just reinventing the JVM, in slower, but more secure.
(However, I don't agree. I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.)
Yeah, yay for progress and horrible Electron apps..
I much prefer the latter (HTML5 + CSS3 + JS + WebAsm).
What's not to like?
Can't we just make DOM bindings for the JVM and reuse the huge existing library base?
Almost nobody is asking for this, compared to the huge number of people asking to compile C++ codebases.
That'd make it even possible to reuse old applets with just a tiny shim around them.
And it'd keep compatibility with a huge environment of libraries and languages.
Because Java bytecode is not a good target for many languages, such as C and C++, for one. It lacks unsigned and value types.
> just replace the APIs over which it interacts withthe system (as Android has done)?
That still leaves a whole bunch of APIs that are duplicated.
> That'd make it even possible to reuse old applets with just a tiny shim around them.
The number of people who want to do that is far, far less than the number of people who want to compile existing C++ codebases.
> And it'd keep compatibility with a huge environment of libraries and languages.
While sacrificing compatibility with the even huger existing JS environment.
Do you remember the part where everyone started using JavaScript instead because of all the deficiencies of Java Applets? (Slow to load, resource intensive, no interaction with the surrounding page)
More secure?
I'm sooooo glad I'm not you. I've literally halted all personal projects using JS until they get modules implemented natively.
Or, alternatively, the 20% for all of them combined don't prove your point that "people are using ancient versions", because, as you point out yourself, "most were on IE 11".
FWIW IE 11 is around 3% globally, all other IE is around 0.5%, combined: http://caniuse.com/usage-table
Out of all browsers, including on mobile devices -- which skews the results pretty significantly.
If you only consider desktop browsers, MSIE comes out between 9-10%, including about 7% on MSIE11. That's not counting Edge, which is another 3% or so.
Chrome Apps (and extensions) using PNaCl will continue to work.
Disclaimer: My opinion, not that of my employer.
Sure, it is deprecated and will be deactivated eventually (but maybe not soon; consider WebSQL). Google's got every incentive to make sure that WebAssembly (plus the APIs exposed in ChromeOS) provides a complete replacement for PNaCl and apps have had time to transition before doing that.
https://stackoverflow.com/questions/42288596/websql-has-incr...
(I'm one of the current maintainers and we're already all over this transition)
https://blog.google/products/chromebooks/the-google-play-sto...
One caveat however. The meta key is easier to map in the chrome app - for those using emacs for instance. 'External keyboard pro' may helps on android, but the setup is more complex.
Hopefully you'll just use whatever language your org/team/etc. uses, and have it compiled to JS or WebAssembly as is most appropriate for said language.
To answer your other question, I most certainly hope we won't see "more Web stuff" built with C++. C++ is a terrible language for that. It's a very good language to do stuff that needs predictable high performance such as games. And games is a good market for C++ in the browser through WebAssembly. But other than that I hope other, more high level languages will pick up.
I guess it will be Rust or Go.
Rust because of Cargo (for npm users a big +) and Mozilla (good marketing of Rust).
Go because of Google (also a Web company with good marketing) and because I read some Node.js developers already switched to Go before WASM.
I'm not a web developer but this has definitely peaked my interest to the point I've been dabbling with WebAssembly. It's really easy to get going so I could see a lot of people with other than WebDev backgrounds getting into application development in the browser.
With that said I'm just parroting some other comments I've seen on this topic in other contexts, so I'm asking the question genuinely.
Why can't the Go implementation can have its own GC, the same as the Go implementation for, say, x86 does?
If a popular web library uses it for something real, they will probably provide a JavaScript API to call into it.
For resources, MDN has a great introduction. Pretty up-to-date too. [1].
[1] https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wa...
You can program in wasm's text format (the actual assembly language) directly, if you want, and you can program in anything that compiles to wasm. C/C++ have the most developed toolchains for higher (than wasm itself) level languages, for now, but that should open up.
Not perfect but the direction looks good so far.
The way Google has abrubtly sent PNaCL to the knackery, rather than a gradual transition is just ugly. By removing the PNaCL functionality completely from builds they have broken faith with the development community. They didn't even commit to allowing PNaCL to run in deprecated mode via a feature flag or something.
In hindsight, I can see that Google had shifted their effort away from PNaCL several years ago. But to kill it they way they have it just brutal.
I would agree that for general web development this seems a way out of the javascript purgatory. But there is a long way to go before it can match what PNaCL did. And I find it bizarre that they created a 32 bit implementation; I know they had reasons but they seem shortsighted.
Not sure what you mean by "code signing" in this context.
The API attack surface is a non-issue; it's already accessible by any page that serves a PNaCl object.
There's a small performance deficit but it's getting smaller. AOT compilation and caching of compilation results is possible; asm.js did it.
I already mentioned shared-memory parallelism (it's just about done); did you read what I wrote?
Standard cross-browser Web APIs give you access to those devices already.
Same-origin is a strait-jacket --- a necessary one. "Break the Web's security model" isn't a desirable feature.
"Elegance" is just a point of view. From another point of view, "duplicate everything in the Web platform" is not elegant.
As for maturity and bugs --- having multiple interoperating implementations and real specifications is a good way to drive competition on quality ... and to distinguish "this is a bug, fix it" from "hello de-facto standard!"
Non-portable NaCl did have the advantage that it could specifically target and optimize for one CPU architecture, and it had the beginnings of 64-bit address space support. These were nice, but not widely used. And we both could conceivably make it into WASM in the future.
Q. Why not NaCl or PNaCl instead? Are you just being
stubborn about JavaScript?
A. The principal benefit of asm.js over whole new
technologies like NaCl and PNaCl is that it works today
It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead.
[1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-dec...
Wasm is only superficially non-JS. AFAIK every browser vendor is implementing Wasm by reusing the optimizing compilers in their JS engines.
I think we might see some extensions to WebIDL and Web platform APIs to improve Wasm app performance. We're sort of already seeing that with [AllowShared]. But there's no need to develop entirely new platform APIs, because fundamentally there's no reason calls from Wasm through JS API glue to the browser should be slow; JS API glue can be inlined into the Wasm code, for example.
https://blog.google/products/chromebooks/the-google-play-sto...
Well, for the Chrome Apps use case for Chrome OS, chrome.sockets.udp seems to be available, and wasm can call out to JS APIs. What other browser vendors do isn't really relevant for Chrome Apps.
ZeroVM was a desktop/server sandboxing environment that just didn't get any attention and mindshare. Shame!
I want a ZeroVM-like system that makes all of the Debian user-space available on any other OS, each app in a little sandbox... It ought just be another compiler target and automated.
Oh to what could have been! :(
You should check linuxkit https://github.com/linuxkit/linuxkit
Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf.
Want to authenticate your users, but don't want to deal with all the different permiations on hardare tokens, ssh keys, etc? Just let them upload a wasm function.
It was before my time, but I don't imagine the open source community was ever going to really embace it.
The basic tech behind it is LLVM IR, which is the same tech Apple Store now uses to target the Watch and future devices.
But this is just my impression to listening to some talks by the developers of webasm.
While I am happy that it looks like this will (more or less) be standardized across browsers, I still hope for the day where running a more minimal browser (text, image, maybe videos) will become viable. Of course, I'm pessimistic on this, seeing as so many sites are probably not functional without javascript and other related technologies, but maybe some web developers care about choice. Who knows.
A good reminder not to invest in any Google specific technology.
> We recognize that technology migrations can be challenging.
You recognize you wasted a lot of people's time.
I really think this is a good question, despite the form of your post (hence the downvotes).
To anyone who decided "lets use NaCl or PNaCl", I have a genuine question: Are you honestly surprised to see this tech too go obsoleted?
> We recognize that technology migrations can be challenging. ... You recognize you wasted a lot of people's time.
They are taking this from Apple's book: Don't leave any compatible stuff behind. Leave the maintenance-cost to others.
I'm asking because every time something new is introduced, it feels like it ends up being used to abuse users (Javascript, XSS, Cookies, HTML5 Video).
By the way, why do you think HTML5 is a problem?
Worst, some sites these days will waiting until you've scrolled down a bit before they start playing a video, leaving the user to locate it and stop it.
As for Flash, it was indeed bad, but at least I had the option of not installing it.
Huh? This has nothing to do with browsers; it's purely a site author decision. Autoplaying videos is a site author decision -- and one that they already frequently made before HTML5 video was widely available.
Firefox and Chrome let you mute tabs. Firefox Nightly also blocks playback in any tab you haven't actually looked at yet. Other than that there's not much they can do.
eh. if this is your litmus for abuse you may want to reconsider having an email account or a doorbell.
I'm pretty sure autoplay is now only allowed on videos without sound — as a replacement for the massive waste of bandwidth that is animated GIFs.
Because things are built to standards now, we can build those tools to manipulate them the way YOU want (which includes making them not auto-play) so the move from Flash and other 'black box' plugins to HTML video has been a HUGE win for usability!
The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script.
... which will lead to more ads being served, evening out any advantage.
The great thing about shitty websites is that I can opt to not visit them.
For a concrete example, at least two JavaScript engines (those of Chrome and Firefox) need to emit almost no range checks on regular memory accesses with WebAssembly on 64-bit computers. (For those interested in going past ELI5, they do this by allocating a large chunk of virtual address space, such that any out of range pointers will land somewhere in that space (WebAssembly currently only has 32-bit pointers). Some of the space is filled with memory, and the rest causes a controlled signal/exception so the engine can safely terminate the instance.)
target for static languages that do manual
memory management
While the new Google Earth with PNaCl was just introduced, a large engineering cost for a semester-lived technology! Too bad
I think the likely explanation is that Google is a large company with numerous departments and those departments don't always pull in the same direction. I imagine some people within Google weren't happy with the Google Earth announcement.
Wasm applications can have type confusion bugs, use-after-free bugs, and array overflow bugs, etc, but this is inevitable for any realistic C/C++ compilation target.