111–120 of 135 posts
Earlier quoted context omitted.
Nothing is 100%. It’s effectively impossible.
This disproves your point. How many "effectively impossible" exploits have come out recently?
Earlier quoted context omitted.
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.
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…
I think that misses part of the point. 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…
It's really a pity especially since Go is marketed as "a better C". So far C/C++ has been the best optimal target for wasm. Rust on the other hand is extremely promising but I don't have enough experience with it or data to make a case for or against :)
AssemblyScript looks amazing though. One thing to consider is that many times you do not need to make your whole project in wasm. Instead you should find crucial bottlenecks (eg matrix math for light calculations, or some blur operation, or some physics calculation or whatever) and take that part out and put it in wasm. That part may already be written in JS and might be very difficult to rewrite in C (time consuming, web dev team might have weak C skills, tougher to debug). For such a scenario AssemblyScript looks fantastic, and this is actually the most common scenario I 've personally encountered (and sometimes I 'd end up writing asm.js by hand or go and recreate my logic in C...). So yeah, I have not used AssemblyScript yet but there are many pain points that a good implementation could blow away.
edit: what I describe above is for browser scenarios. I have not used wasm outside of the browser (didn't find a reason to, since I can run native binaries compiled specifically for the target OS - why add one more layer of complexity through wasm?). So, outside of the browser, your experiences might be different.
Earlier quoted context omitted.
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.
I've spent a good amount of time this last year playing around with WASM options in anticipation of it being a major runtime environment for cloud computing. 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 standa…
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.
How often does portability ever appear as a tie-breaker between to different languages?
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…
I think that misses part of the point. 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…
Frankly, it's not really TS, it's an odd, unofficial subset of it - kind of like hacking some nice things about TS to 'make it work'.
Not only is there the fact that it's OO, it needs a VM, it doesn't even support Strings ... so many questions marks.
V8 as it turns out is a pretty good black box. Every one of us runs completely untrusted code on our machines ever day.
Pretty most (all?) Shopify staffers and devs are, every day, running untrusted JS code on V8.
So it's nice to see progress, and I can't wait to see more details, but it looks tricky from the start ... and TS was never going to be the obvious starting point for WASM.
Earlier quoted context omitted.
You can’t change the email on existing accounts however you can definitely delete it. See the docs https://help.shopify.com/en/manual/your-account/privacy/GDPR... Their account management is definitely poor. But you seem to make it a bigger deal than it is. You don’t have to lose the order history, even if you don’t have access to the email anymore nothing would prevent you from logging again with the user/pass. And…
> You can’t change the email on existing accounts however you can definitely delete it. I am an end user and cannot do anything other than email the shop support and hope. I am not a resident of EU or California, you might be surprised at the vast number of websites which tell you to go pound sand if you try and delete your account. As a user, you can do nothing but hope someone deletes something for you if they feel…
Earlier quoted context omitted.
You've been downvoted to oblivion. Don't you think that's a sign that maybe you're wrong?
Whether or not people who likely have no actual experience in this space dislike what I’m saying about the pointlessness of using wasm for this use case has no bearing on my correctness. Most of them demonstrated they didn’t know the difference between seccomp and seccomp-bpf and there have been no rational counter arguments that hold their weight. Usually downvotes without rational rebuttals are a sign of the OP’s c…
In this case anyone with experience in computer security can tell you multiple layers of defense are always better than one.
Seccomp is great, and I think you actually have a point about it, but it's hard to get right without locking out all system calls entirely - and that's hard to do and still run a program, even a barebones C program.
With higher level languages it's immediately insufficient.
Earlier quoted context omitted.
I've spent a good amount of time this last year playing around with WASM options in anticipation of it being a major runtime environment for cloud computing. 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 standa…
Do you have a fork of the compiler online?
zig build-lib add.zig -O ReleaseSmall -target wasm32-freestanding -static
The issue tracking the problem is: https://github.com/ziglang/zig/issues/7133
Earlier quoted context omitted.
I think that misses part of the point. 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…
In my experience GO is not a good language for WASM. The simplest wasm binary you will create, will be at least ~3mb in size, even if it only prints "hello world", because GO will need to embed its internals and the garbage collector in the wasm bundle. In a browser scenario this is not particularly attractive... It's really a pity especially since Go is marketed as "a better C". So far C/C++ has been the best optima…