W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: CfC: Republish MIX as CR; deadline July 29th.

From: Mike West <mkwst@google.com>
Date: Thu, 30 Jul 2015 12:26:26 +0200
Message-ID: <CAKXHy=eQmf3ko265XKSkv6K3fAVJ5fZ7cxHoKdTMPPgxpUrdMg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <hillbrad@gmail.com>
On Thu, Jul 30, 2015 at 12:11 PM, Anne van Kesteren <annevk@annevk.nl>

> On Thu, Jul 30, 2015 at 12:01 PM, Mike West <mkwst@google.com> wrote:
> > That said, it doesn't seem to me that the property we're looking for
> > actually conflicts with "destination context". Aren't they the same
> thing?
> > That is, they both seem to say "Go execute Fetch. Oh, and by the way, we
> > intend to use the response in this particular way."
> Well, except the idea with "destination context" was that we'd only
> use it for prioritization and `Accept` header initialization. Not
> security checks. Since otherwise I could fetch something in a document
> and bypass connect-src by saying it's for an "image" and then feed the
> response to a <script>. Or some such.

I see. Yes, that's a very relevant distinction. :)

Still, examining the `window` and `client` property sees like a strange way
of asking "Is this a passthrough request?" One way of dealing with that
indirection is to bake it into Fetch. Another is to rewrite the algorithm
in MIX to make more sense. It sounds like you'd prefer the latter, Anne.

Splitting out "Is this a passthrough request?" into a separate algorithm
would at least allow us to make the expected invariants explicit, which
seems like an improvement over the current prose.

I'll see what I can do about that.

Received on Thursday, 30 July 2015 10:27:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC