custom cross-realm brand checking

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

custom cross-realm brand checking

Richard Gibson
One of the topics discussed in the final breakouts of last week's TC39 meeting was something like "self-hosted implementation of cross-realm internal slots". I facetiously joked about using the global symbol registry (which is shared across realms), but it was pointed out that such a mechanism would not be private.

I've been thinking about it since, and I believe that the current surface area of the language is sufficient for this to be possible without introducing something like private symbols—specifically by using built-in functions whose identity (regardless of originating realm) is verified with Function.prototype.toString.

There's a demonstration of using this technique to build custom brand-sharing classes of the sort that could trust each other across realms, and I'd love to get some feedback on it: https://jsbin.com/vujehanosu . If this actually is as robust as it seems to be, then it can also be a foundation for cross-realm access to custom analogs of internal slots.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: custom cross-realm brand checking

Jordan Harband
Function.prototype.toString wouldn't suffice as a verification - you could reconstruct it with eval, in many cases - and refactoring the implementation shouldn't force a change in the identity of a function.

On Mon, Oct 1, 2018 at 2:13 PM Richard Gibson <[hidden email]> wrote:
One of the topics discussed in the final breakouts of last week's TC39 meeting was something like "self-hosted implementation of cross-realm internal slots". I facetiously joked about using the global symbol registry (which is shared across realms), but it was pointed out that such a mechanism would not be private.

I've been thinking about it since, and I believe that the current surface area of the language is sufficient for this to be possible without introducing something like private symbols—specifically by using built-in functions whose identity (regardless of originating realm) is verified with Function.prototype.toString.

There's a demonstration of using this technique to build custom brand-sharing classes of the sort that could trust each other across realms, and I'd love to get some feedback on it: https://jsbin.com/vujehanosu . If this actually is as robust as it seems to be, then it can also be a foundation for cross-realm access to custom analogs of internal slots.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

custom cross-realm brand checking

Richard Gibson
Responses inline.

On Monday, October 1, 2018, Jordan Harband <[hidden email]> wrote:
Function.prototype.toString wouldn't suffice as a verification - you could reconstruct it with eval, in many cases
 
I've specifically constructed a use that I believe cannot be reconstructed in such a way, with or without eval. And I've made it easy to share a counterexample if there is one (just copy the shareable link).

and refactoring the implementation shouldn't force a change in the identity of a function.

I disagree, since ECMAScript functions _are_ their implementations. But note that it would be trivial to extend this technique for supporting old versions, and only slightly more challenging to look for certain aspects while ignoring others. And it may also be possible to provide a function-based approach, though I'm skeptical of that because "prove you're the same as me *and* not being wrapped or impersonated" is really difficult in such a dynamic language.

Regardless, the question is not whether you approve of this strategy—it's whether or not user code can implement the kind of robust and unforgeable cross-realm-compatible brand checks that are trivial with direct access to internal slots. I claim that it is, and hope that this is a stepping stone up for software and specifications that currently need to rely on layer violations.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss