Sharing data and interopability between applications is a hard problem, but Apple is on the right track. In any case, starting out with something with sound fundamentals and then improving usability is a much better approach than starting with something that is fundamentally broken and adding kludges to make it more secure.

That may be a roadblock but the primary reason why smartphones are relatively unproductive is because a touch only interface has the disadvantage that you can only interact with things that are visible on the screen. When your screen is less than 7" big and 30% of that space is wasted by a virtual keyboard then the only way to design a UI for a smartphone is to have as few interactions as possible, otherwise we end up having to constantly scroll up and down. The end result is that a lot of apps are hiding core functionality behind the hamburger icon.

copy paste already works wonder to share pictures and the like between multiple programs on iOS at least, one can easily extend the pattern in a desktop environment and even add more entry point as long as they are user initiated, kind of like you can access the clipboard in browser only if it's on the stack of a user initiated event.

How do I type

    for src in $(find . -type '*.png')
    do
        sdir="$(echo "${src}" | dirname)"
        name="$(echo "${src}" | basename)"
        dstdir="/mnt/www/images/${sdir}"

        optipng -out "${dstdir}/${name}" "${src}"
        convert -scale 120x120\> "${src}" "${dstdir}/small_${name}"
    done

into a GUI's "copy paste" feature?

You don't there are plenty better ways to list and filter files check out how beos did it.

You could do literally the same and you didn't even need to drop to the console.

you long press the f for the terminal window to start hilighting text, and drag it to the e in done, and then choose copy.

This is my biggest pet peeve with iOS. That and the way background services act. Why can't I have an app that syncs my photos to my server run at night without the location hack? Ugh.

There ought to be a system level API that a program may call to get to read or write a user supplied file.

Opening any random file should be reserved to just a few core applications.

Its called Mandatory Access Control. It has existed for over a decade in the mainline kernel. Ubutnu, Fedora, Suse - everyone but Arch, pretty much - supports one of its implementations.

The problem is more that I do not believe any distro is shipping a default-deny policy. Unknown programs are simply given the kitchen sink rather than having, say, user friendly prompts saying "this program has no access control and wants to open X or use Y, allow?"

But we definitely have the technology, and it does not take any heavy overhead isolation to do it.

> everyone but Arch

Arch has a grsec kernel in the repos if you want one...

And nobody maintains prebaked PaX profiles for Arch, which makes the MAC part much less effective as a security feature.

There are two ways to do MAC - applications (or the distro) provides the profiles, that restrict execution to just what the program will use, and if it ever asks for anything else it should be suspect for exploitation. The other one is where you put your programs in learning mode, and that only hardens you against future exploits, not current ones, and you also lose the protection against untrusted software because by default everything is untrusted and you must trust everything on a case by case basis.

It's not that simple, and it's easy to misdesign such API.

Say, VLC team had argued that a video player may need to open a supplementary subtitle file. If application can be only granted access to a single video file - that's impossible. I think there were other examples, but I don't remember those off-hand.

Filesystems are trees. VOX could have read access to a particular tree (~/Videos) and no access to everything else, including but not limited to ~/Documents/Finance

But what if I want to watch ~/Downloads/big_buck_bunny.mkv?

Explicitly mark it as available by moving / hardlinking it to ~/Videos.

It's certainly not simple. This is a big UX problem, but one worth solving.

This is actually how it is implemented in OSX. If a sandboxed app shows a 'file open' panel then it automatically obtains the rights to read and write to any file selected (the open panel, or 'powerbox' as it is called, is implemented in a separate process so cannot be manipulated by the app). An app can also request a secure 'bookmark' to this file so it can persist file references.