Strawman: Module Keys
On Wed, Feb 28, 2018 at 4:00 AM, <es-discuss-request at mozilla.org> wrote:
From: Mike Samuel <mikesamuel at gmail.com>I'm looking for other criticism of mikesamuel/tc39-module-keys and for interested parties who might have time to refine it.
I'm just taking a bit of time to read over it. Keep in mind, I'm no security expert.
In the spec, you write,
We use the name frenemies below. This is a terrible name.
I suggest "counterparties". www.investopedia.com/terms/c/counterparty.asp
What's a Box? (I'm serious. You really don't define what it is in this context.) You also talk about boxed values and unboxed values, but I may have missed the paragraphs explaining the difference.
In your example code sections, you imply these properties are directly named as properties of alice and bob, respectively... do we want all of those as such, or maybe under a namespace (alice[someNameOrSymbol].publicKey)? Particularly with such generic names as box and unbox... I'd feel more comfortable if they were under a predefined Symbol.MODULE_KEYS namespace.
That's my two cents - and they're worth exactly that much after inflation. :-)
Alex
On Fri, Mar 2, 2018 at 8:29 PM, Alex Vincent <ajvincent at gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:00 AM, <es-discuss-request at mozilla.org> wrote:
From: Mike Samuel <mikesamuel at gmail.com>I'm looking for other criticism of mikesamuel/tc39-module-keys and for interested parties who might have time to refine it.
I'm just taking a bit of time to read over it. Keep in mind, I'm no security expert.
Thanks for giving it a read.
In the spec, you write,
We use the name frenemies below. This is a terrible name.
I suggest "counterparties". www.investopedia.com terms/c/counterparty.asp
What's a Box? (I'm serious. You really don't define what it is in this context.) You also talk about boxed values and unboxed values, but I may have missed the paragraphs explaining the difference.
Good point. A "box" is an instance of class Box.
The important thing about Boxes is that if frenemies0 and frenemies1 are
outputs from makeFrenemies then
value === frenemies0.unbox(
frenemies1.box(value, (k) => true),
(k) => true)
so the unbox function reverses the box function when things are permissive.
Where this becomes useful is when we use a predicate less permissive than (k => true).
The value associated with a box can only be accessed if both the box caller and the unbox caller agree.
value === frenemies0.unbox(
frenemies1.box(value, (k) => k === frenemies0.publicKey && k()),
(k) => k === frenemies1.publicKey && k())
Public keys can be passed to predicates. The private key is used within unbox to ensure that the public key only returns true when checked on behalf of the module that owns it.
The first ((k) => ...) predicate lets frenemies1 ensure that only
frenemies0.unbox can open the value. The second predicate lets frenemies0 ensure that the box came from frenemies1
In your example code sections, you imply these properties are directly named as properties of alice and bob, respectively... do we want all of those as such, or maybe under a namespace (alice[someNameOrSymbol].publicKey)? Particularly with such generic names as box and unbox... I'd feel more comfortable if they were under a predefined Symbol.MODULE_KEYS namespace.
The only frenemies property that is implicitly exported is publicKey. Having a well-known symbol for the public key seems reasonable.
I'm looking for other criticism of mikesamuel/tc39-module-keys and for interested parties who might have time to refine it.
This adds public/private key analogues to ModuleBodies along with some associated operators.
As background, we on Google's security engineering group have had a lot of success hooking into build systems, linkers and using static analyzers to identify problematic code patterns, guide developers towards safe ones, and make sure we find out about things that we want to know about. This has let a small group of security engineers manage the security of a much larger group of application developers without us-vs-them dynamics.
I hope that some machinery like this might enable similar dynamics within open-source projects that don't have monolithic code repos.