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

On Thu, Jul 30, 2015 at 11:40 AM, Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Thu, Jul 30, 2015 at 10:39 AM, Mike West <mkwst@google.com> wrote:
> > That's not what I think we agreed on. If it was, the discussion around
> > `window` and `client` would have been shorter and simpler. :)
>
> Come to think of it, it wouldn't work, since you have no reference to
> a window in those cases. However, it was one of the use cases people
> had, for podcast applications and such.
>

Right. I think we'd agreed that having a window in which to display UI is
an important aspect of allowing "optionally-blockable" mixed content.
Without a reference to a window, allowing arbitrary requests seems like a
bad decision. Hence the compromise.

I'm sure folks like podcast applications would love to be able to request
audio data from an insecure server in the background. I don't think we can
support that use case with the kinds of restrictions we want to enforce.

> In the case where I'm passing a request through from a document, the
> > incoming Request's `context` will be something like `image`, and the
> Service
> > Worker will copy that Request object and pass it to `fetch()`, which
> sets a
> > `context` to `fetch`. Rather than examining the `window` attribute to
> see if
> > this is a kind of `fetch` we should allow or deny, we can set some
> > `originalContext` (or whatever) attribute on the new Request to `image`,
> and
> > check that when evaluating the outgoing request. That seems simpler than
> the
> > current language in the spec, and less likely to inadvertently change in
> the
> > future.
>
> I think the window bit is the most important aspect though, since it's
> what influences whether or not we can show UI. That, combined with
> mode being "no-cors". "originalContext" captures neither and would be
> confusing with suggested features such as "destination context" (see
> Fetch GitHub issues) and such.
>

I can get behind that explanation: having a `window` property means we have
place to display UI for insecure requests, and allows us to make different
decisions about contexts than we would otherwise.

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."

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)