3 ms·
no if you don't target DOM, if i could have "browser" in a browser that targets canvas or webgl then i cannot block it, only on network level.
by disiplus 8y ago
no if you don't target DOM,
if i could have "browser" in a browser that targets canvas or webgl then i cannot block it, only on network level.
- steveklabnik 8y agoYou can use canvas or webgl from JavaScript too, so there's no change here specific to wasm.
- deleted 8y ago[deleted]
- TeMPOraL 8y agoExcept JS alone wasn't good enough for that; WASM, especially as a compilation target, seems to make the task of embedding a browser within a webpage easier.
- disiplus 8y agoyou can but, wasm should be an order of magnitude faster then javascript, this makes it possible to run all kinds of "heavy" apps in the browser. some kind of client that outputs to webgl in this case shoud be doable, in pure js it would be to slow /expensive.
- EvanAnderson 8y agoYou won't be able to block it on a network level either when it's running on a locked-down platform like iOS and using an eventual iteration of TLS that prevents man-in-the-middle inspection. This feels like yet one more step in the direction of "you don't own your computer anymore".
- disiplus 8y agoi was more thinking on DNS level, but with DNS encryption even that falls on it's face.
- ec109685 8y agoDNS encryption is done by the OS, which you control, so you could still null route ad servers.
- jaegerpicker 8y agoexcept iOS has some of the best ad-blocking available, with OS level extensions that are almost impossible to get around. So your point doesn't really make a ton of sense.
- EvanAnderson 8y agoThe OS-level tools won't be able to inspect the websockets-based channel that the browser-in-browser uses to communicate with its back-end. It will all be opaque TLS-encrypted traffic to the OS. The native browser will be hosting a canvas element that will host the UI and running WASM code and that'll be all the OS will see.