Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Shopify Uses WebAssembly Outside of the Browser

shopify.engineering

Post reply on HN
Print view View original

61–70 of 135 posts

Re: How Shopify Uses WebAssembly Outside of the Browser

#61

Post by marcosdumay »

officialchicken wrote: post #51
nih0 wrote: post #27

Earlier quoted context omitted.

can u elaborate on these jvm promises?

The "sandbox" promise was/is still offered as the primary line of defense for Java. "The first version of Java was released by Sun Microsystems in 1995 [2]. One year later, researchers at Princeton University identified multiple flaws enabling an analyst to bypass the sandbox [3]. The authors identified weaknesses in the language, bytecode and object initialization, to name a few, some of them still present in Java a…

The Java sandbox trusted any code signed with a SSL certificate by design, what didn't stop Sun from announcing it was secure and everything.

Re: How Shopify Uses WebAssembly Outside of the Browser

#62

Post by __s »

twic wrote: post #56

So how about garbage collection? WASM doesn't have GC in the machine model, right? So either customers have to use a language with manual memory management, which is hard work, or use one with GC and then compile the collector into their binaries, which means bloat, and possibly a sub-par GC. I guess what I'm saying is that it seems like it would have been better to have used a JVM.

https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

Re: How Shopify Uses WebAssembly Outside of the Browser

#63

Post by marcosdumay »

gfxgirl wrote: post #30
xg15 wrote: post #6

Earlier quoted context omitted.

Pro: You don't need server infrastructure to customise a Shopify flow. Con: You need coders knowledgeable in WASM. However, I could imagine that an ecosystem of "plugins" could emerge, i.e. ready-made WASM apps that merchants could plug into their stores. There might be more security issues though, if the developer of the WASM and the merchant using it aren't the same party. I think it will be interesting to see how…

Why do you need coders knowledgeable in WASM? The majority of coders will use something else (C, C++, Rust, C#, etc.) The majority of them don't need to know the details of the processor their compiler is targeting.

At the moment, knowing how to compile X to WASM and have it run is a kind of expertise.

I hope that changes, the sooner the better, but right now it's not trivial.

Re: How Shopify Uses WebAssembly Outside of the Browser

#64

Post by imtringued »

twic wrote: post #56

So how about garbage collection? WASM doesn't have GC in the machine model, right? So either customers have to use a language with manual memory management, which is hard work, or use one with GC and then compile the collector into their binaries, which means bloat, and possibly a sub-par GC. I guess what I'm saying is that it seems like it would have been better to have used a JVM.

How would that work? Secure multi tenancy is a difficult problem in its own right. You would now have to build a security layer outside the JVM because the JVM is exposing too many interfaces. You can use containers but the amount of interfaces a container exposes is still high enough that a container escape is possible. Then you need a security layer on top of containers based on VMs. At this point rolling your own security solution is either going to be highly inefficient because you are allocating too many resources to individual customers or expensive because developing infrastructure management to stay secure doesn't make your company more profitable. Your last hope would be to use an off the shelf solution like firecracker to run each JVM in a VM.

Alternatively you can just use a runtime that is sandboxed by default and avoid the cat and mouse game.

Re: How Shopify Uses WebAssembly Outside of the Browser

#65

Post by etimberg »

jedisct1 wrote: post #32
peteretep wrote: post #16

> you cannot express anything malicious in Wasm This feels like a comment that will as age as badly as “you can’t get a virus just from looking at an email”

You can’t express anything malicious in JavaScript either, yet vulnerabilities are constantly found in web browsers, including WebAssembly JITs. You can express malicious things in Go, yet the number of RCEs in Go apps is pretty much zero.

What about something like https://github.com/IAIK/rowhammerjs ?

Re: How Shopify Uses WebAssembly Outside of the Browser

#66

Post by imtringued »

CyberRabbi wrote: post #22
devwastaken wrote: post #19

Earlier quoted context omitted.

That's a pretty bold statement. I'd like to see an in depth analysis between the two before supporting that.

It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying running an entire wasm runtime, likely >= 50K LOC in additional complexity and attack surface. Seccomp uses a small 100 line shim.

You can run WASM to grant fine grained access to certain APIs. You might be able to do this with a sidecar that provides the API over HTTP and then let the untrusted process only access the side car but why do this when you can just grant API access to a WASM module? From the perspective of the third party user the API can be called directly via a function instead of doing a HTTP request.

Re: How Shopify Uses WebAssembly Outside of the Browser

#67

Post by sradman »

The underlying platform is ahead-of-time compiled WebAssembly but AssemblyScript, a variant of TypeScript, will be the only supported language:

> Theoretically any language with a Wasm target can be supported, but the effort developers spend to conform to our API is better focused on solving problems for merchants. That’s why we’ve chosen to provide first class support to a single language that includes tools that get developers up and running quickly.

Re: How Shopify Uses WebAssembly Outside of the Browser

#68

Post by imtringued »

CyberRabbi wrote: post #46
feanaro wrote: post #38

Earlier quoted context omitted.

> Using wasm in addition to seccomp strictly increases your attack surface. If you want to maximize security you would only use seccomp. Huh? How so?

The wasm vm has to parse, validate, and compile untrusted input. It also exposes host calls. Those are all potential attack vectors. That’s at least roughly 50K LOC.

>It also exposes host calls.

Only if you grant explicit access to them. What usually happens is that there is a vendor provided API that only gives you access to exactly what you need which is significantly less powerful than a complete linux process that can write to files, spawn background threads, etc all by default.

Yes you can block access to these things but you're going to miss something at some point.

Re: How Shopify Uses WebAssembly Outside of the Browser

#69

Post by jariel »

alquemist wrote: post #26
martin_drapeau wrote: post #14

Could someone eligthen me. Why not just use JavaScript? It is being used by Cloudflare on the edge, and AWS lambda. Why need to go to WASM?

* Predictable performance. * A wide ecosystem of mature language toolchains. * Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator. * Portability: not tied to a specific HW architecture.

? Those are reasons to use JS not WASM.

"A wide ecosystem of mature language toolchains." - yes, for Javascript, not for WASM, which isn't deployed really anywhere in production and there aren't even best practices for it.

What language are devs going to even write these scripts in? That's not clear.

"Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over.

"Portability" - again, nothing more portable than JS.

The reasons to use WASM are 'performance' along with 'black box' - but in most cases performance is not necessary and the black box for all intents and purposes exists with v8.

Re: How Shopify Uses WebAssembly Outside of the Browser

#70

Post by x86_64Ubuntu »

alquemist wrote: post #26
martin_drapeau wrote: post #14

Could someone eligthen me. Why not just use JavaScript? It is being used by Cloudflare on the edge, and AWS lambda. Why need to go to WASM?

* Predictable performance. * A wide ecosystem of mature language toolchains. * Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator. * Portability: not tied to a specific HW architecture.

How often does portability ever appear as a tie-breaker between to different languages?
Post reply on HN