Re: Next steps for Fetch Metadata

Thanks Anne, Dan.

On Thu, Jan 9, 2020 at 11:52 AM Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jan 8, 2020 at 7:48 PM Daniel Veditz <dveditz@mozilla.com> wrote:
> > There was overwhelming support for us to publish something so it's
> described (at least as a concept) in one place. I couldn't tell how
> strongly people felt about whether it needed to be normative or whether a
> non-normative NOTE would be OK. (Personally I'd be happy either way.)
>
> I'm okay with Fetch calling "set the Fetch metadata headers for a
> request" and adding the new request boolean.
>

I'll send you a patch.

More generally, I wonder if you have opinions about the boundary points
where this kind of split makes sense. If it makes sense for Fetch Metadata,
would it have made sense for Cross-Origin-Resource-Policy? This isn't the
last time we're going to run into the question, and I wonder if there's
some sort of hybrid model we could come up with that might make sense for
these integrated-but-distinct concepts orbiting HTML and Fetch.


> (A concern I have with the growing number of WebAppSec specifications
> is maintenance. Keeping things external is nice as it simplifies
> maintenance of the main module, but some upkeep has to be done. And
> currently even "internal" dependencies such as SRI depending on CSP
> bits get out of sync. In part this can be helped by better tooling,
> but periodic review and editing would also help.)
>

I share this concern, and am probably responsible for much of the failure
in this area. It seems like something that tooling can help with, however,
as many issues are actually visible via Bikeshed's complains when an
algorithm's name changes or it disappears entirely.

It might be interesting to put together some sort of CI system that
compiles all the specs this group is responsible for on each change to HTML
or Fetch, given the tight integrations between them. Perhaps such a thing
already exists?

-mike