| 10:49 | <annevk> | yoav: should stuff like https://github.com/WICG/cross-origin-embedder-policy be archived? |
| 10:49 | <annevk> | (I would file an issue but can't) |
| 10:57 | <yoav> | Weird that you can't file one... I'll look |
| 11:00 | <yoav> | someone turned off issues on that repo... |
| 11:00 | <yoav> | I'll bug people and see if we can archive. Thanks for flagging! |
| 11:00 | <annevk> | To be clear, I understand why they disabled issue filing |
| 11:01 | <annevk> | Thanks! |
| 12:34 | <annevk> | MikeSmith: do we still need the test-mdn-annotations branch on https://github.com/whatwg/html-build/branches? |
| 12:34 | <MikeSmith> | annevk: nope |
| 12:34 | <MikeSmith> | feel free to delete it |
| 12:34 | <annevk> | done |
| 12:56 | <annevk> | https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-06#section-5.2.2.2 is somewhat weird to me. So A2 in A1->B->A2 is cross-site, but A2's service worker is not... If service worker adoption would be universal, it seems you could do the same kind of attacks... |
| 13:01 | annevk | files https://github.com/httpwg/http-extensions/issues/1288 |
| 15:19 | <annevk> | Domenic: sorry, I'm actually no longer sure a worklet needs a reference to anything |
| 15:20 | <annevk> | Domenic: we just call it to do something and then it returns a value |
| 15:20 | <annevk> | Domenic: and when we're done with it we discard it |
| 15:20 | <Domenic> | Hmm |
| 15:20 | <annevk> | Domenic: even the secure context check seems weird as they shouldn't even be instantiated if that's false? |
| 15:20 | <Domenic> | annevk: in the worklets spec today there is no securecontext requirement |
| 15:21 | <Domenic> | annevk: it looks like the CSSWG prefers no secure context requirement but Chrome implemented it as SecureContext |
| 15:21 | <annevk> | Domenic: Mozilla wants that too, although I'm not a 100% on what we did for audio worklets |
| 15:21 | <annevk> | I think they are restricted |
| 15:21 | <Domenic> | Cool, yeah, we should probably change that when incorporating |
| 15:22 | <Domenic> | annevk: The current model creates worklet agents (1) when you call addModule(), if there are no agents, and optionally even if there are; (2) on UA discretion when it needs them, e.g. as in https://whatpr.org/html/6056/worklets.html#worklets-example-registering |
| 15:22 | <annevk> | But yeah, thinking about it more a worklet having a reference to the outside by default is a bit of a smell as they are designed as isolated environments (again, specific types of worklets can override that and audio worklets have a communication channel) |
| 15:23 | <Domenic> | annevk: the issue is how do we shut down worklets when you discard a document. I guess you are thinking a document -> all worklets pointer, instead of the inverse? |
| 15:24 | <annevk> | Domenic: yeah, or document->agent->agent cluster->worklet agents |
| 15:24 | <Domenic> | Hmm |
| 15:24 | <annevk> | I think there's only ever one window agent per agent cluster, but this falls flat when dedicated workers can have a worklet |
| 15:24 | <Domenic> | They currently cannot; it's [Exposed=Window] |
| 15:25 | <Domenic> | Did we put worklets in the window agent cluster? |
| 15:25 | <annevk> | I'm not sure that's formalized, it was one of the somewhat open questions |
| 15:25 | <annevk> | It's needed for audio worklets |
| 15:25 | <Domenic> | It looks like we did |
| 15:25 | <annevk> | Other worklets could potentially also sit in their own agent cluster |
| 15:25 | <Domenic> | They don't get isTopLevel |
| 15:26 | <annevk> | Yeah true, but they could in theory is what I'm saying, there's nothing binding them |
| 15:26 | <Domenic> | Yeah |
| 15:26 | <Domenic> | document -> worklets pointer seems fine |
| 15:26 | <Domenic> | Honestly that would be better for workers too |
| 15:26 | <Domenic> | Right now "discard a Document" is pretty backward, it says something like "all workers whose owner document is this document" |
| 15:27 | <annevk> | Yeah I don't like that |
| 15:28 | <Domenic> | AudioWorklet looks to be SecureContext in Firefox too https://searchfox.org/mozilla-central/source/dom/webidl/AudioWorklet.webidl |
| 15:28 | <annevk> | \o/ |
| 16:19 | <Domenic> | annevk: I think https://github.com/w3c/css-houdini-drafts/issues/843 can be closed? |
| 16:20 | <Domenic> | Now that we have one event loop per agent, it's pretty clear they have their own event loop. And it's also clear it may interleave with (instead of being parallel to) a window's event loop, or whichever, but that's already allowed for all non-[[CanBlock]] cases. |
| 16:21 | <annevk> | Domenic: what runs the event loop though? Does create a worklet do that? |
| 16:22 | <annevk> | Domenic: and does the event loop algorithm need worklet-specific steps similar to what it does for workers? |
| 16:22 | <annevk> | (to be clear, I haven't thought about the second question much at all) |
| 16:22 | <Domenic> | I guess we should add a counterpart sentence like workers' "Event loop: Run the responsible event loop specified by inside settings until it is destroyed." |
| 16:22 | <Domenic> | That's easy enough. |
| 16:23 | <Domenic> | Oh wait, it already exists |
| 16:24 | <Domenic> | https://whatpr.org/html/6056/worklets.html#create-a-worklet-global-scope (but it is misnested) |
| 16:27 | <Domenic> | It looks like no need for worklet-specific steps in event loop processing model. However, we should explicitly state that when you terminate a worklet, its event loop gets destroyed. For workers the event loop processing model checks that every time (which is a bit strange). |
| 16:37 | <annevk> | Cool, I'll do a more detailed read tomorrow |
| 16:37 | <annevk> | I should probably start with the PR Preview version as that's just much easier |
| 16:46 | <Domenic> | Yeah definitely |
| 17:13 | <shu> | Domenic: i got a few naive questions about worklets if you got a min |
| 17:14 | <Domenic> | shu: for sure |
| 17:15 | <shu> | Domenic: the encouragement for idempotence in the worklet spec has no normative teeth, is that right? |
| 17:15 | <shu> | currently, that is |
| 17:15 | <Domenic> | shu: indeed. |
| 17:15 | <shu> | judging by your (3) prohibiting `eval('this')`, i imagine currently `eval('this')` actually returns the global? |
| 17:16 | <Domenic> | shu: I didn't test implementations, but it does in specs. "global this value" is left as its default (= global) when creating the realm. |
| 17:16 | <shu> | Domenic: gotcha, thanks. |
| 17:21 | <shu> | this seems to be the same problem as freezing all inadvertent "side channels", which is, as you know, pretty difficult to plug. jumping through hoops to remove the obvious ways to access the global is only a portion of the API surface where the author can accidentally end up depending on persistent global state |
| 17:22 | <shu> | e.g., stuff added to built-in protos |
| 17:23 | <Domenic> | shu: for sure. The intention was always just to avoid obvious easy footguns, not to be airtight. |
| 17:23 | <Domenic> | From that perspective I guess prohibiting `eval('this')` is not really a win. |
| 17:24 | <shu> | okay, i see |
| 17:24 | <Domenic> | But e.g. I think the hope is that you wouldn't be able to use some isomorphic library which relies on globalThis to store global state |
| 17:25 | <Domenic> | I'm not sure how we feel about polyfills... |
| 17:25 | <shu> | yeah, that came to mind as a primary concern |
| 17:26 | <shu> | in practice i think you're saying "don't polyfill", since polyfilling everytime goes against the performance reasons you're using worklets to begin with, i imagine |
| 17:28 | <Domenic> | Yeah, I suspect that was the intention |
| 17:29 | <Domenic> | (HTML is inheriting this spec from the original authors, so I am not 100% on much of this.) |
| 17:35 | <shu> | thanks for the background |
| 17:35 | <shu> | i think right now, given the intention of plugging the obvious badness, i like the idea of shallow freezing the global object the most |
| 17:39 | <Domenic> | Yeah that sounds pretty nice. Let's see what folks say. |
| 23:16 | <innovati> | Was XML5 ever an official proposal or just a dream spec kind of thing? https://ygg01.github.io/xml5_draft/ |
| 23:20 | <Domenic> | The latter |
| 23:22 | <innovati> | Thanks Domenic :D |
| 23:44 | <Domenic> | It might be implemented in Servo now that I think harder |