combined hardware-virtual isolation

addm/security/combined hardware-virtual isolation:
2.9: 3.31: intro:

. certain attributes of data are essential to security;
eg, by retagging arbitrary data so that it is
usable as a pointer to code,
we can treat malware data as instructions to follow .
. generally all data can be tagged
just as it is done by xml .

. there are 2 possible ways to enforce
process isolation and ROM attributes:
# HW (hardware) mem'mgt,
# VM (virtual machine) mem'mgt .
. hardware mem'mgt can enforce VM mem'mgt:
the VM's run-time exec never needs to change;
so, HW mem'mgt can see that code as const;
also, any file that the VM is trying to interpret
can be treated by the HW mem'mgt as
something that only the VM process can modify .
. finally, the VM has its own process space
and this should keep other processes
from corrupting its work space .

obj' messaging to clarify what's functional

7.28: adda/function/
oop's obj' messaging as a syntax for inout params:
[8.8: 8.16: intro:
. the usual way to manage objects is to
define their interface with a datatype declaration;
eg, t.type: ( ... ) -- that interface can include
both subprograms ( f( x.t ) )
and obj'messages  ( x'f ).
. up to now, that interface declaration
was the only place where we could
define obj'messages;
whereas, subprogram could be defined anywhere:
. there are various declare blocks
( package, record, subprogram, etc).
that can instantiate objects of type t;
eg, (.int:  ... )
-- that's a block that returns an integer;
and, anywhere an object can be declared,
we can also declare subprograms that are
local to the current declare block .]

declare blocks can declare obj'messaging:
. obj'messaging can be seen as
a special style of parameter,
where f(inout x) is instead written as ( x`f ).
. in the context of a type declaration,
( x`f ) is declared simply as ( `f );
because, x is assumed to be
any of the datatype's instantiations;
so, we know what x's type is,
but in a subprogram's declaration of ( x`f )
x's type would not be known;
so, the sub's declaration
would look like this: ( (x.type)`f );
and, a generalization of this would be
(x.type1, y.type2, etc)`f
which is useful for making it obvious that
x,y,etc are all inout parameters;
then we can reserve the syntax ( f(x) )
for functional uses of x,
ie, where ( f ) is not modifying x
nor modifying anything x can access;
ie, if you want to pass a pointer, p,
for the purposes of modifying p's target,
then the needed syntax is p`f, not f(p).

Mac gets some optional Sandboxing

6.2: news.cyb/dev.mac/sandboxes
Apple brings sandboxing to the desktop:

. most PCs have not been into sandboxing
[because backward compatability was an issue;
smartphone platforms are more recent inventions,
so sandboxing is an obvious good .]
. to access resources within a sandbox,
apps must request “entitlements” [aka, capabilities.]
Android apps must ask the user for permissions
and then the OS constrains the app
to the allowed permissions .
[ but Android apps may be all-or-nothing:
either the user accepts all the requests,
or else the app fails to be usable at all .]
Apple’s iOS sandboxing doesn’t involve the user,
as all permissions are handled by
Apple's App Store evaluators .

[7.25:. in order to be accepted into the app store,
developers must divide their app into modules
so as to more easily explain why each part
needs a particular set of entitlements .][7.20:
Apple decides for the user,
what entitlements are appropriate,
not only for the whole app,
but more smartly, for each of its modules .]

. iOS users can still control certain entitlements:
(eg, opening a list of recent files
or saving documents elsewhere in the file system).

Concerns from Developers:

# no more AppleScript:

[7.20:
AppleScript is a programming language
meant to allow the user to reuse apps
by having scripts make calls to apps .
. if an app wants to reuse other apps,
then it too can use AppleScript
to make calls to other apps;
however, in sandboxing this can't be done,
because,
when an app is entitled to AppleScript
it's entitled to anything AppleScript can do
-- which is basically anything!
. if apps are instead designed to be
reused directly by other apps
then sandboxed apps can still be
entitled to use particular other apps
without having to give them access to
the wide world of AppleScript .]

# no more file system management: [7.20:

. Apple sandboxing asks the user
for each and every file access;
so, apps that need access to many files
or that need to work in the background
are not considered sandboxable;

nevertheless, sandboxing of the file system
could work like vmware's shared folders:
. vmware lets you run an OS in a sandbox
as a virtual machine (vm);
and then gives the vm {read, write} access
to just the folders the user requests
(Virtualbox has a similar feature).
. you can divide your file system by sensitivity levels;
eg, if the sandboxed app has access to the web,
then give it entitlements should be
read-only access to non-sensitives,
and write access to a downloads folder .
. letting sandboxes share folders
is important to generativity .]

. see Jonathan Zittrain's Chapter 7 of
The Future of the Internet and How to Stop It .

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 .