@kev @purism you may also wanna add that it lacks default disk encryption, apps run unsandboxed by default, and lacks any kind of boot security.

It litterly sets back years of security advancements made in the mobile space.

@blacklight447 @kev not defending the librem 5, but not sandboxing apps is totally fine if you install them from a trusted distribution. It's only necessary on Android because Google Play is a malware distributor. Debian is not.

@sir @kev there is no reason to not sandbox your apps, why give needless trust to app distributers?

@blacklight447 @kev the trust model works differently on typical linux distibutions. The threats just aren't the same.


@blacklight447 @kev and to answer your question directly: because it's more complex and poorly suited to the unix style. Unix programs don't work well in silos.

@sir @kev just because desktop linux is slacking behind on securiry advancements doesn't mean its a smart idea to recommend to end users to pay 800$ for a device which is significantly less secure the mature platforms. If the librem five was clearly marked to be experimental and should be used with caution, i would be fine with it, but currently thats not the case.

@blacklight447 @kev but it's not less secure. Sandboxing untrusted code is less secure than not running untrusted code in the first place. I'm not a securitybro absolutist like some.

@sir @kev "we can improve a users security by a long shot by providing sandboxing, but we trust the repo maintainers so lets not"

Thats kinda weird logic.

Remember security should be done in depth, if the trust in the maintainers fails, you still have trust in the isolation. Also what about folks who want/need software outside of the default repo's? Dont they deserve protection?

@blacklight447 @kev this is that dumb securitybro absolutism I was referring to. "Better security", at any costs. Everything is a tradeoff, and security does not have an infinite weight on that metaphorical scale.

Folks who want software outside of the default repos have the wrong want. It's like wanting to eat burnt tires.

@sir @blacklight447 @kev

>Sandboxing untrusted code is less secure than not running untrusted code in the first place.

Sandboxing and privilege dropping is just good hygiene. Your image viewer shouldn't be able to read keystrokes from other programs, start new processes, screen-record outside of itself, write to the filesystem, access the internet, etc. You might trust maintainers to be non-malicious, but do you trust all packaged code to act non-maliciously when faced with arbitrary untrusted input?
@passenger @sir @blacklight447 @kev this is a job for capability-based access control moreso than sandboxing
@passenger @sir @blacklight447 @kev i mean they *can* go hand-in-hand but to me sandboxing implies a containerised environment entirely, when that isnt always necessarily what you need
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!