| 09:50 | <ystartsev> | I want to drag up an old discussion: https://twitter.com/bmeurer/status/938260338704900096 |
| 09:51 | <ystartsev> | Did anything ever happen with this? |
| 09:51 | <ystartsev> | more context: https://twitter.com/bmeurer/status/938651499420422144 |
| 09:55 | <ystartsev> | I see some arguments around SES and webcompat, wondering if there is more documentation around this |
| 16:03 | <ljharb> | i think if it was web compat to get rid of species, a lot of people would love to |
| 16:03 | <ljharb> | but imo if we can't get rid of it somewhat close to 100%, then it's better to keep the consistency |
| 16:13 | <shu> | i would love to get rid of species |
| 16:14 | <shu> | let me see if v8 has any usecounters here already... |
| 16:15 | <shu> | ystartsev: if you are also serious about removing species, i suggest that all the browser vendors coordinate on shipping counters/telemetry to get a better picture |
| 16:15 | <shu> | usually the argument for doing extra legwork is it's not worth it and we all got better things to do |
| 16:16 | <shu> | but species is worth removal because of the high security hazard borne out by past experience |
| 16:16 | <ystartsev> | shu: ok, that sounds like a good idea. |
| 16:16 | <ystartsev> | i need to understand the web compat issues |
| 16:16 | <ljharb> | can you tell me more about the security hazard? i'm only familiar with "people think it's icky and unnecessary" |
| 16:16 | <shu> | ljharb: valerie from project zero gave an invited talk at tc39 once |
| 16:17 | <shu> | project zero had a field day with project zero |
| 16:17 | <ystartsev> | but we were discussing it also and it looks like we are supporting this for a very limited use case, but it introduces a lot of performance issuse and complexity |
| 16:17 | <shu> | the security hazard follows directly from the complexity it induces in JITs |
| 16:17 | <shu> | because JITs are optimistic optimizers, they have to manually encode all failure modes to bail out |
| 16:17 | <shu> | species is not something that's easy to get right |
| 16:17 | <shu> | and when you get it wrong, that often becomes exploitable |
| 16:18 | <ljharb> | interesting, ok. i must have missed that one |
| 16:18 | <ljharb> | shu: was it the godaddy one? |
| 16:18 | <shu> | err, i mean project zero had a field day with species, not project zero :) |
| 16:18 | <ljharb> | or maybe europe last year |
| 16:18 | <shu> | ljharb: i don't remember, let me grep the notes... |
| 16:18 | <ljharb> | oh thanks, i could do that too i suppose |
| 16:18 | <shu> | my recollection is more than 2 years ago |
| 16:18 | <ljharb> | ah k, no worries |
| 16:19 | <shu> | the main problem is array species over other species |
| 16:19 | <shu> | because so much work goes into optimizing array access |
| 16:20 | <shu> | hm maybe there were no notes for this |
| 16:20 | <shu> | am i misremembering... |
| 16:21 | <shu> | ah i misremembered the name of the researcher, my bad: Natalie Silvanovich |
| 16:22 | <ljharb> | ah i remember natalie's presentation, but i didn't recall species as a big part of it as much as indexed prototype access |
| 16:23 | <shu> | subclassing was also big part of it |
| 16:26 | <shu> | ljharb: https://docs.google.com/presentation/d/11fkQeEisoszNGF8SrautVT1ltSnsQBWRxJ4usoc-g_o/edit#slide=id.g2b34aaab4a_0_10 look at slide 4 |
| 16:26 | <shu> | trail of tears |
| 16:27 | <shu> | we should just have a script that auto-removes features once it accumulates more than N CVEs and has less than M% uptake in the wild |
| 16:28 | <ljharb> | haha |
| 16:28 | <ljharb> | ime CVEs are mostly false positives, so that might be a bit too hair-trigger :-p |
| 16:29 | <ljharb> | but yeah, let's exterminate the species |
| 17:23 | <ystartsev> | \o/ |
| 17:23 | <ystartsev> | should i put it on the agenda? |
| 17:24 | <shu> | ystartsev: sure, happy to collaborate on it |
| 17:25 | <ystartsev> | ok |
| 17:25 | <ystartsev> | lets set up a call late this week or early next week shu ljharb ? |
| 17:27 | <shu> | do we need a call? |
| 17:27 | <ystartsev> | well, maybe not |
| 17:27 | <shu> | (i mean it seems like we're already all on the same page, i meant more like be happy to help do slides) |
| 17:27 | <ystartsev> | just trying to think of how to organize it |
| 17:27 | <ystartsev> | ah ok |
| 17:27 | <ystartsev> | well |
| 17:27 | <ystartsev> | yeah that sounds good |
| 17:27 | <devsnek> | has it gotten any more CVEs since that presentation |
| 17:28 | <shu> | dunno, worth asking about |
| 17:43 | <Bakkot> | ystartsev see https://github.com/tc39/ecma262/issues/1313 |
| 17:44 | <Bakkot> | I would also love for the committee to get a coherent position on Symbol.species because the current state of things leaves us discussing it unproductively every time it comes up. e.g with Set.prototype.union |
| 17:45 | <shu> | ystartsev: also in the space of gauging backwards-incompat changes, i added a counter to v8 to measure use of the vars redeclaring catch bindings |
| 17:46 | <shu> | Bakkot: it seems like what ystartsev and i are thinking of is an even more radical version of domenic's suggestion in that issue, is that right? |
| 17:46 | <Bakkot> | Domenic's proposal includes "Consider removing it from any existing methods where doing so would be web-compatible", so it's covered by it |
| 17:46 | <Bakkot> | but yeah |
| 17:47 | <shu> | oh i think v8 already has species use counters, let's see... |
| 17:47 | <devsnek> | it has things with species in the name |
| 17:47 | <devsnek> | i have no idea what they imply though |
| 17:47 | <devsnek> | also the charts seem broken |
| 17:49 | <shu> | hm indeed the charts seem broken |
| 17:50 | <shu> | i guess *all* charts are broken? |
| 17:50 | <shu> | oh, no |
| 17:50 | <Bakkot> | use counters seem like they'd be messed up by polyfills |
| 17:50 | <ljharb> | the regex `Symbol.match` one was |
| 17:50 | <ljharb> | i remain convinced that 100% of the usage of Symbol.match on a non-regex was core-js feature-testing Symbol.match |
| 17:50 | <shu> | Bakkot: polyfills of @@species? |
| 17:51 | <devsnek> | V8SloppyMode was reporting 120% of page loads on may 1st |
| 17:51 | <Bakkot> | shu yeah |
| 17:51 | <ystartsev> | _i am technically on family time now so i will look at this tomorrow_ |
| 17:51 | <bradleymeck> | or things testing its existance |
| 17:51 | <ljharb> | shu: https://github.com/paulmillr/es6-shim/blob/master/es6-shim.js#L215 https://github.com/paulmillr/es6-shim/blob/master/es6-shim.js#L486-L502 |
| 17:51 | <shu> | oh, i misunderstood |
| 17:51 | <shu> | messed up in the sense of false positives |
| 17:51 | <ljharb> | yes |
| 17:52 | <ystartsev> | shu: Bakkot i was thinking something along the lines of domenic's suggestion, but this was raised in spidermonkey discussions and I wanted to see what was possible. It is a pain point and seems to have limited use cases, and a huge cost |
| 17:52 | <ljharb> | if you can find a way to delete core-js and es5-shim/es6-shim from use counters, we'd get much more deleteable results i suspect |
| 17:52 | <shu> | the problem of the data being busted right now is worse :) |
| 17:52 | <shu> | ljharb: i think we scrub that level of info from the data |
| 17:53 | <shu> | ystartsev: agree 100% on huge cost |
| 17:53 | <shu> | like the amount of slow paths and extra guards that v8 has here is really not worth it |
| 17:53 | <ystartsev> | yeah the perf impact for us is huge, |
| 17:53 | <shu> | sure it's "done" now, but it has cross-cutting concerns for future features as well |
| 17:54 | <ystartsev> | _gotta duck out_ |
| 17:54 | <shu> | have a good night |
| 17:59 | <ljharb> | shu: yeah i think you're right, which is unfortunate because it means there's no way for me to actually fix Symbol.match |
| 18:00 | <shu> | i'm wondering if the chart for these species use counters is busted because there is literally *no* data |
| 18:00 | <shu> | like, they have never been hit |
| 18:32 | <Bakkot> | can you ask the owners to read the data from the database directly? |
| 18:33 | <devsnek> | shu: they have proper readings on the main popularity page |
| 18:34 | <shu> | devsnek: Bakkot: i'm reading the data directly right now in the google-internal page |
| 18:35 | <shu> | i am kind of confused |
| 18:36 | <shu> | so the popularity page says it's the % of page loads that use the corresponding feature at least once... |
| 19:31 | <shu> | i feel like i need a data scientist for this |
| 19:37 | <shu> | the most conservative view i've been able to distill is that Array @@species in particular have decreased in time but still is around ~0.006% of all page views, which is actually moderately risky |
| 20:40 | <bradleymeck> | shu: is there any sort of domain masking behind the scenes to know how many domains are affected? |
| 20:41 | <bradleymeck> | also i'm curious about what makes this a conservative vs normal view |
| 20:41 | <shu> | bradleymeck: conservative because it's just based off page view hits |
| 20:42 | <shu> | bradleymeck: there is info on domains affected: bottom of https://chromestatus.com/metrics/feature/timeline/popularity/1391 |
| 20:45 | <shu> | that counter is specifically for modifying Array[Symbol.species] |
| 20:53 | <bradleymeck> | shu: quick get/set trap on some of these and a lot seems to be from a Zones polyfill? |
| 20:54 | <bradleymeck> | sec just moving to set trap |
| 20:55 | <shu> | i couldn't parse your last two sentences :) |
| 20:56 | <bradleymeck> | shu: there appears to be a semi-popular library common across a variety of these sites |
| 20:56 | <shu> | ah, now i got it, Zones like domenic's old zones proposal? |
| 20:56 | <shu> | like that ambient context thing? |
| 20:56 | <shu> | fascinating |
| 20:57 | <shu> | i'm going to start a doc documenting what web compat data we have now to gauge risk, since page views alone makes it look risky, but my hunch is that it isn't |
| 20:57 | <shu> | bradleymeck: are you also interested in killing off @@species? |
| 20:57 | <bradleymeck> | shu: i once got asked in a JS meetup what I regret most about JS things that landed, I said @@species |
| 20:58 | <shu> | my man |
| 20:58 | <bradleymeck> | unclear on origin, but salesforce has a different lib doing typed array detection to polyfill a Node API oddly |
| 20:59 | <bradleymeck> | TYPED_ARRAY_SUPPORT is the token that is shared around all of this regardless of the minification... checking |
| 21:03 | <bradleymeck> | shu: thats a lot of code on github using this pattern, i'm surprised it is that low of a counter |
| 21:03 | <bradleymeck> | but one of the main libraries in question at least on github glance https://github.com/feross/buffer/commit/753c064753a174455701cabd9e9feadff7fc768d removed that code semi-recently |
| 21:05 | <shu> | what is Buffer? |
| 21:05 | <shu> | that use counter is specifically for the Array constructor, not all uses of @@species |
| 21:09 | <devsnek> | polyfill of node buffers |
| 21:10 | <devsnek> | its automatically used by webpack and such |
| 21:11 | <bradleymeck> | shu: https://github.com/zloirock/core-js/blob/6e3106817aa46919273b80d6f961e75a65967d22/packages/core-js/internals/set-species.js is being hit a lot too, but trying to read through core-js minified stuff is making my head hurt |
| 21:13 | <Bakkot> | bradleymeck: https://unminify.io/ will probably make it a lot more readable |
| 21:14 | <shu> | bradleymeck: "hit a lot" meaning? |
| 21:14 | <bradleymeck> | Bakkot: i pretty printed it, does that do more? |
| 21:15 | <Bakkot> | bradleymeck yeah it does stuff like `foo && bar()` -> `if (foo) { bar(); }` |
| 21:15 | <bradleymeck> | shu: E.G. https://www.bmw-m.com/en/index.html , `a("./$.species")(Array)` always gets shimmed? |
| 21:15 | <bradleymeck> | but reading that code is... very abstract |
| 21:16 | <shu> | what are you using to define the set traps and make sure that gets loaded at page start? |
| 21:17 | <bradleymeck> | replacing Object.defineProperty and putting a getter/setter on Array[@@species] |
| 21:17 | <shu> | i'm asking the more mechanical question: how do you get that to run before any other scripts run? |
| 21:18 | <shu> | i'm assuming something in devtools lets you do this? |
| 21:18 | <bradleymeck> | shu: https://gist.github.com/bmeck/9633a2459ffe87b62feff1304a342db4 |
| 21:19 | <bradleymeck> | i put a local override in and refresh |
| 21:19 | <bradleymeck> | just at top of page html |
| 21:19 | <shu> | ah, neat |
| 21:20 | <devsnek> | i wonder if firefox has something like local overrides |
| 21:22 | <bradleymeck> | wouldn't be too bad to implement :ponder: |
| 21:22 | <bradleymeck> | honestly i should just write an extension to be more thorough than a local override, probably missing plenty of iframe shenanigans |
| 21:27 | <shu> | why is core-js a million 2-line files |
| 21:27 | <shu> | what is this |
| 21:29 | <bradleymeck> | :jazz hands: |
| 21:34 | <bradleymeck> | my question is really why does it shim it if it exists |
| 21:34 | <shu> | yes indeed |
| 21:35 | <bradleymeck> | shu: does that usage counter take into account if the value is unchanged? only descriptor bits? |
| 21:36 | <devsnek> | it does |
| 21:36 | <devsnek> | `if (DESCRIPTORS && C && !C[SPECIES])` |
| 21:36 | <shu> | bradleymeck: it's not that smart, that use counter logs any time @@species is passed as the property key to a set or define on the Array constructor |
| 21:37 | <bradleymeck> | devsnek: sitting at a debugger statement where Array[@@species] === Array right before it defineProperties it to a weird get() {return this} |
| 21:38 | <devsnek> | weird |
| 21:39 | <bradleymeck> | https://usercontent.irccloud-cdn.com/file/hLWcbCL6/replacing-species-anyway.png |
| 21:39 | <shu> | bradleymeck: so using your local override i've been pondering libertypr.com |
| 21:39 | <shu> | i think it is bundling a very very old version of core-js |
| 21:40 | <shu> | bradleymeck: at 0.7.0 of core-js, you have this file: https://github.com/zloirock/core-js/blob/9ed55e682ff0a9814b6bb0c15c8c058bdfb8d954/src/%24.species.js |
| 21:40 | <bradleymeck> | so, the weird thing is it is replacing it with ~ the spec |
| 21:40 | <shu> | these names match up to the strings i see in the libertypr.com sources |
| 21:41 | <bradleymeck> | it is effectively not doing anything |
| 21:41 | <shu> | i have no idea what $.FW is but it's always defining a @@species with a getter that returns "this" |
| 21:41 | <shu> | so... awesome |
| 21:42 | <bradleymeck> | shu: thats the spec behavior tho |
| 21:42 | <bradleymeck> | https://tc39.es/ecma262/#sec-get-array-@@species |
| 21:42 | <shu> | bradleymeck: i'm saying core-js is explicitly installing a getter regardless of if C[@@species] is already set |
| 21:42 | <shu> | very old core-js is, anyway |
| 21:43 | <shu> | which is what these sites are bundling, i guess, and that's what's hitting a lot of the counters |
| 21:43 | <shu> | i think we're just violently agreeing? |
| 21:43 | <shu> | this is "good" in that the shim is doing something useless |
| 21:43 | <shu> | and is not a compat risk |
| 21:43 | <bradleymeck> | probably, i'm kind of confused/angry/relieved |
| 21:44 | <shu> | that's just this one site |
| 21:44 | <bradleymeck> | shu: i'll script out the whole list and handle iframes if you really want that data |
| 21:44 | <shu> | i think if we do enough manual legwork and see that most of these counter hits are in fact benign |
| 21:44 | <bradleymeck> | but 🤷 |
| 21:44 | <shu> | i am willing to make the case internally to try this backwards breaking thing |
| 21:45 | <shu> | what would the ideal use counter be testing for? |
| 21:45 | <bradleymeck> | would be good to nail down the exact semantics of our check we want |
| 21:45 | <shu> | yeah |
| 21:45 | <bradleymeck> | that {return this} function body XD |
| 21:45 | <shu> | i feel like it's not on the "set" but on the "get" |
| 21:46 | <bradleymeck> | probably, if you do a get on an Array subclass but it isn't the `this` |
| 21:46 | <bradleymeck> | or ... perhaps if it isn't Array? |
| 21:46 | <shu> | yeah i think the actual counter is too expensive to ship |
| 21:46 | <shu> | it's something like: |
| 21:48 | <shu> | trap every call to get @@species in a built-in function. if `this` in the get is one of {Array,Promise,...}, count a use if the return value of the get isn't the built-in constructor, else count a use (i.e. the subclassing case) |
| 21:48 | <bradleymeck> | thats probably a lot of checks given all the usage of array fns |
| 21:50 | <Bakkot> | bradleymeck you have `args[1] =a== Symbol.species` |
| 21:50 | <Bakkot> | which seems like... not what you want |
| 21:50 | <bradleymeck> | Bakkot: for testing when they replace Symbol.species? |
| 21:51 | <Bakkot> | note the `=a==` |
| 21:51 | <bradleymeck> | ah, probably not |
| 21:51 | <bradleymeck> | oh, not in the gist |
| 21:51 | <bradleymeck> | thats me poking around and accidentally typing in devtools |
| 21:52 | <bradleymeck> | https://gist.github.com/bmeck/9633a2459ffe87b62feff1304a342db4/edit is the code i run to breakpoint it |
| 21:52 | <Bakkot> | good good |
| 21:53 | <bradleymeck> | shu: is there any point in crawling those sites to manually test that counter? |
| 21:53 | <shu> | mtg, gimme 20 mins |
| 21:54 | <bradleymeck> | ill be making dinner, will reply async |
| 21:54 | <devsnek> | unsure if meeting or magic the gathering |
| 21:54 | <shu> | do i strike you as a mtg player |
| 21:55 | <ljharb> | you could probably make a comic sans deck |
| 21:55 | <devsnek> | everyone in this channel is a possible mtg player |
| 22:13 | <shu> | bradleymeck: by crawling those sites to manually test, do you mean one of us scripts this? |
| 22:21 | <bradleymeck> | I have stuff already in place with minimal mods to run tests like this |
| 22:21 | <bradleymeck> | shu: yes |
| 22:22 | <shu> | bradleymeck: i am a noob at scripting the browser, but i would like to try this for the sites in the data set |
| 22:23 | <bradleymeck> | Sure, just let me know all relevant stats you want I'll revive the crawler we use |
| 22:23 | <shu> | ideally this has enough smarts to even know if it looks like an old core-js shim |
| 22:24 | <bradleymeck> | It will be slowish so a few extra counter points isn't that expensive |
| 22:24 | <shu> | like having $.species on the stack |
| 22:24 | <bradleymeck> | Just fn src of the getter enough? |
| 22:24 | <shu> | bradleymeck: i will spend the rest of the day writing up a google doc capturing what i know and next steps and share it with you and yulia |
| 22:24 | <bradleymeck> | $.species gets minified sometimes but we can count it |
| 22:24 | <shu> | we can work out the crawler details from there |
| 22:25 | <bradleymeck> | K |
| 22:31 | <ljharb> | if you make this crawler reusable enough that i can use it for other feature tests, i would be very happy about that |
| 22:51 | <bradleymeck> | I'll ask, I don't see why not |
| 22:58 | <devsnek> | there was a bigquery db somewhere |
| 22:59 | <devsnek> | with a lot of useful data |
| 22:59 | <devsnek> | it might've been google's |
| 23:19 | <shu> | do you mean HTTP Archive? that's google's |
| 23:20 | <shu> | that's where those urls came from |
| 23:21 | <shu> | but what i understand bradleymeck to be proposing is something that does more than crawl, like it'd try to script a browser to actually load the front page with a user script and observe some behavior? |
| 23:21 | <shu> | (because if not, then yeah, we'll just run bigquery oh HAR) |
| 23:40 | <bradleymeck> | Our internal http-interceptor uses debug protocol on a browser instance, not parsing HAR |
