5 ms·

WASM doesn't have DOM access (yet).

irrational 7y ago
That is interesting. I didn't realize WASM was designed to be so constrained.
EvanAnderson 7y ago
WASM doesn't need DOM access. You can just implement a browser in WASM and target canvas. I'm really surprised somebody hasn't done this already and marketed it as an unblockable ad delivery platform.
- Faark 7y ago
  How many accessibility laws does this violate? Does it work with a screen reader?
  - EvanAnderson 7y ago
    You can be certain that, when this does happen, these considerations will be dealt with. I feel very strongly that this is going to happen. The chance to execute arbitrary code on clients will be too alluring for adtech companies to ignore.
    - folkrav 7y ago
      "Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.
      - naniwaduni 7y ago
        You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.
        folkrav 7y ago
        For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback. Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch. Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.
        EvanAnderson 7y ago
        Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.
- irrational 7y ago
  How big of a WASM binary would that be? Can we block WASM binaries that are over a certain size in the browser?
  - EvanAnderson 7y ago
    You won't be able to block the binary, because the binary will be what renders the content. Your browser is going to act as a VM to run a browser that will display the content. The "inner" browser will be running on your computer, but short of binary reverse engineering, you won't be able to control it.
    - pdkl95 7y ago
      > Your browser is going to act as a VM to run a browser that will display the content. Gary Bernhardt's talk "The Birth & Death of JavaScript"[1] was an ominous portent of a terrifying future. Unfortunately, some people apparently saw it as development roadmap. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- HugoDaniel 7y ago
  those two would be easy blocks: the canvas showing the ad, and the wasm payload for that to happen
  - throwaway2048 7y ago
    Except the content is mixed into the WASM payload...
- GrayShade 7y ago
  You can already do that in JavaScript, what's the difference? You can even implement a WASM interpreter in JS.
  - EvanAnderson 7y ago
    Functionally, nothing. WASM being a compiler target just lowers the bar (although we've had Emscripten for years). The browser developers are working hard to make it performant, too. Sufficiently obfuscated Javascript is as difficult to reverse engineer as a binary, though.
    - GrayShade 7y ago
      I don't do web, but I imagine there must be some webpack plugins that make an obfuscated mess out of your code, so the barrier to entry must already be quite low. WASM at least is standardized, so there will be a whole ecosystem dedicated to it. Think IDA Pro for WASM. > although we've had Emscripten for years We did. And I didn't see the "asm.js apocalypse" you seem to fear.
      - EvanAnderson 7y ago
        I don't "fear" an "asm.js apocalypse". It's just the next step in the arms race between those who would have the Internet be like television, and those who would prefer it not. I'm one of the people who would have rather had the web stay more like Gopher and less like Java, but that's not the predominant opinion. We're going to lose the document-oriented declarative web because the web is financed by advertising. The spice must flow-- the ads must not be allowed to be blocked. WASM is different between Emscripten was always a fun curiosity, and WASM is being "marketed" to developers as "get native app performance in a browser". "Modern" Javascript has been able to deliver this future for a few years now, but it lacked the marketing and tooling to make it mainstream. Flash and Java were attempts to move to that future that didn't pan out. Having IDA Pro for WASM is all well and good, but doing binary reverse engineering on every single website isn't practical. The web, as it has been, was nice. We're not going to get to keep it. I'm unhappy with it, but I'm resigned to it.

That is interesting. I didn't realize WASM was designed to be so constrained.

WASM doesn't need DOM access. You can just implement a browser in WASM and target canvas. I'm really surprised somebody hasn't done this already and marketed it as an unblockable ad delivery platform.

Faark 7y ago
How many accessibility laws does this violate? Does it work with a screen reader?
- EvanAnderson 7y ago
  You can be certain that, when this does happen, these considerations will be dealt with. I feel very strongly that this is going to happen. The chance to execute arbitrary code on clients will be too alluring for adtech companies to ignore.
  - folkrav 7y ago
    "Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.
    - naniwaduni 7y ago
      You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.
      - folkrav 7y ago
        For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback. Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch. Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.
        EvanAnderson 7y ago
        Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.
irrational 7y ago
How big of a WASM binary would that be? Can we block WASM binaries that are over a certain size in the browser?
- EvanAnderson 7y ago
  You won't be able to block the binary, because the binary will be what renders the content. Your browser is going to act as a VM to run a browser that will display the content. The "inner" browser will be running on your computer, but short of binary reverse engineering, you won't be able to control it.
  - pdkl95 7y ago
    > Your browser is going to act as a VM to run a browser that will display the content. Gary Bernhardt's talk "The Birth & Death of JavaScript"[1] was an ominous portent of a terrifying future. Unfortunately, some people apparently saw it as development roadmap. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
HugoDaniel 7y ago
those two would be easy blocks: the canvas showing the ad, and the wasm payload for that to happen
- throwaway2048 7y ago
  Except the content is mixed into the WASM payload...
GrayShade 7y ago
You can already do that in JavaScript, what's the difference? You can even implement a WASM interpreter in JS.
- EvanAnderson 7y ago
  Functionally, nothing. WASM being a compiler target just lowers the bar (although we've had Emscripten for years). The browser developers are working hard to make it performant, too. Sufficiently obfuscated Javascript is as difficult to reverse engineer as a binary, though.
  - GrayShade 7y ago
    I don't do web, but I imagine there must be some webpack plugins that make an obfuscated mess out of your code, so the barrier to entry must already be quite low. WASM at least is standardized, so there will be a whole ecosystem dedicated to it. Think IDA Pro for WASM. > although we've had Emscripten for years We did. And I didn't see the "asm.js apocalypse" you seem to fear.
    - EvanAnderson 7y ago
      I don't "fear" an "asm.js apocalypse". It's just the next step in the arms race between those who would have the Internet be like television, and those who would prefer it not. I'm one of the people who would have rather had the web stay more like Gopher and less like Java, but that's not the predominant opinion. We're going to lose the document-oriented declarative web because the web is financed by advertising. The spice must flow-- the ads must not be allowed to be blocked. WASM is different between Emscripten was always a fun curiosity, and WASM is being "marketed" to developers as "get native app performance in a browser". "Modern" Javascript has been able to deliver this future for a few years now, but it lacked the marketing and tooling to make it mainstream. Flash and Java were attempts to move to that future that didn't pan out. Having IDA Pro for WASM is all well and good, but doing binary reverse engineering on every single website isn't practical. The web, as it has been, was nice. We're not going to get to keep it. I'm unhappy with it, but I'm resigned to it.