Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAMNA1niB4ZLmzqHqwZxb1gyFky-5mBN0H0i3nUCEb60xs+c8AA@mail.gmail.com>
References: 
 <CAMNA1niB4ZLmzqHqwZxb1gyFky-5mBN0H0i3nUCEb60xs+c8AA@mail.gmail.com>
Date: Wed, 10 Apr 2013 13:23:09 -0700
Message-ID: 
 <CADVgkyMjfX0ArRNOQAcqUc8Q5+e5HPRnu27piaKCUtaYk_dnkA@mail.gmail.com>
Subject: Re: iOS: The future of whitelisting
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c3864c3a854c04da077098

--001a11c3864c3a854c04da077098
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

We recently moved to * by default to ease common userland woe. I'd be in
favor of removal of whitelisting but I'm fairly certain that would be
a controversial position!


On Wed, Apr 10, 2013 at 11:38 AM, Kevin Hawkins <
kevin.hawkins.cordova@gmail.com> wrote:

> Hey all,
>
> Those of us who have been on the implementing and/or serious consumption
> side of whitelisting for iOS=97I've been on both at one time or another=
=97know
> how much work has gone into trying to make it a full-featured security
> subsystem for the iOS version of the framework.  I want to share some
> feedback based on my organization's experiences in implementation, and
> hopefully spark some discussion about the future of whitelisting on iOS
> (and maybe the platform as a whole).
>
> We're essentially running into insurmountable issues with whitelisting fo=
r
> the use cases we're attempting, based on the overreach of the NSURLProtoc=
ol
> approach to whitelist handling.  I say overreach because, in an ideal
> world, Cordova should only ever care about safeguarding traffic destined =
to
> go through the hybrid/native bridge.  This argument can be made for all
> platforms, but the lack of granularity is most onerously overbearing on
> iOS, which filters every HTTP(S) packet that goes through the app.
>
> Our requirements are very strict with regard to what's whitelisted to go
> through the bridge.  But the bridge is conceptually the only thing we car=
e
> about, within that particular sphere of security.  We have a more relaxed
> sphere of security for, say, <img src=3D"http://maps.google.com" />, as t=
he
> threat vectors exposed through image rendering are considerably less than
> malicious injected bridge code.
>
> Alas, we don't=97and arguably never will=97have that kind of granular con=
trol
> in iOS, with the current implementation approach.  NSURLProtocol is simpl=
y
> too broad-brush to meld into a granular approach for whitelisting.  The e=
nd
> result is that we lose the ability to deliver a rich content experience
> that leverages third party artifacts, because we're forced to go with the
> sphere of security that gives us the highest scrutiny, across the board.
>
> We've been considering (very early phase) some alternative approaches to
> managing whitelisting.  Our current thinking has been focusing on a
> gatekeeper (on the native side) to the bridge itself.  This would enforce
> some sort of contract between the hybrid and native side, to make a
> determination of which traffic is authorized to specifically go through t=
he
> bridge.  I'm not sure what that contract looks like at this point, but
> enforcement would be bridge-specific, and all other webview traffic would
> otherwise behave as it would in a normal web application.
>
> I know from past discussions that many (most?) Cordova developers don't
> generally use the whitelist, since their security concerns may not be as
> great, and/or they exclusively host their app functionality locally to th=
e
> device, which allows them to essentially implement their own controls on
> attack vectors through selective app content.  In our case, we're buildin=
g
> an enterprise platform where content could come from any number of source=
s.
>  And whitelisting controls are not working for us.
>
> If there's a future for whitelisting in Cordova 3.0, I personally feel th=
at
> it needs to be revisited.  I'd be interested to hear thoughts from others
> on their usage patterns, and responses to my concerns.
>
> Cheers,
> Kevin
>

--001a11c3864c3a854c04da077098--