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 anis.kadri@gmail.com
 designates 209.85.213.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-YYnn=ppKiPZ2NP_QBX4MtsPspJD+DfPCx8HUExSFC+Zw@mail.gmail.com>
References: <20121102023230.7774340.57294.351@rim.com>
	<CCB8A863.10AB4%fil@adobe.com>
	<CADVgkyP9NbhGeiG_Pnk=CmMZBeYxbr32fDRbLqY++TgYbvYe1Q@mail.gmail.com>
	<CAKP6k2sG3WbGi5cARt-JOv0JcdzkGmC+5WRG7=5cBug=78Qg9w@mail.gmail.com>
	<CANpVHHyqo5wS-T2oAYdOogGZPw9fh1qSrnN+Pa+H48sL+NgL+w@mail.gmail.com>
	<CAE6O_-bE-8hZ02Rph538_DWn9mwJowbLFb1U9Om3jHLhsL_HSQ@mail.gmail.com>
	<CAOBL_k4q2K+Ggnt3PUi4tA55JtYo3h+yaVM1xqNCRcXYpoXZ-g@mail.gmail.com>
	<CAE6O_-b__2rkXTXc=05wCk=FQ4NcQrMkUmiSw+BFMmz9LJkbFw@mail.gmail.com>
	<CANpVHHyqvv4sdi18mDoe8THYabCMbgCfRbqCztZ01LnmPb+QsQ@mail.gmail.com>
	<CAE6O_-YYnn=ppKiPZ2NP_QBX4MtsPspJD+DfPCx8HUExSFC+Zw@mail.gmail.com>
Date: Mon, 5 Nov 2012 15:31:17 -0800
Message-ID: 
 <CANpVHHzjBy+F9AT-fZxydN_8_akm_nDW1iFD=Vh8aqtMniXLAQ@mail.gmail.com>
Subject: Re: Whitelist defaults
From: Anis KADRI <anis.kadri@gmail.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=0016e68ef3efcdec8c04cdc7e12e

--0016e68ef3efcdec8c04cdc7e12e
Content-Type: text/plain; charset=ISO-8859-1

I guess make it "all" then. That's what I conclude from our discussion. As
long as the feature is there, people can make the adequate decisions. I
believe we should add this to the getting started guide (the whitelist docs
are not enough to draw attention).


On Mon, Nov 5, 2012 at 3:26 PM, Shazron <shazron@gmail.com> wrote:

> Well it's all or nothing. There is no "dev" mode with respect to the plist
> itself as it is right now, unless we want to add yet another plist
> property.
>
>
> On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
>
> > I guess the consensus is to whitelist everything (*) all the time.
> >
> > My opinion is that there should be some dev mode where (*) is set and
> then
> > a release mode where you'd specify your hosts.
> >
> >
> > On Mon, Nov 5, 2012 at 3:11 PM, Shazron <shazron@gmail.com> wrote:
> >
> > > We've had the discussion. So what is the decision/consensus? Leave as
> is,
> > > or add "*" to default settings for all, with a warning in the console
> > log?
> > >
> > >
> > >
> > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser <bowserj@gmail.com> wrote:
> > >
> > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <shazron@gmail.com> wrote:
> > > > > Echoing Anis here. The easiest use case is for corporate use
> > > (internal),
> > > > > where any connections are restricted to a certain domain for
> paranoid
> > > IT
> > > > > types.
> > > > >
> > > > > I can see the case of us allowing everything _by default_ though
> (eg
> > > > adding
> > > > > the '*'), which really should have been the default so as to be
> > > > "backwards
> > > > > compatible" with how it was before the whitelist came in. The
> system
> > > > could
> > > > > detect this sole wildcard entry, and print out a warning in the
> > console
> > > > > log, as well as the documentation of course pointing this out --
> the
> > > > latter
> > > > > which we should have done in the first place.
> > > >
> > > > OK, that sounds cool, but does that mean that in six months, we're
> > > > going to deprecate this behaviour and get more aggressive with the
> > > > whitelist?
> > > >
> > > > BTW: In the event that the whitelist isn't found based on the code
> > > > that I'm looking at here, Android should block everything and fire
> > > > default web intents.  If it's not doing this, that's a bug! When we
> > > > refer to defaults, are we referring to the config.xml that we're
> > > > circulating?
> > > >
> > > > Also, how are we testing this whitelisting feature? I can tell you
> > > > that doing it in JS alone wouldn't be enough.
> > > >
> > > > Joe
> > > >
> > >
> >
>

--0016e68ef3efcdec8c04cdc7e12e--