scriptability with sandboxing

6.30: addx/scriptability with sandboxing:

. I was surprised to learn that Preview
-- one of Apple's own apps -- is unscriptable;
but, perhaps that's because it's so costly to produce
the needed scripting dictionary .
. one of addx's motivating features
was the pervasive use of the MVC pattern;
with that in place, app's always come in 2 parts:
# the model that can talk to any controller
(because it's a command line tool);
# the gui controller that humans will need
in order to interact with the model .
. the scripting dictionary comes free
(without the developer having to do anything)
because in order to get an app installed in the system
it had to be submitted to the system librarian,
who put the model's specification in the library
which is viewable by humans and controllers alike .


. the other issue that article made me aware of
was how process sandboxing works when there are
inter-process communications (scripting).
. when apps can use other apps,
then there are 2 dimensions to trustworthiness:
# can the app be trusted to
always to do the smart thing? vs,
# is the app a trusted tool
but only in the hands of a trustworthy user ?
. eg,
when you give your textEditor
rights to modify all files,
you're intuitively granting that access
only to the human user, not the app .
. what you trust about the app itself,
is that it will do exactly what it's told .

. when allowing possible malware
to be the controller of a TrustedApp
then we're expecting TrustedApp to be smart:
to be limiting its controllers
in order to protect all other interested parties
(human users, the system, copyright agreements, etc).

. before systems started using sandboxes,
it was assumed an app inherits the user's privileges;
sandboxing means the app can inherit less,
(or more,  if it has admin privileges);
so, when an app is getting sandboxed,
it is making 2 lists of requested capabilities:
# things it needs that are not controlled by users;
# things it may need if users can access them .