| 00:42 | <rkirsling> | say, wrt function impl hiding |
| 00:42 | <rkirsling> | was adding a field to property descriptors ever suggested? |
| 00:44 | <bradleymeck> | rkirsling: for what |
| 00:44 | <rkirsling> | I can only remember like "yeah directives are awful and should be a thing we did once ever but it's better than mucking further with function syntax" |
| 00:45 | <bradleymeck> | rkirsling: you mean like `define(o, 'methodName', {..., makeItHidden = true}`? |
| 00:45 | <bradleymeck> | no i don't believe it was since it wouldn't handle a simple fn.toString() |
| 00:45 | <rkirsling> | but it seems like `hidden` as a souped-up version of `configurable: false` would be reasonable in theory |
| 00:45 | <rkirsling> | ah |
| 00:47 | <rkirsling> | or like `Object.hide()` I guess would be a similar idea |
| 00:47 | <bradleymeck> | i don't believe that exact api was mentioned but an accessor was talked about at some point |
| 00:47 | <rkirsling> | hm sure |
| 00:48 | <rkirsling> | how did you mean "wouldn't handle"? I'm sure I'm overlooking an important bit |
| 00:49 | <shu> | rkirsling: perhaps bradleymeck meant for local bindings |
| 00:49 | <shu> | rkirsling: how do you defineProperty a binding? |
| 00:49 | <rkirsling> | ah right yeah |
| 00:49 | <bradleymeck> | yea, if you have a reference to the fn already somehow |
| 00:50 | <shu> | i have some vague recollections of discussions around the function author being the decider of whether it should be hidden or not |
| 00:50 | <shu> | so APIs that mutate the visibility of functions after the fact may be unsatisfactory |
| 00:50 | <rkirsling> | I mean I guess you could argue that if you need a function to be hidden then perhaps it's acceptable to be required to declare it in this way and not that |
| 00:50 | <rkirsling> | (i.e. not as a local binding) |
| 00:51 | <rkirsling> | yeah I can see concern about after-the-fact |
| 00:52 | <shu> | a big implementation problem with visibility as a state of a *reference* instead of the function value is you'd have to then track that state on a per-reference basis |
| 00:53 | <shu> | that seems pretty gnarly |
| 00:53 | <rkirsling> | oh hmm right |
| 00:53 | <rkirsling> | I wasn't thinking of it in that way |
| 00:53 | <shu> | also the stack hiding directive no longer makes sense |
| 01:07 | <rkirsling> | right. for some reason I hadn't thought of prop descriptors as describing the means of access and not the thing in itself, even though that sounds ridiculously obvious when I say it out loud |
| 01:10 | <bradleymeck> | out of a sampling of 2500 sites that I am now fairly confident about the coreJS detection happening for @@species, 100% of all traps are from coreJS |
| 01:11 | <bradleymeck> | thats nutty |
| 01:11 | <shu> | corejs!!! |
| 01:11 | <bradleymeck> | but it also means we likely need to instrument into coreJS itself since it replaces things |
| 01:11 | <rkirsling> | that's some good data |
| 01:11 | <shu> | is that meme too dated now? have young'uns nowadays watched wrath of khan? |
| 01:11 | <rkirsling> | I'm excited about this project |
| 01:12 | <shu> | bradleymeck: any insight into the vintage of corejs? i feel like it must all be pretty old |
| 01:12 | <bradleymeck> | i worry about some of the corejs stuff since userland would still be using it as if it were a @@species impl and we don't have numbers on users of corejs actually using things |
| 01:12 | <rkirsling> | wait was the similarity to khaaaan there supposed to be obvious? 😅 |
| 01:12 | <bradleymeck> | shu: i haven't tried to get that data |
| 01:13 | <bradleymeck> | i do know hatenablog is 2% of all usages of @@species pages and it uses an older one |
| 01:14 | <rkirsling> | maybe we can dogeza them into updating |
| 01:14 | <bradleymeck> | idk, updating would still be emulating via a new polyfill |
| 01:14 | <bradleymeck> | i don't think updating actually fixes anything |
| 01:15 | <rkirsling> | oh I meant "updating" in a general sense, but also I was half-joking |
| 01:16 | <bradleymeck> | i think the big thing would be getting babel to stop bundling it |
| 01:16 | <bradleymeck> | since that looks like what most of it is coming from |
| 01:16 | <bradleymeck> | most? all |
| 01:17 | <bradleymeck> | well likely not all but scraping is showing it to be used even if it isn't really needed so some build tool is doing it |
| 01:19 | <rkirsling> | mhm |
| 02:02 | <Bakkot> | I guess completion values for `break` are also pretty weird: https://github.com/tc39/ecma262/issues/1085#issuecomment-570464401 |
| 02:16 | <devsnek> | we should make a thing that generates random valid syntax and then asks whether the completion from it is reasonable or not |
| 02:18 | <rkirsling> | you can call it YouCompleteMe |
| 02:18 | <Bakkot> | "asks whether the completion from it is reasonable" requires knowing what "reasonable" means |
| 02:18 | <Bakkot> | but it's easy to ask if engines are consistent, sure |
| 02:19 | <Bakkot> | I did this when I implemented try-finally in my compiler |
| 02:19 | <Bakkot> | found a lot of bugs |
| 02:20 | <Bakkot> | https://github.com/shapesecurity/shift-codegen-js + a dozen lines of code for producing interesting ASTs will get you there |
| 02:21 | <devsnek> | Bakkot: I mean asks us |
| 02:21 | <devsnek> | that's pretty cool |
| 02:21 | <Bakkot> | ahh |
| 02:22 | <Bakkot> | I love fuzzers |
| 02:25 | <devsnek> | here's one for all the js values https://github.com/devsnek/fuzzy |
| 02:25 | <devsnek> | or most of them anyway |
| 02:26 | <devsnek> | Def needs some work though |
| 02:26 | <Bakkot> | https://github.com/shapesecurity/shift-fuzzer-js does ~ all javascript programs |
| 02:26 | <Bakkot> | bit out of date though |
| 02:26 | <Bakkot> | also tends to generate duplicate bindings, which I need to fix |
| 02:27 | <Bakkot> | ah, yours is the actual values, not programs |
| 02:27 | <Bakkot> | neat |
| 02:29 | <devsnek> | yeah not as fun as generating code |
| 02:29 | <devsnek> | but it helped me write an etf library |
| 02:30 | <Bakkot> | ... exchange-traded fund? |
| 02:32 | <devsnek> | erlang term format |
| 02:32 | <devsnek> | data serialisation |
| 02:47 | <shu> | are we writing prospectus for a new fund |
| 02:52 | <Bakkot> | I was reminded recently that schwab's bond aggregate bond fund trades as SWAGX |
| 02:53 | <Bakkot> | we should make a fund that tries to track JS companies, and then short it, and then intentionally stabotage the language |
| 02:53 | <Bakkot> | I wonder if the ECMA member agreement anticipates that possibility |
| 02:54 | <shu> | well now, if you count ecma member companies as JS companies |
| 03:02 | <devsnek> | I'm not sure we can make anything worse than == |
| 03:06 | <Bakkot> | rebindable syntax + sync XHR |
| 03:06 | <Bakkot> | so that every `===` can be a main-thread-blocking network request |
| 03:10 | <devsnek> | innovative |
| 03:11 | <devsnek> | Bakkot: did you know that comparing two url objects in java by default does a synchronous dns resolution |
| 03:31 | <Bakkot> | yeah |
| 03:31 | <Bakkot> | also map lookups IIRC |
| 04:09 | <shu> | i mean, problems demand solutions |
| 04:09 | <shu> | i don't know what to tell ya |
| 04:13 | <Bakkot> | problem: you want your URLs to compare as equal if they resolve to the same IP |
| 04:13 | <Bakkot> | solution: stop wanting that |
| 04:16 | <Bakkot> | when I was in grad school I had this comic hung on my wall: https://i.imgur.com/7LbRv4V.png |
| 04:23 | <rkirsling> | lol |
| 04:34 | <devsnek> | i love it |
| 04:44 | <ljharb> | bradleymeck: corejs is not going to be possible to get any changes into, its maintainer is indisposed for 18 months |
| 04:44 | <ljharb> | bradleymeck: if that's what you meant by "instrument" |
| 13:15 | <bradleymeck> | ljharb: nah, i was just going to use the debugger to step into his code and muck around. since the sites are deployed we can't really change their code |
| 14:14 | <littledan> | chairs, I'm not sure if the meeting agenda is getting a little overpacked; I'm fine to wait on the operator overloading discussion until next meeting if we are running out of slots |
| 14:59 | <bradleymeck> | littledan: i'd rather we drop from...import |
| 14:59 | <littledan> | why not both? |
| 14:59 | <bradleymeck> | i have some prelim feedback that people aren't too keen oon the idea for now |
| 14:59 | <littledan> | huh really? |
| 14:59 | <littledan> | I always want to type `from...import` |
| 14:59 | <bradleymeck> | and i think there are better uses of time for now like op overloading |
| 14:59 | <littledan> | well my topic is towards the end, so we can decide dynamically |
| 15:00 | <littledan> | we can deprioritize from...import and see at the end which we have time for, or both |
| 17:42 | <ljharb> | seems better not to prematurely optimize the agenda :-) |
| 17:45 | <devsnek> | we can just skip everything before the needs consensus items |
| 17:50 | <Bakkot> | editor's update is actually going to have some content which is not just routine updates this time |
| 19:20 | <leobalter> | @bterlson @bradleymeck can I get admin access to the https://github.com/tc39/proposal-compartments repo? I'd like to transfer 4-5 issues recently opened for Realms that I believe they apply to the compartments proposal. @erights is aware. |
| 19:23 | <bradleymeck> | leobalter: delegates are upgraded perms now |
| 19:23 | <rkirsling> | does anybody have a concrete example of a function impl hiding use-case which involves "security-sensitive" code and not just library/polyfill code? I'm still unclear on how any reasonable sort of "confidentiality" is achieved if you can just open the resource directly as usual (or hell, even grep the specific places that would now be marked `"sensitive"`)? |
| 19:24 | <ljharb> | rkirsling: runtime fraud detection scripts that are dynamically updated over time, that runtime malicious scripts would thus be unable to dynamically adapt to |
| 19:24 | <ljharb> | rkirsling: iow yes, the malicious authors could download the code, but that drastically increases the window between "improved defense" and "improved attack" |
| 19:24 | <ljharb> | whereas if they can view the impl, they could try to write code to shorten that window |
| 19:25 | <ljharb> | (that's the understanding i have of one of those use cases, at any rate) |
| 19:25 | <rkirsling> | ah okay, that's helpful |
| 19:27 | <leobalter> | bradleymeck: thanks! |
| 19:28 | <bradleymeck> | rkirsling: yea, its the diff of being able to exfiltrate source to find exploits vs not. fn impl hiding would lean towards people needing debugger access to get that kind of exfiltration |
| 19:35 | <rkirsling> | thanks! |
| 20:34 | <leobalter> | bradleymeck: can you copy the link here, please? |
| 20:34 | <bradleymeck> | https://godaddy.zoom.us/j/92149833952 |
| 20:43 | <shu> | welp, V8 got its first bug report for "why isn't my finalizer running" |
| 20:48 | <jridgewell> | Link? |
| 20:50 | <rkirsling> | heh |
| 20:52 | <Bakkot> | :D |
| 20:53 | <shu> | https://bugs.chromium.org/p/v8/issues/detail?id=10569 |
| 20:54 | <devsnek> | i'm waiting for the ones that involve `delete` |
| 21:12 | <drousso> | tell them to try forcing a GC using Web Inspector and then see if it invokes |
| 21:13 | <devsnek> | will that mark or just sweep |
| 21:31 | <devsnek> | ystartsev: is avandolder actually implementing the iterator proposal rn? |
| 21:41 | <devsnek> | ah i found https://bugzilla.mozilla.org/show_bug.cgi?id=1568906 |
| 21:41 | <devsnek> | very cool |
