| 06:39 | <mkwst> | annevk: The two prongs of https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-00#section-4.2 are the fundamental disagreement. |
| 06:39 | <mkwst> | annevk: The latest round of the discussion starts at https://www.ietf.org/mail-archive/web/dnsop/current/msg20963.html. |
| 06:40 | <mkwst> | annevk: The discussion group question is probably answered in https://tools.ietf.org/html/rfc7322. :) |
| 07:37 | <mkwst> | annevk, tobie: Ping! I haven't actually run https://github.com/mikewest/tc39-proposal-literals/blob/master/README.md by V8/TC39 folks yet to see if their heads explode, but WDYT about it from a WebIDL perspective? |
| 08:06 | <tobie> | mkwst: would that create a new WebIDL string type? |
| 08:07 | <mkwst> | tobie: I think that'show we'd need to do it. I'm very open to other options, though, if you have different ideas! |
| 08:09 | <tobie> | mkwst: so we'd be able to tighten security requirements for DOMString for new APIs. But not do much for old ones unless folks opted in via CSP or what not, right? |
| 08:11 | <tobie> | mkwst: do `strings` fall in the literal category too (I imagine not)? |
| 08:16 | <tobie> | mkwst: might also be worth talking to the React folks who've been working around this space with https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml |
| 08:19 | <tobie> | mkwst: that said, it seems this is quite restrictive in its application, no? It's basically strings that are part of the UI layer on apps that aren't designed to be translated, right? |
| 08:33 | <annevk> | mkwst: would "x" + "x" also throw? |
| 08:34 | <annevk> | mkwst: if TC39 would add such a language feature I see no reason for us not to accommodate |
| 08:47 | <mkwst> | (Sorry, ran off to get a flu shot) |
| 08:48 | <mkwst> | tobie: It is restrictive. That's more or less the idea. *shrug* Google's security team tells me that the majority of `SafeHtml` instantiations in Google's production code is string literals. |
| 08:48 | <mkwst> | It surprises me, but I don't have much reason to doubt them. :) |
| 08:49 | <mkwst> | annevk: Closure's compiler deals with `"x" + "x"`. If we can do the same, great. If that turns out to be hard, I'm sure we could live without it. |
| 08:51 | <tobie> | mkwst: just to be clear, this implies these strings are statically analysed to be safe? |
| 08:51 | <tobie> | mkwst: (I think I'm not super clear as to what threat we're trying to mitigate against.) |
| 08:51 | <mkwst> | tobie: In some cases, yes (e.g. HTML strings are statically determined to be valid HTML without dangling markup). |
| 08:52 | <mkwst> | In other cases, reviewers will look at them with their eyeballs. |
| 08:52 | <mkwst> | Either way, analyzing a static string is simpler than analyzing an HTML sanitizer, and we can make reasonable decisions about the risk a given string literal presents. |
| 09:07 | <annevk> | mkwst: I guess I'm more curious about the TC39 proposal than the IDL one |
| 09:07 | <annevk> | mkwst: since that seems potentially far more controversial |
| 12:20 | <domfarolino> | annevk: Request domintro nit addressed |
| 12:23 | <Domenic> | mkwst: my prediction is that you'll get pushback of the form "this should be solved by a static analysis tool like TypeScript" |
| 12:24 | <mkwst> | annevk: Ah, sorry I missed this earlier. Yes. I imagine the TC39 side will be harder. I'm hoping to convince the V8 team to fall on that particular sword for me. :) |
| 12:24 | <annevk> | domfarolino: landed |
| 12:24 | <mkwst> | Domenic: That pushback is reasonable, it's what Google does today. |
| 12:24 | <annevk> | (and thanks!) |
| 12:25 | <mkwst> | But it would be significantly more effective if we built it into the platform. *shrug* I'm happy to have that discussion. |
| 12:25 | <annevk> | I wonder how many people realized wasm came with non-detachable ArrayBuffer objects |
| 12:25 | <annevk> | That seems like a fairly major change |
| 12:26 | <Domenic> | mkwst: was there a plan to use a template string tag for trusted types? I thought I saw that, and it seemed so nice. |
| 12:27 | <mkwst> | Domenic: Yeah. That's on the list somewhere. I think koto built a prototype, even. |
| 12:27 | <mkwst> | It does look really nice. |
| 12:27 | <Domenic> | Cool, looking forward to seeing more of that |
| 22:48 | <KiChjang_> | how many ways can you supply credentials when performing a fetch? |
| 22:49 | <KiChjang_> | i know that using the URL works, username:password⊙ec |
| 22:49 | <KiChjang_> | there's also the Authentication header |
| 23:44 | <MikeSmith> | KiChjang_: TLS client certificates |
| 23:44 | <MikeSmith> | and username:password⊙ec won’t work with the fetch API |
| 23:44 | <KiChjang> | huh |