TC39 General on 2023-04-14

08:28	<annevk>	Is anyone still researching base64 utilities?
09:06	<Ashley Claymore>	bakkot updated the base64 proposal just last week. https://tc39.es/proposal-arraybuffer-base64/
10:25	<annevk>	Thanks, it seems that has the relevant issues that need to be solved as well
10:26	<annevk>	I'm getting closer to understanding (and improving) how WebKit handles all of this which should help eventually driving those to some resolution
15:45	<bakkot>	I am hoping to bring it for stage 2 next meeting
15:46	<bakkot>	currently leaning towards, the decoder will be lenient in accepting whitespace / not enforcing `=` padding, and the encoder will be strict in not producing whitespace and always producing `=` padding
15:46	<bakkot>	and then maybe not having options for those, unless there's a compelling case made
15:46	<bakkot>	I was originally planning on having options for how to handle whitespace and `=` but they're probably not actually necessary
16:51	<annevk>	bakkot: what I'm learning in WebKit thus far is that the options differ between base64/base64url
16:51	<bakkot>	fascinating
16:51	<annevk>	bakkot: only base64 has a lenient decode mode of sorts compatible with atob/data: URLs
16:52	<bakkot>	also, some places (possibly including the CSP spec?) allow "mixed" decoding, where you can just mix characters from either alphabet, which I am not current planning to support because, gross
16:52	<annevk>	Which also kinda matches what I've seen in standards, though I haven't tested base64url endpoints myself
16:53	<annevk>	I thought CSP relied on comparing the result of encode from our past discussion, but also have never attempted to test myself
16:53	<bakkot>	that is correct but it does a find-replace first
16:53	<bakkot>	https://www.w3.org/TR/CSP3/#match-element-to-source-list step 5.2.5.2
16:54	<bakkot>	so in practice it is equivalent to doing a strict decoding (i.e. enforcing padding) but with mixed alphabet
16:54	<bakkot>	I would also be 0% surprised to find that implementations differ from the spec on that point
16:57	<bakkot>	ok actually I have reminded myself that it's more complicated because the SRI check, unlike the hash-source check, does not include the find/replace step https://github.com/w3c/webappsec-csp/issues/423
16:57	<bakkot>	again this is just the spec, no idea what implementations do
17:02	<annevk>	Yeah, CSP is pretty bad on a number of fronts so maybe not the best place to draw from. Though if you're inclined to sort it out a bit I'd be happy to help
17:03	<bakkot>	I did open a few PRs a couple years back and they got no attention, so I stopped doing that
17:03	<bakkot>	I guess they're conflicting now so clearly someone has done at least some work
17:20	<annevk>	That's unfortunate
17:21	<annevk>	There has been some more maintenance as of late, but nothing spectacular
17:25	<bakkot>	Yeah probably worth trying again
17:26	<bakkot>	There's a lot of specs which could use some love
18:40	<Partime>	Has there been a proposal to support HTTP headers with the (dynamic) module import syntax?
18:54	<Partime>	It would be useful to pass an `Authorization` header than a token in the URL (easily vulnerable).
20:27	<Chris de Almeida>	https://tc39.es/ecma262/#sec-LoadRequestedModules
20:28	<Chris de Almeida>	`import()` expressions never set the `hostDefined` parameter
20:30	<Chris de Almeida>	https://github.com/tc39/proposal-dynamic-import/issues/76
20:32	<Chris de Almeida>	https://github.com/tc39/proposal-dynamic-import/issues/84#issuecomment-855285508 there's what appears to be a workaround here, but I didn't scrutinize it
20:49	<Chris de Almeida>	https://github.com/tc39/proposal-import-attributes
20:50	<Chris de Almeida>	this proposal could conceivably support it, but handling the options is the domain of the browser/runtime
21:49	<Partime>	Thanks Chris de Almeida
21:50	<Chris de Almeida>	happy to help
21:54	<Partime>	happy to help Would the Blob method allow relative imports from the module?
21:55	<Chris de Almeida>	what do you mean?
21:59	<Partime>	The module would be perceived as from the Blob URL, so an `import('../somefile.js')` would break if called from the imported module?
22:07	<Chris de Almeida>	well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative (or absolute) file imports from the url-imported module would be game over... edit: probably game over but thinking through this a bit more, I'm not 100% sure because I've never done this.. I would expect it not to work but, where is `somefile.js` ?
22:10	<Partime>	well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative file imports would be game over Didn't quite get it. Relative urls already work on browsers/node?
22:11	<Partime>	well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative (or absolute) file imports from the url-imported module would be game over... edit: probably game over but thinking through this a bit more, I'm not 100% sure because I've never done this.. I would expect it not to work but, where is `somefile.js` ? Of course on the server, one level above the absolute URL of the prior module.
22:12	<Chris de Almeida>	`../somefile.js` is not a relative url, it's a relative file path. in any case, at this point, I think I need a more complete example because I'm not sure I'm following you
22:13	<Partime>	Sorry. Wrong terming. Let me clarify.
22:16	<Partime>	You've got `https://some-server/script/index.js` with a statement `import stuff from "./lib/some-util.js";` How does this work with Blobs ?
22:16	<Partime>	It wouldn't, whereas it would if you imported directly.
22:29	<Partime>	Anyway I've resorted to query parameters for now.
22:31	<ljharb>	why would credentials in code be less vulnerable than credentials in a query string?
22:31	<Chris de Almeida>	if I understand you correctly, right, that would not work
22:31	<Partime>	why would credentials in code be less vulnerable than credentials in a query string? Didn't get you.
22:31	<Chris de Almeida>	well -- referrer policy can expose the query string
22:31	<ljharb>	you said earlier It would be useful to pass an Authorization header than a token in the URL (easily vulnerable)
22:32	<Chris de Almeida>	presumably the credentials aren't hardcoded... one would hope
22:33	<Partime>	presumably the credentials aren't hardcoded... one would hope Idk who hardcodes JWTs
22:33	<Partime>	you said earlier It would be useful to pass an Authorization header than a token in the URL (easily vulnerable) That's the Bearer auth standard, isn't it?
22:34	<ljharb>	i'm not sure what you mean
22:34	<ljharb>	where would the credentials come from?
22:35	<Partime>	It could come from anywhere? A login? A delegated access token? Does it matter as long the client somehow finds it?
22:35	<ljharb>	ok so you're not suggesting it live in the source code, you just want a way to tag an import as needing an auth header?
22:35	<Partime>	Yeah because not everyone has access to the same scope.
22:36	<Partime>	And instead of loading scripts and only blocking data APIs, I've decided to block the whole thing.
22:38	<Partime>	I could run you through an example, although the site uses a self-signed certificate at the moment and I didn't add the whole auth thing yet.