Standardizing request contexts

[Anne van Kesteren]

Hi Doug, Patrick, Boris,

Mike and I are working on defining most things content <> network. One
of those is the context of a request. See:
http://fetch.spec.whatwg.org/#concept-request-context

Some of the ongoing discussion is happening here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26247 Not all of you
have a W3C Bugzilla account unfortunately so I figured I'd email.

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy
suggests we have somewhat less granularity than Chromium / the
specification at the moment, but I'm not sure if that's up to date.

Do we have any plans in this area or do you have concerns about the
existing breakdown in the specification? Contexts will be observable
given CSP, Mixed Content, and will be exposed as string to service
workers.

(Copied dev-platform as experiment. To inform everyone else this is
ongoing. If there's a more suitable Mozilla list when it comes to
standardizing Gecko, please let me know!)

Cheers,


--
http://annevankesteren.nl/

[Boris Zbarsky]

On 7/1/14, 6:06 AM, Anne van Kesteren wrote:
> Hi Doug, Patrick, Boris,

ccing Jonas, since he's been thinking about this a lot recently.

> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy
> suggests we have somewhat less granularity than Chromium / the
> specification at the moment, but I'm not sure if that's up to date.

It's up to date, but Jonas is in the middle of working on a replacement
for that API.

> Do we have any plans in this area or do you have concerns about the
> existing breakdown in the specification? Contexts will be observable
> given CSP, Mixed Content, and will be exposed as string to service
> workers.

The list of possible contexts looks OK to me, I think, except "popup",
more on which below.

I assume it will be the responsibility of whoever invokes a fetch to
specify a context?

What is the process of getting new contexts added as new features are
added to the platform?

So, "popup".

Is <a target="_blank" href="whatever"> a "navigation" or a "popup"?
What about <a target="something" href="whatever">? Does it depend on
whether an existing navigation context with the name "something" exists?
What about window.open("whatever", "something")? What about <form
action="whatever" target="_blank">? Is there a difference between
navigations to _blank target that will be show in new windows vs new tabs?

Basically, why is this a useful request context value?

> (Copied dev-platform as experiment. To inform everyone else this is
> ongoing. If there's a more suitable Mozilla list when it comes to
> standardizing Gecko, please let me know!)

This is the right list, imo.

As long as we're here, is the associated origin of a request related to
the request context or the response? It would be good to make that clear.

Should the default mode be no CORS or CORS? It might make some sense to
have it be CORS... Similar for response tainting.

-Boris

[Doug Turner]

adding tanvi.

On Jul 1, 2014, at 7:20, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 7/1/14, 6:06 AM, Anne van Kesteren wrote:
>> Hi Doug, Patrick, Boris,
>
> ccing Jonas, since he's been thinking about this a lot recently.
>

>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy
>> suggests we have somewhat less granularity than Chromium / the
>> specification at the moment, but I'm not sure if that's up to date.
>

> It's up to date, but Jonas is in the middle of working on a replacement for that API.
>

>> Do we have any plans in this area or do you have concerns about the
>> existing breakdown in the specification? Contexts will be observable
>> given CSP, Mixed Content, and will be exposed as string to service
>> workers.
>

> The list of possible contexts looks OK to me, I think, except "popup", more on which below.
>
> I assume it will be the responsibility of whoever invokes a fetch to specify a context?
>
> What is the process of getting new contexts added as new features are added to the platform?
>
> So, "popup".
>
> Is <a target="_blank" href="whatever"> a "navigation" or a "popup"? What about <a target="something" href="whatever">? Does it depend on whether an existing navigation context with the name "something" exists? What about window.open("whatever", "something")? What about <form action="whatever" target="_blank">? Is there a difference between navigations to _blank target that will be show in new windows vs new tabs?
>
> Basically, why is this a useful request context value?
>

>> (Copied dev-platform as experiment. To inform everyone else this is
>> ongoing. If there's a more suitable Mozilla list when it comes to
>> standardizing Gecko, please let me know!)
>

[Mike West]

On Tue, Jul 1, 2014 at 4:20 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> I assume it will be the responsibility of whoever invokes a fetch to
> specify a context?
>

Yes.

> What is the process of getting new contexts added as new features are
> added to the platform?
>

So far, I've been pinging Anne while working through the Mixed Content and
CSP specs. Not sure if that's scalable. :)

So, "popup". <snip> Basically, why is this a useful request context value?


I think the reason it's there is that we were exploring adding auxiliary
browsing context whitelisting to CSP, similar to what we do for frames. We
were calling them "popups" at the time, but you're entirely correct to say
that tabs would fall into the same category.

It's not clear to me whether we are going to add this functionality to CSP,
nor is it clear that a context is the right way of managing it. Off the top
of my head, we could set an `opener` flag on fetch, distinct from `client`.
If the context is "top-level" or "main frame" or whatever we call it, and
there's a `client`/`opener` mismatch, we could deal with it appropriately.

--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

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

[Anne van Kesteren]

On Tue, Jul 1, 2014 at 4:20 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> What is the process of getting new contexts added as new features are added
> to the platform?

File a bug.

> So, "popup".
>
> Is <a target="_blank" href="whatever"> a "navigation" or a "popup"? What
> about <a target="something" href="whatever">? Does it depend on whether an
> existing navigation context with the name "something" exists? What about
> window.open("whatever", "something")? What about <form action="whatever"
> target="_blank">? Is there a difference between navigations to _blank
> target that will be show in new windows vs new tabs?
>

> Basically, why is this a useful request context value?

Good question. From what I remember the main motivation was having
something distinct from navigating the top-level browsing context. A
service worker might want to know whether it's "app" top-level
browsing context is being navigated or whether it's an auxiliary
browsing context.

> As long as we're here, is the associated origin of a request related to the
> request context or the response? It would be good to make that clear.

A request's origin is set by the API that initiates the fetch. A
response does not really carry an origin.

> Should the default mode be no CORS or CORS? It might make some sense to
> have it be CORS... Similar for response tainting.

Yeah maybe. (The response tainting default value is not really of any
concern. As the note points out it is a bookkeeping detail and not
actually part of the spec-facing API.)


--
http://annevankesteren.nl/

[Boris Zbarsky]

On 7/1/14, 10:54 AM, Anne van Kesteren wrote:
> Good question. From what I remember the main motivation was having
> something distinct from navigating the top-level browsing context. A
> service worker might want to know whether it's "app" top-level
> browsing context is being navigated or whether it's an auxiliary
> browsing context.

So there are a few things to unpack here.

If I do a window.open(), then I now have two top-level browsing
contexts. One of them is auxiliary, one is not, right? Its possible to
then navigate that browsing context via more window.open() calls
targeting that auxiliary browsing context name, anchor clicks in that
browsing context or others, location sets, form submissions, etc.

So if what we really want to know is whether a navigation is associated
with an auxiliary browsing context or not, I think doing that via the
request context isn't a good fit; it's somewhat orthogonal to how the
request is being performed.

>> As long as we're here, is the associated origin of a request related to the
>> request context or the response? It would be good to make that clear.
>
> A request's origin is set by the API that initiates the fetch.

OK. So this is the origin of the thing that triggered the fetch, basically?

> A response does not really carry an origin.

I guess that depends on how you think about redirects. The origin of a
response is determined based on the URI it was actually gotten from,
which may not be the same URI that the consumer passed into fetch
initially, right?

-Boris

[Anne van Kesteren]

On Tue, Jul 1, 2014 at 5:18 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> So there are a few things to unpack here.
>
> If I do a window.open(), then I now have two top-level browsing contexts.
> One of them is auxiliary, one is not, right? Its possible to then navigate
> that browsing context via more window.open() calls targeting that auxiliary
> browsing context name, anchor clicks in that browsing context or others,
> location sets, form submissions, etc.
>
> So if what we really want to know is whether a navigation is associated with
> an auxiliary browsing context or not, I think doing that via the request
> context isn't a good fit; it's somewhat orthogonal to how the request is
> being performed.

https://github.com/slightlyoff/ServiceWorker/issues/352

>> A request's origin is set by the API that initiates the fetch.
>
> OK. So this is the origin of the thing that triggered the fetch, basically?

Yes.

>> A response does not really carry an origin.
>
> I guess that depends on how you think about redirects. The origin of a
> response is determined based on the URI it was actually gotten from, which
> may not be the same URI that the consumer passed into fetch initially,
> right?

Yes. And if you used "no CORS" and you went cross-origin >
same-origin, you end up with a response whose type is tainted.

The idea of this model is that a response only gives access to what
you're allowed to based on the request you made and passed to fetch.
If you have special privileges (such as <img> does) you can get to the
internal response from a response and get the actual bytes out for
displaying (at your own risk). Of course, ideally only legacy APIs do
silly things like that.


--
http://annevankesteren.nl/

[Tanvi Vyas]

On 7/1/14 7:28 AM, Doug Turner wrote:
> adding tanvi.
>
> On Jul 1, 2014, at 7:20, Boris Zbarsky <bzba...@mit.edu> wrote:
>
>> On 7/1/14, 6:06 AM, Anne van Kesteren wrote:
>>> Hi Doug, Patrick, Boris,
>> ccing Jonas, since he's been thinking about this a lot recently.
>>

>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy
>>> suggests we have somewhat less granularity than Chromium / the
>>> specification at the moment, but I'm not sure if that's up to date.

>> It's up to date, but Jonas is in the middle of working on a replacement for that API.

The "content policy types" in
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy#Constants
are mostly up-to-date. We've added a few more:
TYPE_CSP_REPORT
TYPE_XSLT
TYPE_BEACON
http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIContentPolicy.idl#138

The work we are doing on the replacement API doesn't change these
types. Each content policy uses these types, the request origin, and
the requesting origin to determine whether or not the content can be
loaded. Looks like some of these map to
http://fetch.spec.whatwg.org/#concept-request-context, but we are
missing quite a few. As new types are introduced into our code base,
developers are encouraged to create new constants and avoid using
TYPE_OTHER. We can add a followup item to our project to extend these
types and add granularity.

~Tanvi