I love the idea of using CSP for this, especially because it handles things
that our whitelist intercept code can't, like <video> tags and WebSockets.

The problem that I've found with it is that we can only enforce it for
single-page apps. We can inject our own CSP headers into the application's
start page very easily, but if the user can leave that page and load
another, then the headers will no longer apply. The WebView interface won't
let use add headers to subsequent pages, so it's up to the developer to
include them in a <meta> tag instead. (and malicious attackers, of course,
won't)

For now, I would encourage devs to include that <meta> tag on *all* of the
pages in their apps, but we can't do it automatically.

If it turns out that we can, then I'd be on board with including that in
the 4.0 branch. It's a much better way to do it. Then we'd only need the
second whitelist for launching intents, I think.

Ian


On Tue, Aug 12, 2014 at 11:48 AM, Parashuram Narasimhan (MS OPEN TECH) <
[email protected]> wrote:

> Had a quick question on the whitelists. I remember that there was talk of
> using CSP to fix this issue. A CSP file may not be backward compatible, but
> could potentially just give us one list instead of 2 whitelists. The CSP
> file may be like the following
>
> Content-Security-Policy:
>         script-src 'self', foo.com, bar.com
>         img-src cdn.com
>         intent-src mail, sms
>
> Note the new intent-src directive, that is basically used to launch
> external programs. Do you think this could be something we can look at, for
> 4.0 ? I am not sure if our whitelist xml file maps to a W3C spec, but CSP
> seems more like a standard. This is breaking, and 4.0 may be the right time
> to do it ?
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Ian
> Clelland
> Sent: Tuesday, August 12, 2014 8:30 AM
> To: [email protected]
> Subject: Re: [Discuss] 3.6.0 Release
>
> I've created CB-7291 for the whitelist issue, and I've ported the code
> from June to the new-style configuration architecture and committed it to a
> named CB-7291 branch on cordova-android.
>
> If anyone has any thoughts/opinions on the syntax or the proposal itself,
> or on what the defaults should be for new and upgrading applications,
> please chime in on the issue.
>
>
>
> On Mon, Aug 11, 2014 at 11:26 AM, Parashuram Narasimhan (MS OPEN TECH) <
> [email protected]> wrote:
>
> > I think we should also finalize on the platform switches so that we
> > all agree on a pattern (even if it is different across platforms).
> > This way, we can release 3.6.0 with a set of switches, and ensure that
> > it is backward compatible.
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Ian Clelland
> > Sent: Monday, August 11, 2014 8:00 AM
> > To: [email protected]
> > Subject: Re: [Discuss] 3.6.0 Release
> >
> > I'll see about committing that today; I've had to reorganize it quite
> > a bit after the Big Config Refactor.
> >
> > Joe, I'm pretty certain that your code is still in master, but
> > definitely add those tests to make sure, and to make sure we don't
> regress.
> >
> > Ian
> >
> >
> > On Mon, Aug 11, 2014 at 10:52 AM, Marcel Kinard <[email protected]>
> > wrote:
> >
> > > I agree with Joe.
> > >
> > > On Aug 11, 2014, at 10:02 AM, Joe Bowser <[email protected]> wrote:
> > >
> > > > Let's not release until the new whitelist is figured out.  That
> > > > feature
> > > is
> > > > too important.
> > >
> >
>

Reply via email to