security through instruction restrictions:

3.19: adda/exceptions/security through instruction restrictions:
. my style of exceptions has been
having the raiser call the caller's handler;
but, if the caller's code can be corrupted,
then the exception raiser could be exploited .
. it's fun to think about a perfect language,
one that's not corruptable;
but it's safer to have layers of security,
and not depend on a perfect language system .
. say the exception raiser is in ROM
(as it is a library routine)
but the exception handler has a jump instruction
that bypasses a safety guard;
what could save us is a VM that knows when it is
inside an exception handler,
and never executes a jump in such situations .

extending the const-var architecture

3.31: addm/extending the const-var architecture:
. what I'm calling the constant-var architecture
makes use of hardware isolation mechanisms
by safely dividing the system into
constant code, and variable data .
. there is another segment to consider:
# write-once-read-many:
. what's variable across process instances
can be constant during execution .
# special permissions:
. the implied permission is that the
data in the process belongs to that process .
. the activation record's resource display
is an example of special permissions:
the process has permission only to
read the resource display, not write to it;
but the supervisor can modify it .

privacy assurance while reporting errors

3.19: addx/privacy rights/reporting errors:
. if an error should be reported to the coder
the report should be generated in such a way that
the user can see it contains no personal data;
or, it should say it does contain data
and ask if it is too sensitive .