TC39 Module Harmony
2022-11-08
plaintext logs
prev next
source on github
16:35
<shu>
i will not be to attend next meeting; this and next week conflict with some chrome events (blinkon next week, some other thing this week)
16:57
<Kris Kowal>
We did not prepare an agenda. If guybedford is prepared to show us some WASM integration, this would probably be a fine meeting to do so.
17:00
<guybedford>
I guess we could work through a status update of the various specs perhaps since we haven't had a sync in a while
17:01
<guybedford>
not much to show for Wasm right now short of the basic reflection use case which we can always go through again, but was actually considering giving a more in depth Wasm components intro as a TC39 presentation possibly for the next meeting
17:02
<guybedford>
(and sorry just fumbling for the meeting link here!)
18:06
<yulia>
oh, we still had another half hour on the time
18:08
<nicolo-ribaudo>
Dinner time for all of us near GMT, it's fine to end earlier :P
18:10
<nicolo-ribaudo>

Mathieu Hofman I was wrong, (async function f() { try { await import("data:text/javascript, throw new Error()") } catch (e) { return console.log("STACK", e.stack) } })() doesn't leak the function name neither in Chrome nor in Firefox.

The error stack contains the function name only when the error is a CSP error, but in that case it throws fresh errors every time.

19:26
<Mathieu Hofman>
interesting that the CSP error contains more information
19:26
<Mathieu Hofman>
We really need to move the error stack proposal forward to put them within tc39 scope
19:31
<littledan>
My understanding from comments from shu was that adding an error stack API wouldn't cause browsers to necessarily change how they expose non-standard information. I think you'd have to persuade them to make those changes more directly.
19:31
<littledan>
(please correct me if I misunderstood)
19:40
<Mathieu Hofman>
The main problem is that right now it's hard to talk about stacks in the spec, and what information can and cannot be exposed through them
19:41
<Mathieu Hofman>
We're seeing this with the ShadowRealm proposal, we're seeing it potentially with the lazy/deferred module loading.
19:42
<Mathieu Hofman>
it may or may not be a problem for any changes we want to make to promises as well
19:42
<littledan>
this relates a lot to the lack of a shared model for what constitutes an information leak, though
19:42
<shu>
i haven't checked since last time this was brought up but littledan's summary still sounds accurate
19:43
<littledan>
(and I think this is not as simple as documenting what the SES group believes is an information leak--there is a sort of ideological disagreement)
19:43
<Mathieu Hofman>
burring out head in the sand pretending stacks don't exist is not right, as programs very much can observe them and change their execution
19:44
<shu>
who is doing that in your opinion, tc39?
19:44
<littledan>
yeah, so I think the project of addressing these leaks will consist more of persuading folks about these issues, more than exposing an additional stack API
19:45
<Mathieu Hofman>
I believe we/tc39 keep forgetting that some changes may have visible impact through stack information
19:45
<Mathieu Hofman>
because stacks are not currently defined anywhere in ecma262
19:46
<littledan>
my point is, you're misanalyzing the causation there
19:46
<littledan>
causality? cause?
19:46
<Mathieu Hofman>
today on the call, noone was sure of the content of the stack property for an error contructed during evaluation of dynamically imported module
19:48
<Mathieu Hofman>
we all somewhat agreed that having potentially different evaluation behavior based on the dynamic import stack would be weird
19:48
<littledan>
if we add an additional stack API, the existing ones will continue to exist, so it wouldn't really resolve that...
19:49
<Mathieu Hofman>
I think it'd provide a place to explicitly discuss and eventually agree on what stack frames should reveal or not
19:50
<littledan>
well, it would risk being ambiguous if we don't know whether it applies to the existing APIs. Anyway, the first thing we'll need to do in that discussion is resolve exactly that persuasion/ideological issue I mentioned.
19:52
<Mathieu Hofman>
fair