| 09:08 | <annevk> | Eric Meyer: bkardell: sounds good. It might be that DOM should provide some helper terms here as thus far the flattened tree has been mostly a layout affair, but aspects of it are observable through events (iirc) |
| 09:12 | <annevk> | Eric Meyer: bkardell: https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A4 and https://dom.spec.whatwg.org/#ref-for-get-the-parent%E2%91%A6 highlight the important differences in terms of traversal |
| 19:04 | <Andreu Botella (he/they)> | I was under the impression that the only way to get a document to be decoded as UTF-16 was with a BOM, since <meta charset> can't be used to switch into/out of UTF-16 |
| 19:04 | <Andreu Botella (he/they)> | but I was completely forgetting the charset MIME parameter |
| 19:06 | <Andreu Botella (he/they)> | So, since UTF-16 is ASCII-incompatible, is there a security risk here? Or we can assume that there isn't one, since the server clearly knows it's serving UTF-16? |
| 19:06 | <Andreu Botella (he/they)> | (but then what about the possibility of proxies doing multiple passes on some input?) |
| 21:23 | <Domenic> | I don't think malicious proxies are really in the threat model? A malicious proxy could completely rewrite the input if it wanted to. |
| 21:25 | <Andreu Botella (he/they)> | I wasn't talking malicious proxies, but about the possibility of a chain of servers processing each other's outputs, where an intermediate server doesn't know it's handling UTF-16 but the final one does |
| 21:25 | <Andreu Botella (he/they)> | but that's probably too much of a stretch |
| 21:25 | <Andreu Botella (he/they)> | and not part of the threat model |
| 21:27 | <Domenic> | I'm not really sure myself, so don't take my sentence above as a definitive answer... |