Walsh: Introducing the SELinux Sandbox

If I take it right, you thought I meant that the file is first downloaded to a file that the browser can write to, then when it's finished read that file and pipe it to the other process? If so, that's not really how the system would work as I interpreted it.

How I see it is this: 1.) The browser wants to download a file (either by the user explicitly clicking on the link or via javascript, or whatever)
2.) The browser notifies the download service (also with the recommended filename, as well as the mimetype)
3.) The download service opens the desktop environment's normal file save dialog box
4.) The user decides where to save the file
5.) The download service tells the browser that the download was approved
6.) The browser beings downloading the data from the remote server
7.) The browser writes that data to the pipe to the download service (*not* to a temporary file or anything)
8.) The download service writes that file's data to disk

At no point is the browser having to write data to the disk, all the data is immediately being transferred over the pipe.

For more security, the browser itself could be further broken up into multiple parts, akin to how Chrome is structured... which'd help isolate the X server from the remote data (I'd imagine that the X server would probably be the weak link in this situation), not to mention having the added benefit of one tab not slowing down all the others (at least in an ideal world).