81–90 of 234 posts
Earlier quoted context omitted.
AFAIK, fonts aren't a passive format, they contain code which executes in a VM.
At least SRT files are a purely declarative sequence of lines with "time time text".
Earlier quoted context omitted.
Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an application like VLC, in the current way of doing sandboxing, which we've done for macOS, WinRT/UWP, and snaps, you still need a lot of permissions. Namely: - you need to be able to open files without user interactions (no file picker), in order to open playlist,…
You actually don't NEED a lot of these things I'm perfectly fine with a default / embedded font. I don't have an optical drive A database can be in the local app storage. I'm fine opening a subtitle file myself. Why would I need IPC? Why would I need to unzip anything? If it's subtitle files, it can be done in-memory. Are you sure we need low-level audio? I don't have a remote, so I'd like it to be disabled by defaul…
> I don't need any access to the network.
90+% of what I use it for comes from my NAS or the Internet.
> I don't have an optical drive
Most of the rest is from optical discs.
> I'm perfectly fine with a default / embedded font. [...] I'm fine opening a subtitle file myself.
It's _fine_ but far from ideal. Both are useful quality of life features.
> Why would I need to unzip anything?
Non-essential, but being able to play video from a ZIP is a useful feature.
Earlier quoted context omitted.
Sure, but then you need a multi-process sandbox, and it's not easy to do. And the performance is not easy to obtain.
You can co-opt Chromium's. I've been doing that with a project I'm working on and it has worked quite well. I'm also not sure where you'd lose much performance. If you hand the file handles/sockets and backbuffer to the renderer, you only need enough IPC to synchronize the drawing. Sending small messages on the order of 100 times per second between processes is not going to be a bottleneck.
It is not easy. If it was, people would have done it already.
Earlier quoted context omitted.
A media player is rarely that simple. Before writing to the GPU you have to access the content (file, network), demux, then decode and finally display. The most dangerous areas are the demuxers and decoders so they have to be sandboxed. So yes, you're right, but this doesn't solve the problem of moving the buffers between processes.
You can share file handles/sockets on Windows/OSX/Linux via IPC without giving the renderer process the ability to open the files/sockets themselves.
Earlier quoted context omitted.
Ha, the famous sandboxing remark. I wish it was that simple! So, let me share some light on the sandboxing for multimedia (I work on VLC). If you sandbox an application like VLC, in the current way of doing sandboxing, which we've done for macOS, WinRT/UWP, and snaps, you still need a lot of permissions. Namely: - you need to be able to open files without user interactions (no file picker), in order to open playlist,…
> Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. That's not actually how Chrome's renderer sandboxing works. Both Windows and OS X allow you to share a GPU-resident texture between processes (DXGI shared surfaces and IOSurface respectively),…
The last part is just one of the issues, very far from all of them.
Seriously, stop thinking that noone has given a thought to the question...
Was annoying to find the details. Looks like PopcornTime was rendering subtitle text as HTML, inside their app (html/js-based), creating an XSS vector (looking at https://github.com/popcorn-official/popcorn-desktop/commit/a... , https://github.com/butterproject/butter-desktop/pull/602 ). Likely the javascript runtime they're using allows file access and execution of arbitrary executables, enabling the metasploit shel…
does this work on Linux and Mac OS? or is it limited to Windows systems?
Earlier quoted context omitted.
No, you can use a shared memory segment for a buffer just for that. It's more coding, certainly, but it's possible. Security is an option if we wanted it.
That's exactly the point above. See my above comment.
The shared memory segment can be a GPU image buffer, so I don't think that's true.
Earlier quoted context omitted.
You can co-opt Chromium's. I've been doing that with a project I'm working on and it has worked quite well. I'm also not sure where you'd lose much performance. If you hand the file handles/sockets and backbuffer to the renderer, you only need enough IPC to synchronize the drawing. Sending small messages on the order of 100 times per second between processes is not going to be a bottleneck.
But you need to pass data from the access to the stream_filter, from the stream_filter to the demuxer, from the demuxer to several decoders, from the decoders to potentially a few video-filters and chroma-converters, and then finally to the output. Each of them need different access policies, and several of them require FS access. It is not easy. If it was, people would have done it already.
Do any of those components need unrestricted/unpredictable file access? Because if they don't you can just open the files in the main process that handles the UI and send them to the sandboxed process via IPC. None of Windows/OSX/Linux do permission checks when file handles are read from, they only check when the file is initially opened.