W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2020

Next steps for Fetch Metadata

From: Mike West <mkwst@google.com>
Date: Wed, 8 Jan 2020 17:14:49 +0100
Message-ID: <CAKXHy=d0rre=tF9uMd_F+nkRkOsJ1RFnjc1Yv8SVSLnxq9LW1A@mail.gmail.com>
To: Web Application Security Working Group <public-webappsec@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Jeffrey Yasskin <jyasskin@google.com>, Artur Janc <aaj@google.com>, Francois Marier <francois@brave.com>
Hey folks!

On the last call, we discussed next steps for Fetch Metadata
<https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-12-17-minutes.md#fetch-metadata-httpsw3cgithubiowebappsec-fetch-metadata>.
IMO, the spec is pretty much finished, and I think it's time to start
merging some normative bits into Fetch. I think we can do so in a few ways,
and I'd like y'all's opinions on the subject.

On the one hand, this mechanism is pretty clearly and tightly integrated
with Fetch. It would be unfortunate for folks to need to hop back and forth
between `request.destination`'s definition in one spec and usage in
another. With this in mind, it might make sense to move all the normative
text to Fetch and call it a day.

On the other hand, I personally appreciate having separate documents for
separable concepts, which can go into a bit more detail about how the thing
works, why it works that way, and why developers should care. With this in
mind, it might make sense for Fetch to link to Fetch Metadata as it does
for CSP or MIX. Or it might make sense to copy the normative text into
Fetch, and publish Fetch Metadata as a standalone NOTE rather than REC.

We talked a bit about this in https://github.com/w3c/webappsec/issues/550 when
adopting the spec as a deliverable for this group, and I think it's
probably time to revisit the discussion.

What seems like a reasonable next step to folks in this group?

CCing +Anne van Kesteren <annevk@annevk.nl>, +Jeffrey Yasskin
<jyasskin@google.com>, +Artur Janc <aaj@google.com>, and +Francois Marier
<francois@brave.com> specifically, as they all weighed in on that original
thread.

Thanks!

-mike
Received on Wednesday, 8 January 2020 16:15:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:10 UTC