| 06:43 | <annevk> | hsivonen: I'm curious if you have thoughts about https://github.com/annevk/orb/issues/7#issuecomment-933275068. The context here is that we get a response from the network, attempt to parse it as JavaScript in some utility process, and then only if that succeeds, we let it enter the content process. For maximum compatibility we'd have to forward the encoding along with the request, but that also means attackers might be able to get more things to parse as JavaScript (in theory). Given that most of the syntax is ASCII, is that a problem? Is UTF-16 a problem? (Anyone else who has thoughts is of course also welcome to share them.) |
| 07:46 | <Noam Rosenthal> | Hi annevk. I'm contemplating about the HTML/fetch integration with resource timing. Most of the resources there load the entire resource at once, e.g. creating a source text for a script from a response body. Should they be using process response end-of-body, or is that reserved for fully synchronous things such as sync XHR and they should use process response? |
| 07:49 | <annevk> | Noam Rosenthal: I think it would be fine for them to use that, yes |
| 07:50 | <annevk> | Noam Rosenthal: all the callbacks are "async" and don't block the main thread; the only thing is that would imply stuff isn't processed incrementally, but implementations are allowed to do that under the covers, as long as it's not observable directly (observing via better perf is fine) |
| 07:51 | <annevk> | https://infra.spec.whatwg.org/#algorithm-conformance talks a bit about that after the example. |
| 07:55 | <Noam Rosenthal> | gotcha, thanks annevk |
| 16:30 | <timothygu> | Do we know who triple-underscore is and how they have so much time translating specs? |
| 16:33 | <annevk> | timothygu: I think they have some kind of system in place for translation that makes it more straightforward, but no, I don't know |
| 16:33 | <annevk> | timothygu: they're also very good at spotting mistakes with recent changes |
| 20:08 | <timothygu> | annevk: I'm trying to understand the reason why we don't allow URLs to change scheme from special to non-special through the protocol setter. https://github.com/whatwg/url/commit/5533c8d91e17fc81fc8a16a16af9155bf940aca8 says it's to support relative non-special URLs, but I'm not sure how it factors into special to non-special |
| 20:09 | <timothygu> | And similarly, what's bad about allowing new URL(schm://host.com/hello).protocol = 'http'? |
| 22:05 | <jschoi> | timothygu: I think they have some kind of system in place for translation that makes it more straightforward, but no, I don't know What a mysterious character… |