zlacker

>>pjmlp+(OP)
This is objectively great news.

As long as it's function is to keep the program locked in, and not the user locked out from modifying it...

>>no_tim+X7
What exactly does it do for me as a user?

>>Camper+ff
It’s a security boundary. It lets you control the resources an application has access to. For example, if that cool weather app you just installed asks for access to your Documents directory, or your camera or microphone, you can say no.

>>cridde+Di
I see, it lets me install random .EXEs from sketchy web sites on my Windows machine without having to worry. Sounds safe.

>>Camper+gj
Whats your point? You just ran a bunch of untrusted code when you visitied this website.

>>iknows+2n
Untrusted code running in a well-defined and maintained sandbox.

>>EvanAn+qq
Yes and....

>>pauldd+vI1
Visiting a website and running Javascript vs. running a native application aren't equivalent. Browser sandbox exploits are "a thing" but that doesn't make the situations the same.

>>EvanAn+U93
Yes and WASM can be sandboxed just as easily as JavaScript.

There is nothing "magical" about web browsers in that regard.

>>pauldd+Jt3
I don’t follow where you’re going.

I didn’t say there was anything “magical” about browsers. They have a sandbox for JavaScript, by default. Windows doesn’t have a sandbox for native apps, by default.

A parent poster seemed to be making a statement of equivalency between running a native application in Windows and running JavaScript in a browser. I don’t think they’re equivalent.

That’s what I’m saying.