taming shims could be applied multiple times

[warner]

When one SES Realm creates another one, they don't coordinate on the taming shims, so we might end up applying the shims multiple times. This gets worse if we have very deeply nested realms.

We sketched out a design to avoid this (known as SES.powers, named after the object that would keep a bitmap or set of remaining untamed power, which would be populated by the parent SES realm and gets smaller with each new layer of attenuation), but decided not to implement it, because:

• our shims really ought to be idempotent anyways, so applying them multiple times merely affects performance, not correctness
• to maintain overtly-transparent virtualization, there should be no "normal" way for the confined code to determine what constraints have been placed upon it. (In a mobile OS scenario, the owner of a phone should be able to instruct the OS to lie to apps about their geolocation or time or whatever, and the app should not be able to ask the OS whether it is being lied to or not.. imagine something similar but for SES authorities)
• SES is designed to host multiple mutually-suspicious objects anyways, so we aren't likely to have deeply nested realms. We might have two (an outer one with more IO authority, in which you create the Powerbox and whatever IO abstractions you need, where all the code comes from the trusted platform and we just run it in a SES realm so that the objects it creates are safe to pass inwards, and an inner one where all the untrusted code runs). But in general you'll get to a fully-confined SES realm pretty quickly, and once you're there, there is no need to create any further realms. So the O(N) nature of the shims isn't really an issue, since N won't ever be more than 2.
• if an SES realm creates a normal Realm, then that normal Realm creates a SES Realm, then there's no good place to pass the data through to the grandchild. There's a question of how the intermediate realm gets the code to create an SES realm, but we're going to have an answer for module loading eventually, and we can imagine the SES code being a pure module that gets passed in as just a string.

This issue exists just to capture our thoughts on this.. we can probably close it.

[jfparadis]

Shims are no longer handled by SES itself. Closing.