4 ms·

Capsicum shows that the capability model can be practically implemented within Unix, ignoring bugs (i.e. ignoring monolithic vs microkernel consequences). But t

by wahern 5y ago

Capsicum shows that the capability model can be practically implemented within Unix, ignoring bugs (i.e. ignoring monolithic vs microkernel consequences). But the poor uptake of Capsicum and the popularity of Docker also show how impractical it is for the current ecosystem of software, even though conceptually it should be a relatively easy shift. It's far easier to enforce and adopt in the context of smartphones and IoT, where APIs are already highly restricted. But these restrictions also reflect a substantially limited capacity to innovate--only the platform provider can innovate locally; everybody else has to treat the environment as a dumb terminal with accelerated graphics. Even the underlying capability frameworks are largely hidden; capabilities are an implementation detail of the exposed APIs from the perspective of the application--unless the application developer is also the platform developer like with Google and Chrome.

contextfree 5y ago
Windows has had a similar problem with UWP (which is based on a rudimentary capability system and implements the file dialog powerbox pattern outlined in mikewarot's post)
iggldiggl 5y ago
> But these restrictions also reflect a substantially limited capacity to innovate They also break already existing applications and workflows – there are e.g. quite a few file formats around that don't work with the "pick a single file and that's all you can access without pestering the user once more" model: - separately stored subtitles (media players currently automatically look for those when opening a video, but with strictly sandboxed file access that would no longer work) - playlists (opening a playlist should likely implicitly allow that application to also access all the files referenced therein, but of course the OS can't be expected to understand each and every filetypes intricacies) - multi-part videos - multi-part archives - HTML documents with links to other documents and/or separately stored resources (media files/CSS/JS) - any other kind of multi-file file format Along the same lines, download manager extensions in Firefox have become semi-useless since the switch to webextensions, because there's no way to download multiple files elsewhere than the OS downloads folder without asking the user for each and every file.

by wahern 5y ago

contextfree 5y ago

Windows has had a similar problem with UWP (which is based on a rudimentary capability system and implements the file dialog powerbox pattern outlined in mikewarot's post)

iggldiggl 5y ago

> But these restrictions also reflect a substantially limited capacity to innovate They also break already existing applications and workflows – there are e.g. quite a few file formats around that don't work with the "pick a single file and that's all you can access without pestering the user once more" model: - separately stored subtitles (media players currently automatically look for those when opening a video, but with strictly sandboxed file access that would no longer work) - playlists (opening a playlist should likely implicitly allow that application to also access all the files referenced therein, but of course the OS can't be expected to understand each and every filetypes intricacies) - multi-part videos - multi-part archives - HTML documents with links to other documents and/or separately stored resources (media files/CSS/JS) - any other kind of multi-file file format Along the same lines, download manager extensions in Firefox have become semi-useless since the switch to webextensions, because there's no way to download multiple files elsewhere than the OS downloads folder without asking the user for each and every file.