| 00:04 | <domfarolino> | yoav: would you say https://github.com/whatwg/html/pull/3752/files#r269950600 is "resolved", given your latest comment? |
| 04:09 | <domfarolino> | annevk: is there no way to determine the "destination", or resource type of a response? seems you can only get that from request? |
| 04:37 | <annevk> | domfarolino: resource type? |
| 04:39 | <domfarolino> | annevk: Well, I guess I am just wondering if you can get the request's `destination`, from a #concept-response |
| 04:39 | <annevk> | domfarolino: you cannot |
| 04:44 | <domfarolino> | annevk: Ok. Right now a #concept-request can only get its integrity metadata set for a few destinations ("", "style", and "script" from what I can tell). |
| 04:44 | <domfarolino> | To enable `integrity` on rel=preload w/o enabling SRI on a bunch of destinations that SRI currently cannot affect (like "object"), I'm thinking of having SRI spec define a set of "sri-compatible destinations", and having Fetch gate calling into the SRI spec based on whether the destination is "compatible" |
| 04:45 | <domfarolino> | Looks like I can just use request's destination, and pass that to the SRI spec for it to determine whether or not a dest is "compatible" |
| 04:46 | <annevk> | domfarolino: why would we not support it for all with rel=preload? |
| 04:47 | <domfarolino> | https://w3c.github.io/webappsec-subresource-integrity/#verification-of-html-document-subresources mentions that a "future version of this document" would include support, just by tweaking a couple things in the Preload/HTML standards |
| 04:47 | <domfarolino> | Perhaps it'd be sensible to allow SRI verification on destinations that you can preload, if and only if you can perform SRI verification on that destination w/o the preload |
| 04:48 | <domfarolino> | (for example, there's no way of setting an <audio> request's integrity metadata, so maybe we should not honor it on its preload, since SRI spec isn't expecting that atm |
| 04:48 | <annevk> | Why? |
| 04:49 | <annevk> | fetch() supports it, the infra is there |
| 04:50 | <domfarolino> | True...I guess I like the idea of the SRI spec being in control of where SRI verification can take place, since it kind of attempts to do that now |
| 04:50 | <annevk> | Ignoring the infra despite the attribute being set seems likely to lead to issues in the future if we do want more “destinations” |
| 04:51 | <annevk> | domfarolino: if it does that’s dumb, as Fetch and HTML are in control |
| 04:52 | <domfarolino> | ok that makes sense. This note in SRI spec should probably be gone then "Note: A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements." |
| 04:52 | <annevk> | domfarolino: the main callout Fetch has to SRI is about running the check on the response body |
| 04:52 | <annevk> | Unless I’m missing something |
| 04:53 | <domfarolino> | No that makes sense, just I assumed that SRI spec was trying to be in control of where it is supported, given the partial IDL interfaces it has, and the note ^ |
| 06:35 | <annevk> | domfarolino: it having partial IDL seems wrong too |
| 06:36 | <annevk> | domfarolino: unless it’s somehow made non-normative and not indexable, but that might be needlessly confusing too |
| 06:37 | <TimothyGu> | it seems like the right approach is interface mixin + `includes` |
| 06:37 | <TimothyGu> | (right?) |
| 07:02 | <annevk> | TimothyGu: well, I haven't looked but in this case I think it's duplicating HTML as the partial interfaces were upstreamed and integrated there |
| 07:02 | <annevk> | (iirc) |
| 07:03 | <domfarolino> | That is my impression too |
| 12:42 | <TimothyGu> | oh ok |
| 12:54 | <zcorpan> | Hmm whatpr.org versions of the HTML spec don't have link-fixup.js or html-dfn.js |
| 12:56 | <MikeSmith> | zcorpan: I vaguely recall maybe that was intentional, because we don’t actually want people using those drafts for any actual information needs? |
| 13:17 | <zcorpan> | MikeSmith: it makes it harder to review though :-| |
| 13:18 | <zcorpan> | maybe link-fixup isn't necessary to review, but I wanted html-dfn.js now |
| 13:19 | <zcorpan> | Where do I file an issue for this? |
| 13:20 | <Domenic> | zcorpan: MikeSmith: whatpr is only running wattsi, not full HTML build, because we only have a wattsi server, not a html-build server. |
| 13:21 | <Domenic> | Probably best tracked at https://github.com/whatwg/html-build/issues, although I thought we had an issue already; maybe it is somewhere else. |
| 13:22 | <MikeSmith> | ah sorry I realize now whatpr is for pull requests? I was (mis)thinking it had something to with the lawyer drafts |
| 13:23 | <zcorpan> | Domenic: ok. could it just load the URL https://html.spec.whatwg.org/html-dfn.js ? |
| 13:25 | <Domenic> | MikeSmith: yeah just for pull requests |
| 13:25 | <MikeSmith> | k |
| 13:26 | <Domenic> | zcorpan: I think that'd be hard because currently tobie's setup just calls to the web service, but maybe it could work |
| 13:27 | <zcorpan> | Domenic: I mean changing the <script src> in whatwg/html source |
| 13:29 | <Domenic> | Oh, interesting |
| 13:29 | <Domenic> | I guess we could, but I wonder where that stops; do we do it for all the images and such? |
| 13:29 | <Domenic> | I think it also won't work because we don't generate the json file |
| 13:29 | <Domenic> | Or maybe we do, I forget whether that's wattsi or html-build... |
| 13:40 | <MikeSmith> | for the dfn's? |
| 13:40 | <MikeSmith> | wattsi generates the json |
| 14:14 | <zcorpan> | Domenic: I suppose having images would also be nice, but seems less important since images are rare. We already load file-issue.js with an absolute URL fwiw |
| 21:36 | <zcorpan> | TIL http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7001 |