Why we still fail to endow liveSlots

[erights]

endo/packages/compartment-mapper/src/policy.js

Line 31 in 59b756e

list = keys(from);

Uses Object.keys which only includes string-named properties.

My first thought is to change it to Reflect.ownKeys, but this includes non-enumerable properties as well. What did we decide was correct in general for these global endowments? Should we change to Reflect.ownKeys and then filter out non-enumerables? Or should we just use Reflect.ownKeys?

[kriskowal]

We agreed that the goal state would be for the globals to use the semantics of Object.assign except that all properties would be non-enumerable by default, and to leave a door open for globalProperties which would be copied by the semantics of Object.getOwnPropertyDescriptors and Object.defineProperties. We were content to omit a globalProperties option from Compartment since the behavior is allowed with direct manipulation of compartment.globalThis, but the compartment mapper would need one for those semantics. We also agreed to leave open the possibility of a parallel design for inescapableGlobals and inescapableGlobalProperties on the Compartment constructor.

[erights]

So concretely, this specific line should do Reflect.ownKeys and then filter out the non-enumerables, in order to be consistent with Object.assign behavior?

[erights]

Btw, even with this line corrected, we're still failing to endow passStyleOf. Still tracking that down. Attn @warner

[kriskowal]

I am open to relitigating. I would be fine with a proposal that all owned, enumerable string and symbol names of globals be copied by assignment and made non-enumerable in the goal state. We would need to either use a feature flag to enable the new behavior or do a trial to verify that the change is inconsequential to existing applications.

[kriskowal]

attn @naugtur since this is in endomoat policy enforcement.

[naugtur]

Last time we discussed this I was initially in favor of copying all own properties, enumerable or not.
The only thing that raises an eyebrow for me here is all owned, enumerable string and symbol names of globals be copied by assignment and made non-enumerable

• why change from enumerable to non-enumerable?
• how would we change enumerability if we're using set semantics?
• as far as I can tell, fix(compartment-mapper): fix #2407 include symbol-named properties #2408 is not turning them non-enumerable