Live data from Hacker News

WebAssembly’s post-MVP future

hacks.mozilla.org

201–207 of 207 posts

Re: WebAssembly’s post-MVP future

#201
post #52
post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Why not implement the GCs themselves using low-level WASM code? That would enable a language-agnostic approach (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

The kinds of memory guarantees and controls a GC wants for good performance seem to be the kind of things you wouldn't want to give to some random third-party.

Re: WebAssembly’s post-MVP future

#202
post #191

Earlier quoted context omitted.

Meta-data can be embedded to describe and categorize content. But accessibility is usually not a goal for many "office productivity" applications (per my domain-specific standards suggestion). Usage of DOM alone does not guarantee accessibility either. As far as Qt, while it may be a good starting point, I don't think direct C++ calls is practical. Some intermediate markup or declarative language should be formed aro…

> accessibility is usually not a goal for many "office productivity" applications I think I might be misunderstanding you. Are you saying accessibility is usually not a goal for the kind of applications that people need to be able to use to do their jobs?

I believe there's a reasonable limit to how adaptable workplace software has to be to those with poor vision, etc.

Re: WebAssembly’s post-MVP future

#203
post #191

Earlier quoted context omitted.

Let's not do that until we have a way to make non-DOM-based web applications accessible to screen readers and other assistive technologies.

Meta-data can be embedded to describe and categorize content. But accessibility is usually not a goal for many "office productivity" applications (per my domain-specific standards suggestion). Usage of DOM alone does not guarantee accessibility either. As far as Qt, while it may be a good starting point, I don't think direct C++ calls is practical. Some intermediate markup or declarative language should be formed aro…

> Some intermediate markup or declarative language should be formed around it: a declarative wrapper around Qt.

QML is exactly that.

Re: WebAssembly’s post-MVP future

#205

Earlier quoted context omitted.

Hi. Cloudflare Workers tech lead here. No, process isolation does not work for us, because it does not scale well enough. The point of Cloudflare Workers is to distribute your code across Cloudflare's entire edge network -- 154 locations and growing -- so that you can respond to requests at the closest location to your end user. We want to put every customer's code in every location, rather than forcing you to choose…

Do you see the complexity of V*'s multi-tiered JIT compiler as a security risk? Maybe a simple JS interpreter plus a simple AOT WebAssembly-to-x64 compiler would be safer.

Complexity is a risk, but we also care deeply about performance and startup time in much the same ways Chrome does. So we need that JIT.

I'm comforted by the fact that if there's a breakout in V8, Chrome is a much juicier target than we are -- and has an incredibly strong security team that will jump on the issue. I think we would be overall less secure using a lesser-known JS implementation.

Re: WebAssembly’s post-MVP future

#206

Earlier quoted context omitted.

Do you see the complexity of V*'s multi-tiered JIT compiler as a security risk? Maybe a simple JS interpreter plus a simple AOT WebAssembly-to-x64 compiler would be safer.

Complexity is a risk, but we also care deeply about performance and startup time in much the same ways Chrome does. So we need that JIT. I'm comforted by the fact that if there's a breakout in V8, Chrome is a much juicier target than we are -- and has an incredibly strong security team that will jump on the issue. I think we would be overall less secure using a lesser-known JS implementation.

Actually, I think Cloudflare is a juicier target, due to a combination of two things:

1. No process isolation 2. Data from lots of users on any given node

Am I missing something?

Re: WebAssembly’s post-MVP future

#207

Earlier quoted context omitted.

Complexity is a risk, but we also care deeply about performance and startup time in much the same ways Chrome does. So we need that JIT. I'm comforted by the fact that if there's a breakout in V8, Chrome is a much juicier target than we are -- and has an incredibly strong security team that will jump on the issue. I think we would be overall less secure using a lesser-known JS implementation.

Actually, I think Cloudflare is a juicier target, due to a combination of two things: 1. No process isolation 2. Data from lots of users on any given node Am I missing something?

While I don't mean to deny the risk, which we take very seriously, I do think there's a number of reasons Chrome remains a much more interesting target:

* While process isolation makes Chrome somewhat less interesting than it used to be, keep in mind that process isolation is being rolled out as a defense to arbitrary-read attacks (like spectre), not arbitrary-code-execution attacks. Executed code can potentially talk to the rest of Chrome and perform actions that a web site is not intended to be allowed to. (At least in the past, this included the ability to read all the user's cookies, though it's possible they've improved on that, I don't know.)

* Cloudflare has potentially multiple tenants in a node, but the attacker has no control over who they are. There's no particularly good way to target a specific end user nor a specific web site.

* V8 vulnerabilities are likely to be memory safety issues, which are difficult to leverage into an attack without an understanding of the process's memory space, which is hard to get without having access to the source code or a compiled binary. The attacker would be flying blind and would almost certainly just segfault or be caught by our layer 2 sandbox (which blocks almost all syscalls), which incidentally would immediately alert us to their activity. (I don't particularly like this as a defense, since I like open source -- but frankly, it is a pretty big barrier.)

* The attacker would be burning their zero-day by uploading it to Cloudflare. We block eval() and the like, such that the only way to run code on our edge is by uploading it through our deployment APIs, which keep a copy.

* Last I checked, Chrome still does not use site isolation on mobile, because the overhead is too high.

Post reply on HN