Goodbye PNaCl, Hello WebAssembly • Hacker News Board

Re: Goodbye PNaCl, Hello WebAssembly

#171

Post by mrout » Wed, May 31, 2017, 2:59 AM UTC

snakeanus wrote: post #168

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.

If you run them as a different user from yourself, maybe, but who does that?

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.

Re: Goodbye PNaCl, Hello WebAssembly

#172

Post by Hydraulix989 » Wed, May 31, 2017, 3:01 AM UTC

snakeanus wrote: post #168

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.

Suppose your JS Chrome App is getting the plug yanked on it, what are your alternatives?

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.

Re: Goodbye PNaCl, Hello WebAssembly

#173

Post by 3131s » Wed, May 31, 2017, 3:02 AM UTC

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.

> Bitcoin mining that regular user can't detect

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.

Re: Goodbye PNaCl, Hello WebAssembly

#174

Post by Veratyr » Wed, May 31, 2017, 3:03 AM UTC

favadi wrote: post #127

johns wrote: post #111

Earlier quoted context omitted.

It's based on Electron

Don't be surprise, people consider electron "native" today.

Some people and those people are arguably wrong.

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.

Re: Goodbye PNaCl, Hello WebAssembly

#175

Post by captainmuon » Wed, May 31, 2017, 3:05 AM UTC

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…

You are right, but replace Bitcoin with the latest Fadcoin and it might get lucrative again.

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.

Re: Goodbye PNaCl, Hello WebAssembly

#176

Post by captainmuon » Wed, May 31, 2017, 3:11 AM UTC

drdaeman wrote: post #158

mintplant wrote: post #143

Earlier quoted context omitted.

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

WASM is aiming to be fast enough to actually be capable of running a rendering engine. No more DOM for adblockers to look at, the pages may finally become canvases. I just cannot see this not happening.

Right, but you can already do that. Serve the whole page as a SVG, or JPEG, or PDF. You can already embed ads inline. Or just plain serve them from your own server, calling them article.jpg instead of http:://ads.adcompany.com/advertisement.jpg .

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.

Re: Goodbye PNaCl, Hello WebAssembly

#177

Post by roca » Wed, May 31, 2017, 3:19 AM UTC

jhpriestley wrote: post #105

From the asm.js FAQ: 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 asm.js however wasn't good enough to actually be useful, as evidenced by the lack of adoption and the move to wasm. So now we have wasm which is not backward compatible. We would be further along now if Mozilla/Ei…

PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs

Re: Goodbye PNaCl, Hello WebAssembly

#178

Post by artursapek » Wed, May 31, 2017, 3:22 AM UTC

bastawhiz wrote: post #164

artursapek wrote: post #157

Earlier quoted context omitted.

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.

So I guess it's equivalent to rendering ads on a Canvas element?

Re: Goodbye PNaCl, Hello WebAssembly

#179

Post by indolering » Wed, May 31, 2017, 3:22 AM UTC

Caspy7 wrote: post #162

thristian wrote: post #153

Earlier quoted context omitted.

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.

I totally agree that we shouldn't be throwing random PDFs at that pile of C++ code, but I'm not sure there is much of an alternative.

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

Re: Goodbye PNaCl, Hello WebAssembly

#180

Post by roca » Wed, May 31, 2017, 3:27 AM UTC

nojvek wrote: post #138

duskwuff wrote: post #108

Earlier quoted context omitted.

> every web browser maker seems to think that autoplay videos are great 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.

Not really. Browsers just need to default stop autoplaying videos out of the screen view. Or better yet what they did to popup blockers. Give one chance to behave well, if the site doesn't then it gets blocked and the user has a notification that autoplay was disabled.

Blocking scripted calls to "element.play()" really sucks for Web developers building games and other kinds of apps. Safari on iOS did this and it was horrible for developers.

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.