cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <>
Subject Re: iOS: The future of whitelisting
Date Wed, 10 Apr 2013 20:44:02 GMT
I am completely in favor of removing whitelisting as well.  I believe it
gives developers a false sense of security.
imho the only sure way to protect access to the bridge is to only ever load
code that you control. We should be pushing developers towards

Some of the whitelist stuff should become redundant when we have things
like the Contact API moved into plugins.  ie. You can be absolutely certain
that no JS code is accessing the device's contacts if you do not include
the native pieces of the Contact API.


On Wed, Apr 10, 2013 at 1:23 PM, Brian LeRoux <> wrote:

> 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 <
>> wrote:
> > Hey all,
> >
> > Those of us who have been on the implementing and/or serious consumption
> > side of whitelisting for iOS—I've been on both at one time or
> another—know
> > 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
> for
> > the use cases we're attempting, based on the overreach of the
> NSURLProtocol
> > 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
> care
> > about, within that particular sphere of security.  We have a more relaxed
> > sphere of security for, say, <img src="" />, as
> the
> > threat vectors exposed through image rendering are considerably less than
> > malicious injected bridge code.
> >
> > Alas, we don't—and arguably never will—have that kind of granular control
> > in iOS, with the current implementation approach.  NSURLProtocol is
> simply
> > too broad-brush to meld into a granular approach for whitelisting.  The
> end
> > 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
> the
> > 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
> the
> > device, which allows them to essentially implement their own controls on
> > attack vectors through selective app content.  In our case, we're
> building
> > an enterprise platform where content could come from any number of
> sources.
> >  And whitelisting controls are not working for us.
> >
> > If there's a future for whitelisting in Cordova 3.0, I personally feel
> that
> > 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message