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

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

Post reply on HN
Print view View original

161–170 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#161

Post by pcwalton »

quickben wrote: post #126
eeZi wrote: post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. 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 an…

Add to that list: - 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.

> - unblockable advertising

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

Re: Goodbye PNaCl, Hello WebAssembly

#162

Post by Caspy7 »

thristian wrote: post #153
indolering wrote: post #141

Earlier quoted context omitted.

Yeah, AFAIK PDFium doesn't use PNaCI and Flash will only be around as long as absolutely necessary. The only reason they aren't using PDF.js is because the PDf spec is ~12K pages long and they don't want to throw engineer resources at it anymore.

I'm sad to see PDF.js go. The PDF spec is ~12K pages long, and most of those pages describe things I don't want my PDF viewer to support, like embedded Flash, in much the same way I don't want my browser to support Flash. 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).

PDF.js isn't "going" per se, but its lack of inclusion and development may certainly take wind out of its sails. It should still be possible as a PDF viewer in the browser (as an addon). And I think you can already use it (inside Firefox) to view non-web-PDFs.

Re: Goodbye PNaCl, Hello WebAssembly

#163

Post by sowbug »

winstonewert wrote: post #150
solomatov wrote: post #147

Earlier quoted context omitted.

>- Bitcoin mining that regular user can't detect It makes very little sense to mine on anything other than ASICs.

Is that still true if someone else foots the power bill?

Put it this way: once you factored in the price of the bus fare to get to the public library to borrow a terminal to check your giant botnet's bitcoin earnings, your criminal enterprise would be operating at a loss.

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.

Re: Goodbye PNaCl, Hello WebAssembly

#164

Post by bastawhiz »

artursapek wrote: post #157
mintplant wrote: post #143

Earlier quoted context omitted.

> - unblockable advertising I don't see how this necessarily follows from WASM.

Don't most ad blockers just rely on media queries on the DOM? I imagine there's a lot of ways to circumvent those techniques when you are rendering raw pixels with wasm.

Those pixels still have to go somewhere in the DOM, and clicks on those pixels still need to be handled. Plus, there's nothing wasm can render that you can't render with uglified JS already.

Re: Goodbye PNaCl, Hello WebAssembly

#165

Post by foota »

ehsankia wrote: post #120
itp wrote: post #42

Earlier quoted context omitted.

One way it affects it is to reduce the overall market for Chrome apps, reducing the incentive to make an app in the first place.

Exactly. I doubt most of the ChromeApps that exist today were made for ChromeOS. They were made because it was an easy and straight forward way of making a webapp on the desktop. Now, as OP mentions, everyone is moving to Electron and NWJS, neither of which works directly on ChromeOS. 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…

Maybe Google is looking to run Android apps in chrome?

Re: Goodbye PNaCl, Hello WebAssembly

#166

Post by ehnto »

pcwalton wrote: post #161
quickben wrote: post #126

Earlier quoted context omitted.

Add to that list: - 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.

> - unblockable advertising 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…

I doubt a regular user would notice 100% CPU usage and even less certain that they would know what to do about it or what was causing it. Most OSes operate chrome just fine when another process is asking for 100% as well.

Re: Goodbye PNaCl, Hello WebAssembly

#167

Post by brandon »

_wmd wrote: post #25

The most material result of this is that Chromebooks won't have a working SSH client starting sometime next year, because WebAssembly can't do real sockets without an external proxy.

We're going to make sure that the Secure Shell app for Chrome, in one form or another, continues to be usable on Chrome OS.

(I'm one of the current maintainers and we're already all over this transition)

Re: Goodbye PNaCl, Hello WebAssembly

#168

Post by snakeanus »

eeZi wrote: post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. 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 an…

> 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.

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.

Re: Goodbye PNaCl, Hello WebAssembly

#169

Post by nol13 »

AsyncAwait wrote: post #28
Crontab wrote: post #24

Is WebAssembley going to turn into yet another web technology that can be used by websites in order to track us or to annoy us with advertising? 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).

Every piece of technology can be abused, that doesn't mean the technology itself is bad and shouldn't be adopted.

Will WASM trackers/ads be harder to block than ECMA Script ones?

Re: Goodbye PNaCl, Hello WebAssembly

#170

Post by bas »

ehnto wrote: post #166
pcwalton wrote: post #161

Earlier quoted context omitted.

> - unblockable advertising 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…

I doubt a regular user would notice 100% CPU usage and even less certain that they would know what to do about it or what was causing it. Most OSes operate chrome just fine when another process is asking for 100% as well.

Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.
Post reply on HN