d at domenic.me (2015-09-15T21:21:22.219Z)
On Sun, Sep 6, 2015 at 3:37 AM, Gary Guo <nbdd0121 at hotmail.com> wrote: > I think weak references are discussed before, and get postponed because it > can cause information leaks between realms. > http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#security says > To plug this leak, a weak reference created within realm A should only > point weakly within realm A. When set to point at an object from another > realm, it should either point strongly or throw an error, depending on > whether a surprising leak or a surprising error is expected to be more > inconvenient for the caller. Security demands only that such inter-realm > references not point weakly. This requires an object model change: functions are already specific to their realm of birth. This solution to the information leakage problem requires that all objects that could be weakly pointed to are already specific to the realm of their birth. Many implementations already do the necessary bookkeeping to keep track of an object's birth realm, but we would not need to mandate that bookkeeping and include it in the object model. > See https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html for > a nice refinement for pointing weakly at objects from a set of realms. Since then I have come to the opinion that an inter-realm weak reference should silently point strongly, not throw an error. The other security issue is how to make the WeakRef constructor available at all within a realm, since it should not be available to unprivileged code within a defensive realm. At https://github.com/whatwg/loader/issues/34#issuecomment-126768933 The loader is the third example of an (existing or proposed) primordial > object that does grant authority: > > - The global object, for which we rejected Reflect.global for the same > reason. > > > - The proposed WeakReference factory (e.g., WeakRef or makeWeakRef) > which makes GC observable, opening a covert channel. This is why we > carefully separated WeakMap from any notion of WeakRef. > > > - The default loader, which causes external I/O and internally has a > mutable mapping from module names to mutable module instances. > > We do need a good way to provide standard access to authority-providing > primordials such as these. In particular, I think all three of these are > well motivated and should somehow become standard. But, because they > provide authority they should be clearly separated from the means of > providing abstractions that are safely sharable. From the way the discussion proceeded, it seems an acceptable place to put these is on a global System object, i.e., - System.global - System.defaultLoader - System.WeakRef
On Sun, Sep 6, 2015 at 3:37 AM, Gary Guo <nbdd0121 at hotmail.com> wrote: > I think weak references are discussed before, and get postponed because it > can cause information leaks between realms. > http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#security says To plug this leak, a weak reference created within realm A should only > point weakly within realm A. When set to point at an object from another > realm, it should either point strongly or throw an error, depending on > whether a surprising leak or a surprising error is expected to be more > inconvenient for the caller. Security demands only that such inter-realm > references not point weakly. > This requires an object model change: functions are already specific to their realm of birth. This solution to the information leakage problem requires that all objects that could be weakly pointed to are already specific to the realm of their birth. Many implementations already do the necessary bookkeeping to keep track of an object's birth realm, but we would not need to mandate that bookkeeping and include it in the object model. > See https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html for > a nice refinement for pointing weakly at objects from a set of realms. Since then I have come to the opinion that an inter-realm weak reference should silently point strongly, not throw an error. The other security issue is how to make the WeakRef constructor available at all within a realm, since it should not be available to unprivileged code within a defensive realm. At https://github.com/whatwg/loader/issues/34#issuecomment-126768933 The loader is the third example of an (existing or proposed) primordial > object that does grant authority: > > - The global object, for which we rejected Reflect.global for the same > reason. > > > - The proposed WeakReference factory (e.g., WeakRef or makeWeakRef) > which makes GC observable, opening a covert channel. This is why we > carefully separated WeakMap from any notion of WeakRef. > > > - The default loader, which causes external I/O and internally has a > mutable mapping from module names to mutable module instances. > > We do need a good way to provide standard access to authority-providing > primordials such as these. In particular, I think all three of these are > well motivated and should somehow become standard. But, because they > provide authority they should be clearly separated from the means of > providing abstractions that are safely sharable. >From the way the discussion proceeded, it seems an acceptable place to put these is on a global System object, i.e., System.global System.defaultLoader System.WeakRef -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150906/52774526/attachment.html>