4 ms·

I am concerned that web assembly will mean an end to ad blocking and to a proliferation of malware, as the end user is basically going to be handed an opaque bi

I am concerned that web assembly will mean an end to ad blocking and to a proliferation of malware, as the end user is basically going to be handed an opaque binary blob they can't do much with but execute.

dotancohen 4y ago
The only way to fight that is to, as a community, refuse to run _all_ wasm that is found to serve ads, or infringe on privacy, or exhibit other malware traits. The only way to do that would be to use browser extensions that disable and report, to disable for other users automatically. But how would we identify the executables? hash? That can be changed trivially. I really fear that wasm brings us 180 degrees from "don't execute anything from the internet" to "all WWW usage is running other peoples' executables".
- deleted 4y ago
  [deleted]
- jschrf 4y ago
  That's already the case! Also, having other people tricked into running other-other people's code with the others' credentials against _your_ code. I think WASM will actually be more secure than the exsting www model. See: POST for an example :) I agree though... there will be bad actors and an ever evolving cat and mouse game
the_duke 4y ago
Wasm in the browser can only communicate by going through browser APIs. Most ad / analytics / tracker blocking works by intercepting HTTP requests, so they will work just as well for Wasm code. WASM that uses the regular DOM for rendering also doesn't really change blocking capabilities. The only real issue is visual/selector based blocking when frameworks do their own rendering via canvas, webgl or webgpu. Flutter does this. But doing your own rendering comes with a lot of overhead, both in download sizes, startup time and performance. Applications might do that (with lot's of caveats), but most websites never will. So I'm not that concerned. Wasm is certainly much lower level than JS, but also much higher level than Assembly. It's far from an opaque binary blob. All the minified and partially even obfuscated JS is not that much better.
- chii 4y ago
  > but most websites never will only because it's harder to do that right now than just describing a document via html. But there will come a time when it's trivially easy to write a full app in the browser via wasm, and the outcome will be that the user can either accept or reject the entire app, rather than selectively choose the part of the app to view or use.
  - paulgb 4y ago
    You’re right, but it’s worth noting that nothing about that is particular to wasm. A JS app could equally avoid the DOM and render its own UI components via WebGL/WebGPU.
    - lowwave 4y ago
      wasm is just fast at doing that that's all. However, do make us to think we need another API for general JS without WebGL and GPU access.
  - pmoriarty 4y ago
    "there will come a time when it's trivially easy to write a full app in the browser via wasm" This will be facilitated by libraries and frameworks that do all the low-level heavy lifting for the developer, who'll be able to concentrate on higher level concerns.
deleted 4y ago
[deleted]
vardump 4y ago
Minified obfuscated Javascript isn't really all that different. You can create call graphs out of WASM binary as well, decompile and analyze it in detail. In fact, even before WASM, you could compile C++ to very hard-to-read asm.js subset of Javascript as well, see Emscripten. You could create tools to block WASM based on signatures, heuristics, behavioral analysis, etc. Difficulty level is very similar to doing same with Javascript. [0]: https://en.wikipedia.org/wiki/Emscripten https://en.wikipedia.org/wiki/Emscripten
- pmoriarty 4y ago
  "You could create tools to block WASM based on signatures, heuristics, behavioral analysis, etc." Yes, the concern is that as the browser becomes the operating system, we'll need anti-malware and anti-virus tools on it just as we've needed them on Windows.
flohofwoe 4y ago
WebAssembly just had its 7th anniversary. If it hasn't happened yet, it probably won't happen at any time in the future. And I think this hasn't happened because it wouldn't work with the "ad mafia" business model. Embedding hardwired ads into a WASM blob of an application doesn't make any business sense just as it doesn't make business sense to host ads locally from your own server. Instead ads are typically injected from an external ad network, and those requests can be filtered even when they are coming out of a WASM blob. As for the malware comment: WASM isn't any different from minified Javascript in that regard.
- Aldo_MX 4y ago
  > If it hasn't happened yet, it probably won't happen at any time in the future. Remember that ads is an unethical arms race and there was a time where ad companies were using VBScript to create system-level popups which defeated any popup blocker. The question is not if it will happen, but when and what will be the consequences.
- krapp 4y ago
  More to the point, it didn't happen with Java, it didn't happen with Flash and it didn't happen with Silverlight. This is just a perennial conspiracy theory.
jeroenhd 4y ago
You don't need wasm for that, anything that just throws up a huge <canvas> in the browser will do. What I expect wasm to do is to introduce new frameworks that take whatever the devs consider to be native behaviour and plonk it right into the browser. There are already plenty of demos out there that break the most basic browser features because compiling all of Qt into a canvas view can't possibly render a native experience. Then again, we've lost the concept of "native" years ago when we started packaging browser engines with popular applications. Soon we'll reach a stage where native code gets compiled to wasm, bundled with a slightly outdated copy of Chrome and sold off as a "native application".
mikewarot 4y ago
>the end user is basically going to be handed an opaque binary blob they can't do much with but execute. If you step back far enough, you realize that pretty much everything we run on our machines fits this definition. The key feature of WebAssembly is that the code has NO access to the rest of the system, by default. It's this freedom to just run anything, without the worry of unwanted side effects, that gives me hope for the future.
- ReactiveJelly 4y ago
  If they're comparing to JS, that was already true of JS. And JS is so easy to minify / obfuscate that de-obfuscating JS isn't much better than dis-assembling WebASM. Anything that gets popular gets dis-assembled, even MIPS and x86 binaries.
323 4y ago
The end point of ad blocking is neural networks analyzing the final rendered image before being shown to the user. This blocking could be strict, or lax, where you block even non-intentional ad stuff like someone writing in a HN comment "I love X".
- pmoriarty 4y ago
  "The end point of ad blocking is neural networks analyzing the final rendered image before being shown to the user." This is an endless cat-and-mouse game, where advertisers could start using DRM that prevents the viewer from interposing anything between the browser and the digitally-connected monitor. Maybe eventually users will start wearing AR glasses that filter out ads for them... Until advertisers figure out a way around that too.
postalrat 4y ago
Wasm executing in the browser can't do anything on it's own. Can't make requests, cant update the dom, can't ask for input, nothing. All that still needs to happen in javascript. So I don't see much has changed.

dotancohen 4y ago

The only way to fight that is to, as a community, refuse to run _all_ wasm that is found to serve ads, or infringe on privacy, or exhibit other malware traits. The only way to do that would be to use browser extensions that disable and report, to disable for other users automatically. But how would we identify the executables? hash? That can be changed trivially. I really fear that wasm brings us 180 degrees from "don't execute anything from the internet" to "all WWW usage is running other peoples' executables".

deleted 4y ago
[deleted]
jschrf 4y ago
That's already the case! Also, having other people tricked into running other-other people's code with the others' credentials against _your_ code. I think WASM will actually be more secure than the exsting www model. See: POST for an example :) I agree though... there will be bad actors and an ever evolving cat and mouse game

the_duke 4y ago

Wasm in the browser can only communicate by going through browser APIs. Most ad / analytics / tracker blocking works by intercepting HTTP requests, so they will work just as well for Wasm code. WASM that uses the regular DOM for rendering also doesn't really change blocking capabilities. The only real issue is visual/selector based blocking when frameworks do their own rendering via canvas, webgl or webgpu. Flutter does this. But doing your own rendering comes with a lot of overhead, both in download sizes, startup time and performance. Applications might do that (with lot's of caveats), but most websites never will. So I'm not that concerned. Wasm is certainly much lower level than JS, but also much higher level than Assembly. It's far from an opaque binary blob. All the minified and partially even obfuscated JS is not that much better.

chii 4y ago
> but most websites never will only because it's harder to do that right now than just describing a document via html. But there will come a time when it's trivially easy to write a full app in the browser via wasm, and the outcome will be that the user can either accept or reject the entire app, rather than selectively choose the part of the app to view or use.
- paulgb 4y ago
  You’re right, but it’s worth noting that nothing about that is particular to wasm. A JS app could equally avoid the DOM and render its own UI components via WebGL/WebGPU.
  - lowwave 4y ago
    wasm is just fast at doing that that's all. However, do make us to think we need another API for general JS without WebGL and GPU access.
- pmoriarty 4y ago
  "there will come a time when it's trivially easy to write a full app in the browser via wasm" This will be facilitated by libraries and frameworks that do all the low-level heavy lifting for the developer, who'll be able to concentrate on higher level concerns.

deleted 4y ago

[deleted]

vardump 4y ago

Minified obfuscated Javascript isn't really all that different. You can create call graphs out of WASM binary as well, decompile and analyze it in detail. In fact, even before WASM, you could compile C++ to very hard-to-read asm.js subset of Javascript as well, see Emscripten. You could create tools to block WASM based on signatures, heuristics, behavioral analysis, etc. Difficulty level is very similar to doing same with Javascript. [0]: https://en.wikipedia.org/wiki/Emscripten https://en.wikipedia.org/wiki/Emscripten

pmoriarty 4y ago
"You could create tools to block WASM based on signatures, heuristics, behavioral analysis, etc." Yes, the concern is that as the browser becomes the operating system, we'll need anti-malware and anti-virus tools on it just as we've needed them on Windows.

flohofwoe 4y ago

WebAssembly just had its 7th anniversary. If it hasn't happened yet, it probably won't happen at any time in the future. And I think this hasn't happened because it wouldn't work with the "ad mafia" business model. Embedding hardwired ads into a WASM blob of an application doesn't make any business sense just as it doesn't make business sense to host ads locally from your own server. Instead ads are typically injected from an external ad network, and those requests can be filtered even when they are coming out of a WASM blob. As for the malware comment: WASM isn't any different from minified Javascript in that regard.

Aldo_MX 4y ago
> If it hasn't happened yet, it probably won't happen at any time in the future. Remember that ads is an unethical arms race and there was a time where ad companies were using VBScript to create system-level popups which defeated any popup blocker. The question is not if it will happen, but when and what will be the consequences.
krapp 4y ago
More to the point, it didn't happen with Java, it didn't happen with Flash and it didn't happen with Silverlight. This is just a perennial conspiracy theory.

jeroenhd 4y ago

You don't need wasm for that, anything that just throws up a huge <canvas> in the browser will do. What I expect wasm to do is to introduce new frameworks that take whatever the devs consider to be native behaviour and plonk it right into the browser. There are already plenty of demos out there that break the most basic browser features because compiling all of Qt into a canvas view can't possibly render a native experience. Then again, we've lost the concept of "native" years ago when we started packaging browser engines with popular applications. Soon we'll reach a stage where native code gets compiled to wasm, bundled with a slightly outdated copy of Chrome and sold off as a "native application".

mikewarot 4y ago

>the end user is basically going to be handed an opaque binary blob they can't do much with but execute. If you step back far enough, you realize that pretty much everything we run on our machines fits this definition. The key feature of WebAssembly is that the code has NO access to the rest of the system, by default. It's this freedom to just run anything, without the worry of unwanted side effects, that gives me hope for the future.

ReactiveJelly 4y ago
If they're comparing to JS, that was already true of JS. And JS is so easy to minify / obfuscate that de-obfuscating JS isn't much better than dis-assembling WebASM. Anything that gets popular gets dis-assembled, even MIPS and x86 binaries.

323 4y ago

The end point of ad blocking is neural networks analyzing the final rendered image before being shown to the user. This blocking could be strict, or lax, where you block even non-intentional ad stuff like someone writing in a HN comment "I love X".

pmoriarty 4y ago
"The end point of ad blocking is neural networks analyzing the final rendered image before being shown to the user." This is an endless cat-and-mouse game, where advertisers could start using DRM that prevents the viewer from interposing anything between the browser and the digitally-connected monitor. Maybe eventually users will start wearing AR glasses that filter out ads for them... Until advertisers figure out a way around that too.

postalrat 4y ago

Wasm executing in the browser can't do anything on it's own. Can't make requests, cant update the dom, can't ask for input, nothing. All that still needs to happen in javascript. So I don't see much has changed.