Replace "primordial" terminology with adjective-"intrinsic"
MODIFY
packages/harden/README.md
packages/harden/README.md
@@ -105,16 +105,16 @@ untrustedUser1(newAPI);
untrustedUser2(newAPI);
```
-If `harden()` runs in a [SES](https://github.com/Agoric/SES) environment, all of the "primordials" (the built-in Javascript objects like `Map`, `Number`, `Array`, and so on) are already frozen. In a SES environment, to interact with untrusted code safely according to the API that you've constructed, you just need to `harden()` the objects that you give to other code (and any custom prototypes you might be using). Outside of SES, `harden()` is insecure and should be used for testing only.
+If `harden()` runs in a [SES](https://github.com/Agoric/SES) environment, all of the intrinsics (the built-in Javascript objects like `Map`, `Number`, `Array`, and so on) are already frozen. In a SES environment, to interact with untrusted code safely according to the API that you've constructed, you just need to `harden()` the objects that you give to other code (and any custom prototypes you might be using). Outside of SES, `harden()` is insecure and should be used for testing only.
## MakeHardener and creating a custom harden() function
-The package [`@agoric/make-hardener`](https://www.npmjs.com/package/@agoric/make-hardener) provides a `makeHardener()` which can be used to build your own `harden()` function. `makeHardener` does not know about any specific primordials, and must be passed that information. When you call `makeHardener()`, you give it a set of stopping points, and the recursive property walk will stop its search when it runs into one of these points. The resulting `harden()` will throw an exception if anything it freezes has a prototype that is not already in the set of stopping points (or was frozen during the same call).
+The package [`@agoric/make-hardener`](https://www.npmjs.com/package/@agoric/make-hardener) provides a `makeHardener()` which can be used to build your own `harden()` function. `makeHardener` does not know about any specific intrinsics, and must be passed that information. When you call `makeHardener()`, you give it a set of stopping points, and the recursive property walk will stop its search when it runs into one of these points. The resulting `harden()` will throw an exception if anything it freezes has a prototype that is not already in the set of stopping points (or was frozen during the same call).
The provided harden() function is created by calling makeHardener() on a specific set of stopping points. Thus, makeHardener is bundled (see package-lock.json for the actual version) in this package for ease of use.
-For everyday usage, you probably want to use the `harden()` provided in [SES](https://github.com/Agoric/SES) instead of creating your own. If you want to test your code before using it in SES, you can use this package [@agoric/harden package](https://github.com/Agoric/Harden). (Note that without SES freezing the primordials, `harden()` is insecure, and should be used for testing purposes only.)
+For everyday usage, you probably want to use the `harden()` provided in [SES](https://github.com/Agoric/SES) instead of creating your own. If you want to test your code before using it in SES, you can use this package [@agoric/harden package](https://github.com/Agoric/Harden). (Note that without SES freezing the intrinsics, `harden()` is insecure, and should be used for testing purposes only.)
[circleci-svg]: https://circleci.com/gh/Agoric/harden.svg?style=svg
[circleci-url]: https://circleci.com/gh/Agoric/harden

MODIFY
packages/harden/src/anonIntrinsics.js
packages/harden/src/anonIntrinsics.js
*
* <p>Generally, this file should be run as the first script in a
* JavaScript context (i.e. a browser frame), as it relies on other
- * primordial objects and methods not yet being perturbed.
+ * intrinsic objects and methods not yet being perturbed.
*
* <p>TODO(erights): This file tries to protect itself from some
* post-initialization perturbation by stashing some of the
- * primordials it needs for later use, but this attempt is currently
+ * intrinsics it needs for later use, but this attempt is currently
* incomplete. We need to revisit this when we support Confined-ES5,
- * as a variant of SES in which the primordials are not frozen. See
+ * as a variant of SES in which the intrinsics are not frozen. See
* previous failed attempt at <a
* href="https://codereview.appspot.com/5278046/" >Speeds up
- * WeakMap. Preparing to support unfrozen primordials.</a>. From
+ * WeakMap. Preparing to support unfrozen intrinsics.</a>. From
* analysis of this failed attempt, it seems that the only practical
* way to support CES is by use of two frames, where most of initSES
* runs in a SES frame, and so can avoid worrying about most of these
@@ -75,14 +75,14 @@ function getAnonIntrinsics(global) {
// ////////////// Undeniables and Intrinsics //////////////
/**
- * The undeniables are the primordial objects which are ambiently
+ * The undeniables are the intrinsic objects which are ambiently
* reachable via compositions of strict syntax, primitive wrapping
* (new Object(x)), and prototype navigation (the equivalent of
* Object.getPrototypeOf(x) or x.__proto__). Although we could in
* theory monkey patch primitive wrapping or prototype navigation,
* we won't. Hence, without parsing, the following are undeniable no
- * matter what <i>other</i> monkey patching we do to the primordial
- * environment.
+ * matter what <i>other</i> monkey patching we do to the primal
+ * realm.
*/
// The first element of each undeniableTuple is a string used to
@@ -174,7 +174,7 @@ function getAnonIntrinsics(global) {
* and the instrinsics section of whitelist.js
*
* <p>Unlike getUndeniables(), the result of sampleAnonIntrinsics()
- * does depend on the current state of the primordials, so we must
+ * does depend on the current state of the intrinsics, so we must
* run this again after all other relevant monkey patching is done,
* in order to properly initialize cajaVM.intrinsics
*/

MODIFY
packages/harden/src/buildTable.js
packages/harden/src/buildTable.js
@@ -35,7 +35,7 @@ export default function buildTable(global) {
function addToWhiteTable(rootValue, rootPermit) {
/**
- * The whiteTable should map from each path-accessible primordial
+ * The whiteTable should map from each path-accessible intrinsic
* object to the permit object that describes how it should be
* cleaned.
*
@@ -57,7 +57,7 @@ export default function buildTable(global) {
return;
}
if (whiteTable.has(value)) {
- throw new Error('primordial reachable through multiple paths');
+ throw new Error('intrinsic reachable through multiple paths');
}
whiteTable.set(value, permit);
keys(permit).forEach(name => {

MODIFY
packages/harden/src/whitelist.js
packages/harden/src/whitelist.js
/**
* <p>Each JSON record enumerates the disposition of the properties on
- * some corresponding primordial object, with the root record
+ * some corresponding intrinsic object, with the root record
* representing the global object. For each such record, the values
* associated with its property names can be
* <ul>

MODIFY
packages/lockdown-shim/src/main.js
packages/lockdown-shim/src/main.js
@@ -141,7 +141,7 @@ export function lockdown(options = {}) {
// Circumvent the override mistake.
const detachedProperties = enablePropertyOverrides(intrinsics);
- // Finally register and optionally freeze all the primordials. This
+ // Finally register and optionally freeze all the intrinsics. This
// must be the operation that modifies the intrinsics.
harden(intrinsics, registerOnly);
harden(detachedProperties, registerOnly);

MODIFY
packages/ses/demos/challenge/README.md
packages/ses/demos/challenge/README.md
@@ -26,12 +26,12 @@ the computer.
You provide the attacker's program by pasting its source code into the box
and pressing the Execute button. The attack program is confined in an SES
environment (shared with the defender), which means it is limited to
-``strict`` mode and has access to the usual ECMAScript primordials (Object,
+``strict`` mode and has access to the usual ECMAScript intrinsics (Object,
String, Array, Math, Map, Date (but see below), and so on). But it does not
have access to platform objects (``window``, ``document``, or ``XHR`` on a
web browser, or ``require`` on Node.js).
-In addition to the primordials, the attacker's program gets access to two
+In addition to the intrinsics, the attacker's program gets access to two
endowments: ``guess(code)`` and ``log(message)``. These are provided by the
defender.

MODIFY
packages/ses/docs/secure-coding-guide.md
packages/ses/docs/secure-coding-guide.md
@@ -77,9 +77,9 @@ function writer2(write) {
}
```
-Clearly, safe operation in the face of mutable primordials is nearly
+Clearly, safe operation in the face of mutable intrinsics is nearly
impossible. SES exists to provide a safer environment, in which all
-primordials are **frozen**. All subsequent examples are expected to be run in
+intrinsics are **frozen**. All subsequent examples are expected to be run in
a SES environment (for documentation on how to achieve this, look elsewhere
in this directory).

MODIFY
packages/ses/docs/source/api.md
packages/ses/docs/source/api.md
The main entry point to SES is
`const s = SES.makeSESRootRealm(options)`. This creates a new SES
-"root" Realm, in which all primordials are frozen, all sources of
+"root" Realm, in which all intrinsics are frozen, all sources of
non-determinism are disabled, and all means of escape are blocked off.
The main utility of this new `s` object (which we might call the
@@ -130,7 +130,7 @@ s.evaluate('console.log(4)', { console: newConsole });
Wrapping endowments like this is critical for security, because the
simple approach would reveal an outer-realm object to the confined code,
which it could use to escape confinement by modifying the parent Realm's
-primordials like the `toString()` method on `Object`s:
+intrinsics like the `toString()` method on `Object`s:
function evil() {
const outerObjectPrototype = consoleEndowment.log.__proto__.__proto__;

MODIFY
packages/ses/docs/source/draft-standalone-spec.md
packages/ses/docs/source/draft-standalone-spec.md
@@ -43,9 +43,9 @@ We define the *shared globals* as all the standard shared global
variable bindings defined by the above, i.e., without `Intl` by default,
with `Realm` (see below), without `eval`, without `Function`, without
anything outside the EcmaScript 2018 spec, and with `BigInt`. We define
-the *shared primordials* as all the objects transitively reachable from
+the *shared intrinsics* as all the objects transitively reachable from
the shared globals. Note that no global objects or evaluators are
-reachable from the shared primordials.
+reachable from the shared intrinsics.
## Additions
@@ -85,11 +85,11 @@ would appear as follows.
the property must be absent so that SES code can feature-test for
it.
-2. Freeze all shared primordials. With the above omissions, there is no
- hidden state or ambient authority among the shared primordials, so
- transitive freezing means that the shared primordials are immutable
+2. Freeze all shared intrinsics. With the above omissions, there is no
+ hidden state or ambient authority among the shared intrinsics, so
+ transitive freezing means that the shared intrinsics are immutable
and rom-able. Since no global objects or evaluators are reachable
- from the shared primordials. They can be placed in ROM without the
+ from the shared intrinsics. They can be placed in ROM without the
bookkeeping needed for them to point at any objects not in ROM.
3. For each compartment, create a new global populated by:
@@ -98,7 +98,7 @@ would appear as follows.
- An `eval` function and `Function` constructor that evaluates
code in the scope of that global
- Both this `eval` function and `Function` constructor inherit
- from the shared %FunctionPrototype% primordial.
+ from the shared %FunctionPrototype% intrinsic.
- Each of these `eval` functions is considered an initial eval
function for purposes of determining whether a an expression
in direct-eval syntax is indeed a direct-eval. (The
@@ -107,7 +107,7 @@ would appear as follows.
direct-eval syntax should also be statically rejected with
an early error.)
- `Function.prototype` is initialized to point at the same
- shared %FunctionPrototype% primordial.
+ shared %FunctionPrototype% intrinsic.
- All of these global properties are made non-configurable
non-writable data properties. The new per-global objects (the
eval function and Function constructor) are frozen. Since they
@@ -168,26 +168,26 @@ Full SES, as embedded into EcmaScript, supports running vetted
customization code in a freezable realm prior to freezing it into a SES
realm. Such vetted customization code runs in an environment like that
described above except:
- * The shared primordials are not yet frozen \*
+ * The shared intrinsics are not yet frozen \*
No host objects have been added to the global. Thus the vetted
customizations run fully confined, without access to any external world.
Although the custoimizations run confined, because they can arbitrarily
-mutate the shared primordial state before other code runs, all later
+mutate the shared intrinsic state before other code runs, all later
code is fully vulnerable to these custiomizations. This is why we refer
-to them as *vetted customization code*. Once the shared primordial state
+to them as *vetted customization code*. Once the shared intrinsic state
is transitively frozen, then we can support the standalone SES
environment described above, where compartments are units of protection
between subgraphs of mutually suspicious objects.
An analogy is that vetted customizations are what a shopkeeper does to
their shop in preparation for opening for business. Freezing the
-primordials is the last step before opening the doors and allowing in
+intrinsics is the last step before opening the doors and allowing in
untrusted customers.
In an IoT context, we should associate these two stages with build-time
and runtime. The build-time environment should support more of the
Realms and SES APIs for creating a SES world, that would be absent from
within the standalone SES world they are creating. The freezing of the
-primordials is the snapshotting of the post-constomization primordial
+intrinsics is the snapshotting of the post-constomization intrinsic
state for transfer to ROM.

MODIFY
packages/ses/docs/source/draft-standalone-spec.rst
packages/ses/docs/source/draft-standalone-spec.rst
@@ -39,9 +39,9 @@ We define the *shared globals* as all the standard shared global
variable bindings defined by the above, i.e., without ``Intl`` by
default, with ``Realm`` (see below), without ``eval``, without
``Function``, without anything outside the EcmaScript 2018 spec, and
-with ``BigInt``. We define the *shared primordials* as all the objects
+with ``BigInt``. We define the *shared intrinsics* as all the objects
transitively reachable from the shared globals. Note that no global
-objects or evaluators are reachable from the shared primordials.
+objects or evaluators are reachable from the shared intrinsics.
Additions
---------
@@ -82,11 +82,11 @@ would appear as follows.
realms. On platforms that do not support ``Realm.makeRootRealm``, the
property must be absent so that SES code can feature-test for it.
-2. Freeze all shared primordials. With the above omissions, there is no
- hidden state or ambient authority among the shared primordials, so
- transitive freezing means that the shared primordials are immutable
+2. Freeze all shared intrinsics. With the above omissions, there is no
+ hidden state or ambient authority among the shared intrinsics, so
+ transitive freezing means that the shared intrinsics are immutable
and rom-able. Since no global objects or evaluators are reachable
- from the shared primordials. They can be placed in ROM without the
+ from the shared intrinsics. They can be placed in ROM without the
bookkeeping needed for them to point at any objects not in ROM.
3. For each compartment, create a new global populated by:
@@ -95,7 +95,7 @@ would appear as follows.
code in the scope of that global
- Both this ``eval`` function and ``Function`` constructor
- inherit from the shared %FunctionPrototype% primordial.
+ inherit from the shared %FunctionPrototype% intrinsic.
- Each of these ``eval`` functions is considered an initial eval
function for purposes of determining whether a an expression in
direct-eval syntax is indeed a direct-eval. (The direct-eval
@@ -103,7 +103,7 @@ would appear as follows.
is low priority. When omitted, the direct-eval syntax should
also be statically rejected with an early error.)
- ``Function.prototype`` is initialized to point at the same
- shared %FunctionPrototype% primordial.
+ shared %FunctionPrototype% intrinsic.
- All of these global properties are made non-configurable
non-writable data properties. The new per-global objects (the eval
@@ -155,26 +155,26 @@ Stage Separated SES
Full SES, as embedded into EcmaScript, supports running vetted
customization code in a freezable realm prior to freezing it into a SES
realm. Such vetted customization code runs in an environment like that
-described above except: \* The shared primordials are not yet frozen \*
+described above except: \* The shared intrinsics are not yet frozen \*
No host objects have been added to the global. Thus the vetted
customizations run fully confined, without access to any external world.
Although the custoimizations run confined, because they can arbitrarily
-mutate the shared primordial state before other code runs, all later
+mutate the shared intrinsic state before other code runs, all later
code is fully vulnerable to these custiomizations. This is why we refer
-to them as *vetted customization code*. Once the shared primordial state
+to them as *vetted customization code*. Once the shared intrinsic state
is transitively frozen, then we can support the standalone SES
environment described above, where compartments are units of protection
between subgraphs of mutually suspicious objects.
A analogy is that vetted customizations are what a shopkeeper does to
their shop in preparation for opening for business. Freezing the
-primordials is the last step before opening the doors and allowing in
+intrinsics is the last step before opening the doors and allowing in
untrusted customers.
In an IoT context, we should associate these two stages with build-time
and runtime. The build-time environment should support more of the
Realms and SES APIs for creating a SES world, that would be absent from
within the standalone SES world they are creating. The freezing of the
-primordials is the snapshotting of the post-constomization primordial
+intrinsics is the snapshotting of the post-constomization intrinsic
state for transfer to ROM.

Replace "primordial" terminology with adjective-"intrinsic" (#199)