Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of bowserj@gmail.com designates
 209.85.128.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADVgkyPnxE_HDtqjUF=CKfmkVCJOsVS6povCOkbgLoT8k1aG8w@mail.gmail.com>
References: 
 <CADVgkyNN3EKT4xiRXJFbwMGFhsrVF3kHQRzd3exvb5nW7_GdfA@mail.gmail.com>
	<CAE6O_-Y=BSCXANSexYw1t6KDVqKyivBGwKvwYiPs4+N9WFaj3w@mail.gmail.com>
	<CAK_TSXLXzA9etr2wrpnqWVZrj3TYPinH0E0bPKYXUufimcZk2g@mail.gmail.com>
	<CABiQX1UKUuOCnUJuEQv5_MxDm2=f5Wk0-GoJgW1DEWMbnownNA@mail.gmail.com>
	<CADVgkyPnxE_HDtqjUF=CKfmkVCJOsVS6povCOkbgLoT8k1aG8w@mail.gmail.com>
Date: Tue, 8 Jul 2014 09:54:23 -0700
Message-ID: 
 <CAOBL_k7n7+aF4T1hXqc7WrEvKObdfnJW4CEq+NRoH4dy2aoN5Q@mail.gmail.com>
Subject: Re: whitelist as a plugin
From: Joe Bowser <bowserj@gmail.com>
To: dev <dev@cordova.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm in agreement with Andrew on this one.  If we can get CSP working,
that's a far better solution than our Whitelist, which was done
because it was needed at the time for the enterprise use case that IBM
had.  I don't think we're ever going to stop are users from doing dumb
things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
their apps any time soon, but they'll have to jump through more hoops
to do dumb things, and making dumb things harder is a good thing.

On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux <b@brian.io> wrote:
> Heh. Why do we always seem to be at the opposite end of considerations?
> (Not a bad thing anyhow. ;)
>
> So making whitelist a plugin would most certainly isolate the code which
> would help us better understand:
>
> 1.) where the surface for bugs are (we seem to miss/find new security hol=
es
> each quarter=E2=80=A6)
> 2.) if people actually use it
>
> I'm more interested in #2. I suspect the only people whom do use it are
> security researchers disproving the whitelist veracity. I feel this API w=
as
> a mistake, is misleading, and ultimately leads to poor web security
> practices wrt 3rd part scripts. I'd like the evidence to remove it
> completely and making it a plugin would do that. (And still allow for its
> existence to those whom want to contribute to a "marketing" based api.)
>
>
>
> On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve <agrieve@chromium.org> wrot=
e:
>
>> I don't think moving the whitelist to a plugin would aid in its
>> understanding. Right now the whitelist is used for two things:
>>
>> 1. Whether to allow network requests through (although this is broken fo=
r
>> <audio>/<video> on iOS, and broken for them + websockets on Android
>> 2. Whether to allow top frame navigations (e.g. clicking a link to http:=
//
>> *
>> opens in system browser vs. webview)
>>
>> #1 doesn't work very well due to technical limitations.
>> #2 is actually the more import one security-wise I think, and I don't th=
ink
>> should be relegated to a plugin.
>>
>> I'm hoping medium-term that CSP can replace the use-case of #1.
>>
>>
>> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland <iclelland@chromium.org>
>> wrote:
>>
>> > What would be the security implication of removing it from core? No
>> access
>> > at all by default? Or unlimited access by default?
>> >
>> > I suspect that if the default policy with no plugin installed is the
>> > latter, then we will be given the impression that it's not important a=
t
>> all
>> > :)
>> >
>> > I had considered just turning the whitelist settings into a plugin --
>> > either leaving the default rules as they are, and writing a
>> > "cordova-security" plugin that locks it down, or tighten everything by
>> > default, and tell people to install "cordova-plugin-insecurity" if the=
y
>> > want to open it up :)
>> >
>> > I like the idea of making the entire whitelist architecture into a
>> plugin,
>> > though. If nothing else, it should be easier to reason about it, and
>> easier
>> > to fix or replace it in the future if we need to.
>> >
>> >
>> > On Mon, Jul 7, 2014 at 3:55 PM, Shazron <shazron@gmail.com> wrote:
>> >
>> > > Actually it's already possible in any iOS version, we just have to
>> > > make sure the plugin loads at startup. This is for UIWebView only,
>> > > WKWebView has this issue:
>> > > https://issues.apache.org/jira/browse/CB-7049 - you can't intercept
>> > > any requests from it currently (not sure if anything changed in iOS =
8
>> > > beta 3)
>> > >
>> > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux <b@brian.io> wrote:
>> > > > Was discussing this w/ Shaz and Joe and, in theory, this is possib=
le
>> > from
>> > > > iOS8 onward and possibly w/ some refactoring in the 4.x series of
>> > > Android.
>> > > >
>> > > > Its also probably the single most problematic areas of
>> misunderstanding
>> > > as
>> > > > it relates to security we have. Isolating it from core would give =
us
>> a
>> > > > better picture of how important it truly is.
>> > > >
>> > > > Thoughts?
>> > >
>> >
>>