| 06:14 | <Mathieu Hofman> | First I think the main focus here is to build a safe resolve operation for spec and host, and not directly exposed to the programmer. Second even if that proxy sensitive operation was directly accessible to programs, we may find it preferable to changing the semantics of thenables. |
| 06:16 | <bakkot> | Several delegates have expressed the constraint that anything we do here should be implementable in userland; e.g. Node implements a bunch of web APIs in JS |
| 06:18 | <bakkot> | and I don't think this is changing the semantics of thenables given that it's doable in userland already, unless we handle the frozen objects case, which is not really part of how anyone thinks of thenables afaik |
| 20:42 | <nicolo-ribaudo> | Are AOs first class values? Can I maybe pass an AO name to something that expects an abstract closure? |
| 20:45 | <nicolo-ribaudo> | Oh I guess the answer is "yes", like in steps 6-7-8 of https://tc39.es/ecma262/#sec-applystringornumericbinaryoperator. Nice |
| 21:54 | <Mathieu Hofman> | I'm not sure I understand what you mean. My concern is that your "userland solution" relies on the resolution value to have a non-frozen then. It simply fails with frozen values, which I hope we can agree should be totally valid values to use as a resolution. |
| 21:55 | <bakkot> | you cannot specifically pass an AO name to something that expects an abstract closure, those are different kinds of thing |
| 21:55 | <bakkot> | you can do the thing in ApplyStringOrNumericBinaryOperator but it's not a common pattern and I wouldn't recommend it in most cases |
| 21:56 | <Mathieu Hofman> | We can definitely consider exposing to userland a safe resolve operation, even if that operation would let the caller asynchronously discover information about whether the value is a proxy (or has a proxy in its prototype chain). |
| 21:57 | <Mathieu Hofman> | I currently find that preferable to other alternatives I've heard so far. |
| 22:02 | <Mathieu Hofman> | However I haven't heard a request for userland to be able to implement the safe resolve operation itself. Just that whatever hosts can do, that userland can do it just as much (aka a virtualization constraint, which of course I'm 100% behind) |
| 22:13 | <Michael Ficarra> | @nicolo-ribaudo according to our editorial conventions, it should be avoided https://github.com/tc39/ecma262/wiki/Editorial-Conventions |
| 22:14 | <bakkot> | I am primarily concerned about preventing this class of CVEs in browsers, which are about passing spec-defined objects, none of which expect to have a We could, additionally, provide a version which works even if the object has been modified in one of those two ways. I'm neutral on this; it's pretty much irrelevant to the case of web specs because users are not, in practice, going to do either of those things. However, if we did, I don't think it would meaningfully change the definition of "thenable" given what's already possible. |
| 22:14 | <bakkot> | sorry, to be clear, I meant the latter thing yes |
| 22:17 | <Michael Ficarra> | there's an easy solution here though, which is to define an AC that just forwards its parameters to an AO |
| 22:22 | <bakkot> | I'm fine with that too if everyone else is. |