>> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose.

> This is not enough, as explained above.

If the file chooser is powerful enough, couldn't it be?

I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as I'm concerned.

>> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. >This is not enough, as explained above.

Well, its hard to say that as this kind of stuff is not designed yet. Better to say that the requirements of VLC on the design of this are more complex than just the "allow access to single-picked-file" semantics. Hopefully we can take this into account when we look into the details here.

> Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know.

Some of these need not necessarily be as complex as you imagine though. They could very well be some kind of thin service that enumerates the real devices and hands over the opened FD to your app after having verified that it is allowed.

> libpulse requires X, as far as I know.

Libpulse can optionally be built with X, but this is really only used to read back the pulse socket name from the x root property. It works just fine without X (witness the non-X, but pulseaudio using demo in the blog post for instance).

OpenGL access is via DRI, but yeah, output to the screen will have to happen via wayland. That could use subsurfaces with YUV surfaces, and it is then up to the compositor to use overlays if possible (i know weston does this for instance).

For VDPAU etc, i don't really know.

> I'm making sure the same does not happen on Linux, before we get kicked out of our own platform.

To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This sandboxing (together with other bits) would allow you to distribute your application eventually 80% of the various Linux distribution users. I think it'll take some time because there's a lot of things to work out (e.g. relying on Wayland, kdbus, change Pulseaudio to use kdbus, etc).

A user should have control on what an application can do, but that's something new and user might highly prefer such applications (e.g. not allowing an application to just modify ~/.bashrc and adding some evil sudo alias if it feels like it).

IMO at most you'd have some package software which shows for VLC: "unrestricted access". The intention is to offer more security where possible to the user while at the same time it's not too difficult for the developer.

Yeah, the possibility of a "gatekeeper effect" is what's worrisome here. There's no way you can anticipate everything a user might want to do with their computer, so while opt-in sandboxing can only help, mandatory sandboxing could stifle the creativity of developers who must go through a gatekeeper (even a benevolent one) any time they want to ship a program that uses hardware or software abstractions in some unforeseen way.

Or alternatively, Joe User goes "[grumble grumble] guess I gotta delete that dang PulsePolicyD that's keepin' me from runnin' muh binaries [copies and pastes the first command found when googling "how i run X" into shell]" and it's all for naught.