5 ms·
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...
by no_time 3y ago
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...
- CamperBob2 3y agoWhat exactly does it do for me as a user?
- criddell 3y agoIt’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.
- CamperBob2 3y agoI see, it lets me install random .EXEs from sketchy web sites on my Windows machine without having to worry. Sounds safe.
- iknowstuff 3y agoWhats your point? You just ran a bunch of untrusted code when you visitied this website.
- EvanAnderson 3y agoUntrusted code running in a well-defined and maintained sandbox.
- paulddraper 3y agoYes and....
- EvanAnderson 3y agoVisiting 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.
- paulddraper 3y agoYes and WASM can be sandboxed just as easily as JavaScript. There is nothing "magical" about web browsers in that regard.
- EvanAnderson 3y agoI 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.
- iknowstuff 3y agoWe are literally talking about an environment for running Win32 apps in a sandbox
- hardware2win 3y agoStill stuff manages to escape constantly You can find exploits on gh for older chromium versions easily
- EvanAnderson 3y agoEven so it's disingenuous to compare running native code in an OS w/o a capabilities model to running Javascript in a browser.
- parl_match 3y agoRunning a native binary in an environment with a large attack space and user level permissions is not NEARLY the same as running javascript in a browser with all of its sandboxing, isolation, and controls. And you know it.
- pwg 3y agoIndeed, but sadly, features designed to "keep the program locked in" can also often be miss-used to "keep thee user locked out". Only time will tell where this one goes.
- iggldiggl 3y agoAnd all the file sandboxing approaches I've seen so far only seem to cater for the simple "choose a single file (or directory)" workflow and break multi-file formats, any customised UX around file I/O and any other advanced workflows. To some extent that's just laziness, because who cares for the long tail of workflows, right, and to some extent unfortunately it's a fundamental trade-off of sandboxing (the OS can't know the details of each and every file format and which files are related and need to be opened together even if the user only launched one file, the application developer does know, but is the untrusted party; being able to paste a file path directly into a GUI respectively directly edit it there can be comfortable, but it bypasses the official secure OS file picker, so again a no-go, etc. etc.).
- mike_hearn 3y agoThe Mac sandbox grants access to the whole directory when a file is selected, iirc. I'm curious what you mean by customized UX around file I/O?
- iggldiggl 3y ago> The Mac sandbox grants access to the whole directory when a file is selected, iirc. Does it, by default? https://developer.apple.com/documentation/security/app_sandbox/accessing_files_from_the_macos_app_sandbox https://developer.apple.com/documentation/security/app_sandb... [1] doesn't look like it, and there seem to be special features for requesting access to related files which wouldn't be necessary if selecting a file gave you access to the whole directory. Though I've got no Mac, so no idea how this actually works in practice – maybe you're right, though it'd also noticeably weaken the sandbox, which seems strange. > I'm curious what you mean by customized UX around file I/O? Simply things like a directory tree control integrated into the UI, IrfanView's directory switcher (when you reach the start or end of a directory while browsing through your pictures, it pops up a dialogue that allows you to easily – and without having to use the mouse – navigate up and down the directory tree to a different folder), or even something as simple text input control that allows direct editing instead of always having to go via an official OS file picker. [1] It seems like Apple does have some support for storing relative file references after all ("document-scoped bookmarks"), so that picking something like a master project file also gives access to all related documents, no matter how complex the file format is, though I have no idea whether those really work even when moving files between different devices, and they almost certainly won't work for cross-platform file formats, because non-Mac software will of course have no idea about that kind of thing. And last time I looked, Android's and Windows's sandbox implementation didn't have anything comparable, and Linux likely doesn't, either…