| 09:33 | <noamr> | annevk: was thinking that there might be an issue with using CORS to protect orientation/resolution - background/other CSS images never send CORS as they don't have a crossorigin attribute. Though those also don't leak anything as they don't have readable dimensions. |
| 09:36 | <annevk> | How careful is the CSSWG about that with the CSSOM I wonder? |
| 09:54 | <noamr> | good question. you might be able to gather those from getComputedStyle(...).backgroundSize |
| 09:56 | <noamr> | it seems like currently you can't - but I doubt that they're aware of this at CSSWG |
| 09:57 | <noamr> | though this kind of makes CORS an unsuitable solution for orientation/resolution IMO, there needs to be something that's purely a response header |
| 10:10 | <annevk> | That makes sense, that might get complex though with redirects |
| 10:30 | <noamr> | yea but that's also true for CORS |
| 10:31 | <noamr> | annevk: I think that a server that wants to protect an image's orientation/resolution from leaking can do so today without changing anything - bake them into the image before serving them and not serve that metadata at all. Adding a response header would allow a new way to do that, but maybe it's redundant. |
| 10:32 | <annevk> | Yeah, but we have the infrastructure in place there. |
| 10:32 | <noamr> | orientation/resolution are kind of an optimization "opt in" and servers have a way to serve the same data without them if they care about that information leakage |
| 10:33 | <annevk> | That servers have ways to mitigate same-origin policy issues is not an argument to not enforce it. |
| 10:34 | <noamr> | it's an argument against creating new ways for servers to mitigate it |
| 10:35 | <noamr> | as maybe the current ways are sufficient, and CORS as enforcing same-origin policy doesn't play well with image geometry |
| 10:36 | <noamr> | I guess an HTTP header would be opt-in instead of opt-out, which would make it less redundant |
| 10:37 | <annevk> | I'm not sure I'm following what you're saying here, but I don't think an argument can be constructed whereby we expose all image metadata because servers could hide it if they cared enough |
| 10:37 | <annevk> | An acceptable argument, that is |
| 10:37 | <noamr> | I wonder how are redirects handled with Timing-Allow-Origin? It sounds almost like a similar problem |
| 10:38 | <annevk> | noamr: yeah, it's handled in Fetch; I guess we could abstract that |
| 10:46 | <noamr> | Thinking something along the lines of Media-Transform-Allow-Origin. Limited to transformation metadata (rotate/scale), not allowing to read GPS etc. which should require CORS |
| 12:57 | <annevk> | Domenic: why do statics use the current global? There's no real this? |
| 14:00 | <Domenic> | annevk: correct |
| 14:03 | <annevk> | Okay, implementations seem to get that right and most other aspects too, except for Safari as noted |
| 15:35 | <annevk> | Domenic: hmm, so how do we state exceptions are created in this's relevant Realm? |
| 15:35 | <Domenic> | annevk: exceptions are created in the current realm |
| 15:35 | <annevk> | They're not |
| 15:35 | <Domenic> | https://heycam.github.io/webidl/#es-creating-throwing-exceptions |
| 15:35 | <annevk> | At least not in my tests |
| 15:36 | <Domenic> | Show me the test? |
| 15:37 | <annevk> | Domenic: https://github.com/web-platform-tests/wpt/pull/24601/files#diff-4f09c53069aab10026cff804ebb984a2R88 |
| 15:37 | <annevk> | Or is that because of the promise? Hmm |
| 15:40 | <Domenic> | annevk: in a simpler example it's definitely current: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8271 |
| 15:41 | <Domenic> | annevk: so if you have a response from the relevant realm, then the current realm at the time `res.json()` runs is the original relevant realm |
| 15:41 | <Domenic> | I.e. since `res` is from `frames[1]` then at the time `res.json()` runs, the current realm is `frames[1]` |
| 15:42 | <Domenic> | You'd need to do `originalCurrentFrame.Response.prototype[method].call(res, ...)` |
| 15:42 | <annevk> | Domenic: okay, so some of those tests are wrong; perhaps that's also why the JSON thing is weird |
| 15:43 | <Domenic> | Yeah, although the JSON thing seems like a spec inconsistency at the very least |
| 15:44 | <annevk> | If browsers end up doing current after all I think we should just let it be though, but... |
| 15:44 | <Domenic> | Probably true |
| 15:46 | <annevk> | Domenic: also, it seems that upon fulfillment doesn't allow stating the realm for that promise |
| 15:47 | <Domenic> | Hmm |
| 15:47 | <annevk> | Domenic: which I guess means it would default to current? |
| 15:47 | <Domenic> | It would default to "current at the time that PerformPromiseThen creates a new promise", i.e. it would default to the same realm as the promise that is sent as input |
| 15:47 | <annevk> | I wish "this" was available to IDL somehow via magic |
| 15:47 | <annevk> | Wait, it is available as IDL passes it in... |
| 15:48 | <annevk> | Can we make new/a new promise/etc. smarter about this? |
| 15:48 | <Domenic> | You mean, allow them to implicitly chose the right realm? See https://github.com/heycam/webidl/issues/135 |
| 15:50 | <annevk> | Ah, that also talks about statics |
| 15:50 | <annevk> | Hmm |
| 15:51 | <annevk> | So now I'm not sure whether to update Fetch to make this all explicit |
| 15:53 | <Domenic> | Fair... might be best to fix IDL. |
| 16:17 | <Domenic> | Ugh GitHub is janky |
| 16:50 | <andreubotella> | annevk: I'm refactoring https://github.com/whatwg/encoding/pull/215 to make streams / token queues a list subtype, and replace "token" by "item" throughout. |
| 16:50 | <andreubotella> | Should I use the name "consumable list" then? |
| 16:53 | <annevk> | andreubotella: yeah I suppose, or I/O list |
| 16:53 | <annevk> | Maybe Domenic has thoughts? |
| 16:53 | <Domenic> | I liked "token queue" |
| 16:54 | <Domenic> | Similar to how "task queue" is a list subtype |
| 16:54 | <Domenic> | (or, rather, is just a list) |
| 16:54 | <annevk> | You don't find it confusing with queue? |
| 16:54 | <Domenic> | No. It's still conceptually a queue. |
| 16:54 | <Domenic> | Even if it's not "implemented" that way. |
| 16:54 | <annevk> | queues don't have prepend though |
| 16:55 | <andreubotella> | I was thinking of prepend as an internal operation, since we have an appendix listing alternative ways to implement it |
| 16:55 | <andreubotella> | so maybe that's fair |
| 16:56 | <MikeSmith> | annevk: deque |
| 16:56 | <annevk> | I also don't really understand why we'd call it "token" here and not "item" |
| 16:57 | <andreubotella> | maybe I/O queue? |
| 16:57 | <annevk> | If it's really just a list it doesn't really need a separate name as it doesn't belong to anything |
| 16:57 | <annevk> | But given read it's probably useful |
| 16:58 | <annevk> | andreubotella: yeah I guess that's fine if nobody minds the specifics of queue |
| 18:11 | <andreubotella> | is `ioQueue` an acceptable variable name? `IOQueue`? |
| 18:27 | <Domenic> | andreubotella: `ioQueue` sounds good |
| 20:32 | <Domenic> | data: URLs really get their own agent? |