91–100 of 135 posts
Earlier quoted context omitted.
I think you’re referring to seccomp-bpf. seccomp has never been escaped and it is unlikely such a bug could happen due its simplicity. If you do not know the difference between seccomp and seccomp-bpf, please check references: https://en.wikipedia.org/wiki/Seccomp
Unlikely? Sounds like you think it could happen.
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.
There might also be the point of APIs. I'm no expert, but I imagine in-browser WASM must have access to some set of browser-specific APIs to communicate with JS and the DOM. Shopify won't have those APIs available in its runtime environment, but will probably offer different APIs to communicate with the purchase flow etc. I don't know how the WASM tooling landscape looks, but if most tools assume the browser APIs to be available, this could make it harder to develop WASM for other contexts. E.g., you can compile Unity games to WASM, but that WASM will assume that it runs in a browser. You probably couldn't use Unity to write a Shopify plugin.
Earlier quoted context omitted.
Yes, I work at Shopify and our first party subscription support just recently launched a few months ago.
Awesome! Very exciting. I recently launched a small business which has a natural subscriptions element ( https://narwallmask.com - a mask with replacement filters, which you may want regularly) but without subs integrated into shopify checkout, I decided simply not to offer it. Maybe now I can! Can you say whether wasm helped make this happen? Seems quite plausible to me...
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 ge…
Like always, browsers are a funny ecosystem and very unpredictable. In all this time I thought that I could see a rise in the adoption of C and Rust libs by the community through WASM but now instead we are building around AssemblyScript. Touche.
This is PR about Shopify’s use/promise of WebAssembly—cool. I get WebAssembly tech is cool. I’m interested why Shopify is practically the only sales platform that gets ‘airtime’ at HN. Is this because partner apps are using Ruby? Does it have something to do with the governance of Shopify? Community of Canadians on HN? I have some experience with Square, and a few others. I’m an interested party.
Do Shopify's competitors produce similarly high-quality engineering content? (if you know some, please link!)
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 ge…
Like always, browsers are a funny ecosystem and very unpredictable. In all this time I thought that I could see a rise in the adoption of C and Rust libs by the community through WASM but now instead we are building around AssemblyScript. Touche.
Rust has the most developed ecosystem but the best experience I've had otherwise was with Zig. It's reasonably easy to write and can produce excellent final wasm size. The only problem is that the compiler is currently exporting every public symbol in the standard library but when I hacked up the compiler to only export a hard coded list of symbols I got ~150 bytes for add (the WASM hello world) and easily sub 1k for the type of modules the post is discussing.
Earlier quoted context omitted.
* 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…
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 ge…
WASM meets their feature needs. WASM is at the core of it.
But, they needed a widely accessible language to tell people to use. This helps with examples and guidance. They chose AssemblyScript due to their customers being familiar with JS.
It looks like I could write what I need in Go or Rust, for example, and build for WASM. They’re just not putting that up front. This is about making an easy path for most people.
The way it’s put together is about n making their customers successful rather than building all that’s possible
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?
We are talking about two alternative architectures, Cloudflare Workers and Fastly Compute@Edge, solving the same problem: how to run server-side untrusted code. Cloudflare runs a sandboxed V8 runtime in-process with its Nginx servers while Fastly chose a Function-as-Service platform using Lucet compiled WebAssembly modules with minimal runtime and fast startup. Fastly’s Varnish servers invoke FaaS modules and it soun…
Maybe nitpicking, but that's not quite right. The Workers Runtime is a separate process from nginx and is inside a heavy second-layer sandbox separating it from the rest of the system. Multiple Workers Runtime instances exist on each machine to serve different tiers of customers, and each instance may additionally create further subprocesses to provide extra sandboxing adaptively.
Here's a diagram: https://blog.cloudflare.com/mitigating-spectre-and-other-sec...
(In that diagram, the "Inbound/Outbound HTTP Proxy" boxes are, at least at present, nginx, but the big middle box is a new server architecture written from scratch.)
Earlier quoted context omitted.
I don't think you get security. It's about threat mitigation. There is nothing secure, including seccomp jails. You want defence in depth - that is using multiple layers of defence to reduce the risk. You can never get it to 0, but if you combine two mechanisms that are each 99% effective, then your risk is now 0.01% instead of 1%. That's obviously an improvement. You don't run your database without a password (hopef…
I don’t think you get the difference between seccomp and seccomp-bpf