3 ms·
> It's usually more performant and is less of a security risk. Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert
by FabHK 7y ago
> It's usually more performant and is less of a security risk.
Source, particularly for the "less of a security risk"? (It might well be now, I'm not an expert, but a few years ago I'd have thought "no way").
- allannienhuis 7y agoI expect he's referring to the web page running in a sandbox vs running an app locally with no sandbox.
- rawrmaan 7y agoWhat's the mystery here? It doesn't have access to your file system or the ability to request root access.
- ashelmire 7y agoWhich do you think is more potentially damaging? 1) Using a website which has had its server code compromised (slack). 2) Installing and using an application which has had its code compromised (maybe also slack). The installed application is going to have more access and potential to damage your system and to compromise your data. There's not really anything more to it. One's in a browser sandbox and limited by browser capability, the other can do literally anything it wants.
- FabHK 7y agoMakes sense, thanks. I think my mental threat model was different: you're talking about dodgy (potentially compromised) software: better run in the browser sandbox (albeit imperfect) than natively. I was thinking of sensitive software (eg secret chats) I want to protect from attack: better run natively than in the (imperfect) browser sandbox. In the context of this discussion (Slack), your threat model probably makes more sense.
- dx87 7y agoSoftware running in a browser is probably going to heavily sandboxed and have tight restrictions on what it can access since the purpose of a browser is to run untrusted code. Native software will usually have minimal sandboxing because it's supposed to be trusted, and can do anything the user running it could do. As far as performance, I think that only applies to apps like Slack and Spotify that use Electron to pretend to be a native app.