Jack Works

I believe this becomes urgent. SES lockdown now fails on core-js 3.23 and it cannot be fixed on the core-js side. See discussion in: https://github.com/zloirock/core-js/issues/1092

- immer (writes mapInstance.set) https://github.com/immerjs/immer/pull/914/ - web3-core-method (writes functionInstance.call) https://github.com/ChainSafe/web3.js/pull/4918 - gun (writes so many utility functions) https://github.com/amark/gun/pull/1217 - error-polyfill (try to polyfill Error.captureStackTrace and Error.getStackTrace) https://github.com/inf3rno/error-polyfill/pull/38/ Following packages bundles...

I believe this is duplicated to https://github.com/endojs/endo/issues/925 and #318

 Still left 2 intrinsics

Call `.toString()` on the function, if it contains `"hide source"` or `'hide source'`, then return `[native code]`. But that requires `toString()` on all functions ~~so I think extensible WeakMap is...

 I found sentry is doing the same thing and I'm figuring out how to use sentry with lockdown

another idea comes up to my mind. If we allows `Function.prototype.toString()` to be overwritten after lockdown, it allows those libraries to patch them as "native function"

Since we don't have a `repairIntrinsics` phase... But marking function as native is a thing that many implementation does.

Like what we did the tolerate to Array.prototype.sort.prototype

Yes, this will be unsafe. But any method I can think of is either unsafe or will trigger user code.