[Interest] Qt 5 and Mac App Store

[Till Oliver Knoll]

Am 19.10.2012 um 18:20 schrieb Daniel Price <daniel.price at fxhome.com>:

> 
>> Ah, okay then, but still: if your application *wanted* to be malicious and, say, delete the file the user has such selected via file dialog, ...
> 
> Hmm I'm pretty sure that sandboxing is there to prevent *you* from doing thing's not you're supposed to do. Preventing another malicious app from pretending to be your app is what code-signing is for.

Preventing another app to "impersonate" your app, as to do malicious things with the rights of the user account, that's done by code-signing, absolutely correct.

However it is important to realise that when you say "the sandbox is there to prevent *you* from things you're not supposed to do" that you *deliberately* waive these rights! Well, at least some of those anyway, other restrictions are in fact enforced.

That's a subtle but important difference when asking "what is a sandbox good for?" (and let's forget for a moment that Apple only accepts sandboxed apps in their store):

A sandbox does not enforce or control those restrictions such that *your* code (process) doesn't do any harm. As I mentioned previously even a sandboxed application could do considerable harm to the user's files, or e.g. read the address book (with the consent of the user) and send it over the network.

So this is *not* the scenario a sandbox tries to prevent (your app is simply assumed to be good!). What the sandbox tries to prevent is when your application gets exploited by a *security hole* and malicious. So in order to prevent the above "address book stealing" scenario you would split your application into two processes: the one has a network privilege (but cannot access the address book or read/write the filesystem), the other process can read the address book, but cannot access the network.

Now in order to exploit a security hole it would be necessary to corrupt *two* processes - a magnitude harder than finding a security hole in a single process.

So again: the goal of sandboxing an application is not to protect the system from that application (it could still do considerable harm with the consent of the user). That is (should) be already validated by trusting that application in the first place (known source where the app comes from, app store tests, other user's feedback, ...). It is another line in the defense in case your app exhibits *a security hole*!

Off course that *does* come with necessary restrictions. You must not call Apple Script of another process, for instance. Allowing that would otherwise render sandboxing ad absurdum.

So yes, some kinds of applications are simply not "comparible" with any sandboxing concept. That's a fact. But for most applications it simply means some extra effort for development - splitting up the application into different processes, inventing a comminication protocol etc. - and you still get the same functionality.

> ...
> 
> And that, is why SourceTree was pulled from the store. As source-control client, it needed read and write access to files that the they user hadn't specifically selected via a dialog. This is the show-stopper I mentioned.

One (or rather: Apple) could argue that the App Store is meant for "end users" only, and they never need sophisticated developer tools (which access files "behind the back" of a user).

And seeing how my mother manages to completely mess up with her files I tend to think that it is probably a good thing to "shield" those users from "complicated apps".

Now there's us "power users", "developers", "people who know what they're doing" etc.

Those are the users that know how to get the software by other means anyway. 

Time will show if and when more "complex" apps will become possible. For instance a user could select a directory and the app was allowed to read any file therein (and in subdirectories). Then an app like SourceTree would become possible again (I for my part have all my sources under a common "work" directory, so that would clearly be an increase in security, also for me as a developer, knowing that this SourceTree could only access those files therein).

Oh well, wait, that's already possible, I just checked the Apple docs: the user *can*specify a directory and "in response, the system makes the folder, it's contents, and its subfolders available to your app."

I don't know that SourceTree app and why exactly it was pulled from the store, but the way you described it (and how I imagine what that app does) I imagine a simple first setup step "Specify your folder where your sources are located" would have solved the issue. I don't see why a simple "source control system" should have any access to other files (and again, not because I don't trust that application - but in case it got corrupted!).

> When you create a Cocoa app, you get a recent files menu for free in the MainWindow.nib. I suspect that there is some special-casing going on with that menu that we cannot reproduce outside of Cocoa.

That's not true: that implementation uses the exact same "URL Security Scoping" API, which yes, happens to be an API of NSURL class. Alternatively you can use the corresponding Core Foundation API which happens to be a plain C API, if I am not mistaken.

So I don't quite understand what you mean by "I suspect that there is some special-casing going on with that menu that we cannot reproduce outside of Cocoa."


> 
>> However I also remember having read about "Document security scoped URLs", that is if the user opens a document (a file), and that document refers to other files (say jpeg photos stored alongside with that document), then there is an API which also lets you "security-scope" those files alongside - even though the user has never explicitly openened them via file dialog, the application is still allowed to read them the next time.
> 
> Yes that should work because they're in the same directory. Directories are just entities on disk.

Hmmm, not sure whether we are talking about the same feature here:

Apple provides two concepts:

* app-scoped bookmarks (where the user selects a file or directory)

* document-scoped bookmarks

I was referring to the later here.


But getting on topic again: unless Qt provides an API which would stop working in a sandbox I don't see why Qt should be bothered.

For instance Qt does /not/ yet provide a QRecentFiles API (which would stop working when sandboxed). Qt now works flawlessly togethet with the "powerboxed file dialog" (so also QFile works out of the box, if given a filepath which was opened via file dialog).

Given that it might be useful to have a "app-scope that file" flag in the QFile API. That Security-Scoped URL would then have to be stored and retreived again from somewhere (where? User config file which has to be specified previously?). Details to be elaborated :)

Cheers,
  Oliver