2012-07-04

can a scripting engine really be safe?

6.1: addx/can a scripting engine really be safe?:

. I just heard that Apple will no longer allow apps to
communicate by sending each other AppleScripts;
instead they need to use each other's API .
. this I found confusing because I had a different understanding
of applescript connectivity:
. apps exported an API that applescript could understand,
and then applescripts could use all such apps .
. I guess what they were saying is that, counterintuitively,
only AppleScript had been able to use such API's:
you couldn't do so from the native lang (objective C).
. anyway, this got me to asking the question:
can a scripting engine really be safe?
here's my yes:

. given a sufficiently descriptive capabilities definition,
the user could understand each program's effect
in terms of {read, write, modify, append}'s
affecting {specific folders, specific internet sites}.
7.4: 6.1:
. rather than burden the user with
such cap'base security decisions
Apple has developer programs that are paid to inspect your app
(where they can weed out obviously stupid capability requests).
6.3:
. one problem I have with the app store security model
is it doesn't give budding programmers a chance to
program their device on their device
-- that is the sole mission of the addx project,
but addx want's the same level of security as Apple,
so addx needs to show that cap'based security
is just as good as the app store .
. once you give user's access to run their own code,
they will inevitably become socially engineered to
run other's code too,
so the whole scripting engine needs to be user-sandboxed
such that instead of having a particular effect,
the arbitrary code is making a number of
capability requests,
and then the scripting engine is fullfilling these requests
only if the user's capabilities preferences are ok'ing it .
. the main problem Apple is having though,
is that they have to protect more than the user;
they also have to protect the system from the users
-- users who tend to hack phone systems
and violate the intellectual property rights of others .
. in the case of IP rights, for example,
addx would have to recognize copyrighted audio sources
and prevent users from copying the audio stream
whenever it included a copyrighted source; [7.4:
or allow copying only as some lower-quality version,
one that is good for identifying a song
(eg, for logging one's experience),
but not good for resale .]

No comments:

Post a Comment