Re: Fwd: Fwd: Draft Proposed Standard SES (Secure EcmaScript)

On Mon, Mar 21, 2016 at 11:11 AM, Mark S. Miller <[email protected]> wrote:

> Hi Matt, thanks for reminding me of that! As a result, I have added a short
> summary section at the beginning of https://github.com/FUDCo/ses-realm ,
> using that example to explain the difference between the "offensive code
> problem" (which confinement addresses) and the "defensive code problem"
> which this document had not adequately explained. Please have a look.

"Reflect.confine(src, endowments) makes a new SES realm in the same
way, copies the endowments onto its global, and then evaluates src in
that realm, returning the result."

I would add something to the effect of

returning the result, at the point of return the caller receives sole
ownership of the result and the discretion for its propagation.

to set the stage for the paragraph in the background section

"With these familiar restrictions we can guarantee that the only way
for one object to come to possess a reference to a second object is
for them to have been given that reference by somebody else"...


>> so say if I wanted a Diary object which contains alice/bob/carols
>> secrets, and ensures the separation of those secrets, you need to
>> evaluate this source multiple times?
>
>
> Depends who "I" and "you" are. In the standard scenario Alice sets up the
> situation by loading/evaluating Bob and Carol. Alice trusts herself, so even
> without auditors, Alice might trust that this counter code is defensive and
> provides no more communications opportunity than she intends. Since Bob and
> Carol are loaded by Alice, they are necessarily fully vulnerable to Alice.
> If nothing else, Alice could rewrite their code before evaluating "them". So
> it is not very meaningful for them to be suspicious of Alice. However, Alice
> can be suspicious of them and they can be suspicious of each other.


To clarify my intent it was to lead up to the compartments example
showing a case where constant source object and parameters with
different reachability, where the source object is useful but of
unknown defensiveness, then contrast two variations before adding
revocation.

friends.map(function (friendSrc) {
  // friendSrc's each get their own isolated diarySource
  Reflect.confine(friendSrc, Reflect.confine(diarySource, {}));
})

if her intent is to keep her friends diary objects isolated it would
be inadequate for Alice to pass her friends a reference returned
through a single invocation of Reflect.confine
since it does not achieve her reachability goals.

sharedGroupDiary = Reflect.confine(diarySource, {});
friends.map(function (friendSrc) {
  // since sharedGroupDiary is held in common, it and anything deriving from it
  // can act as a bridge between the otherwise isolated sub programs.
  Reflect.confine(friendSrc, sharedGroupDiary);
}