You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2012/11/02 00:34:37 UTC

Whitelist defaults

Quick q: how come Android + BB's whitelists by default whitelist
everything (*), but iOS does the opposite (whitelist nothing)?

I'd like to see this unified across all platforms we support.

Re: Whitelist defaults

Posted by Brian LeRoux <b...@brian.io>.
The primary use case is the same one as the web: malicious 3rd party
scripts. The less plausible theory is John Resig decides to 'go rogue' and
take out the internet by publishing an evil jQuery to the edge. The more
realistic scenario is embedded advertising getting pwnd and now all our
customers contacts, photos, videos, and who-knows-what-else gets stolen
leaving you holding the bag.

The more I think about this the more I think the default should be * and
the functionality should be opt in with strong language in the
documentation recommending this as a part of securing the app for release.



On Fri, Nov 2, 2012 at 9:23 AM, Lorin Beer <lo...@gmail.com> wrote:

> >
> > I am with Fil, I never use it, and the first thing I do is * it.
>
>
> same here, and then I never think about the whitelist as a security
> solution again.
>
> +1 for covering data sanitization and security in docs
>
> What use cases are we enabling by having the whitelist?
>
>
> I'd be very interested to hear a solid use case as well. If none are
> forthcoming/obvious, I think this is good justification for opening it up
> as Brian suggests.
>
> On Fri, Nov 2, 2012 at 2:17 AM, Jesse <pu...@gmail.com> wrote:
>
> > I am with Fil, I never use it, and the first thing I do is * it.
> >
> > I think it also gives developers the impression that they just load
> > arbitrary untrusted content into their apps, and the whitelist will
> > protect them.
> >
> > Untrusted content will always need to be sanitized, however, having
> > the whitelist even prevents use of the InAppBrowser ( formerly
> > ChildBrowser ) plugin for it's main use-case.
> > If I were to make a twitter client with cordova, I would have to * the
> > whitelist so I could load links without exiting, and I would still
> > have to sanitize the data ...
> >
> > What use cases are we enabling by having the whitelist?
> >
> >
> >
> >
> >
> > On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
> > > I feel its a good feature for a release time but not so during
> > development
> > > time. So what ends up happening is the thing gets *, forgotten about,
> and
> > > negates the usefulness.
> > >
> > > I'm in favor of opening it up and using docs to guide how ppl should
> > secure
> > > their app for release/production.
> > >
> > >
> > > On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > >> Personally I think the whitelist is pretty useless...
> > >>
> > >> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
> > >>
> > >> >Not sure why the BlackBerry version white lists everything. We don't
> do
> > >> >that in WebWorks ;)
> > >> >
> > >> >
> > >> >
> > >> >From: Steven Gill
> > >> >To: dev@cordova.apache.org
> > >> >Reply To: dev@cordova.apache.org
> > >> >Re: Whitelist defaults
> > >> >2012-11-01 10:30:42 PM
> > >> >
> > >> >
> > >> >
> > >> >+1 to point it out in the getting started guides.
> > >> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
> > >> >
> > >> >> Also sounds like a good step/topic in the "getting started" guides.
> > >> >>
> > >> >> -- Marcel Kinard
> > >> >>
> > >> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
> > >> >>
> > >> >>> Yup agree it should whitelist nothing but it also needs to be very
> > >> >>>clear
> > >> >>> in
> > >> >>> the log when we block a request that it's due to the whitelist.
> > >> >>>
> > >> >>> On Thursday, November 1, 2012, Shazron wrote:
> > >> >>>
> > >> >>> I concur with Kevin. It won't be much of a whitelist if no one
> uses
> > it
> > >> >>>> -- I
> > >> >>>> would argue that if you set it to "*" by default, no dev will
> > >> >>>>(usually)
> > >> >>>> change that, especially if they don't know there is a whitelist
> in
> > the
> > >> >>>> first place.
> > >> >>>>
> > >> >>>>
> > >> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> > >> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
> > >> >>>>
> > >> >>>> From a security perspective, I'm partial to the iOS (nothing)
> > default,
> > >> >>>>> recognizing of course that there are certain usability drawbacks
> > to
> > >> >>>>>that
> > >> >>>>> approach.
> > >> >>>>>
> > >> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
> > >> >>>>>
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
> > >> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
> > >> >>>>>>
> > >> >>>>>> I'd like to see this unified across all platforms we support.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>
> > >> >
> > >> >---------------------------------------------------------------------
> > >> >This transmission (including any attachments) may contain
> confidential
> > >> >information, privileged material (including material protected by the
> > >> >solicitor-client or other applicable privileges), or constitute
> > >> >non-public information. Any use of this information by anyone other
> > than
> > >> >the intended recipient is prohibited. If you have received this
> > >> >transmission in error, please immediately reply to the sender and
> > delete
> > >> >this information from your system. Use, dissemination, distribution,
> or
> > >> >reproduction of this transmission by unintended recipients is not
> > >> >authorized and may be unlawful.
> > >>
> > >>
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>

Re: Whitelist defaults

Posted by Lorin Beer <lo...@gmail.com>.
>
> I am with Fil, I never use it, and the first thing I do is * it.


same here, and then I never think about the whitelist as a security
solution again.

+1 for covering data sanitization and security in docs

What use cases are we enabling by having the whitelist?


I'd be very interested to hear a solid use case as well. If none are
forthcoming/obvious, I think this is good justification for opening it up
as Brian suggests.

On Fri, Nov 2, 2012 at 2:17 AM, Jesse <pu...@gmail.com> wrote:

> I am with Fil, I never use it, and the first thing I do is * it.
>
> I think it also gives developers the impression that they just load
> arbitrary untrusted content into their apps, and the whitelist will
> protect them.
>
> Untrusted content will always need to be sanitized, however, having
> the whitelist even prevents use of the InAppBrowser ( formerly
> ChildBrowser ) plugin for it's main use-case.
> If I were to make a twitter client with cordova, I would have to * the
> whitelist so I could load links without exiting, and I would still
> have to sanitize the data ...
>
> What use cases are we enabling by having the whitelist?
>
>
>
>
>
> On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
> > I feel its a good feature for a release time but not so during
> development
> > time. So what ends up happening is the thing gets *, forgotten about, and
> > negates the usefulness.
> >
> > I'm in favor of opening it up and using docs to guide how ppl should
> secure
> > their app for release/production.
> >
> >
> > On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> Personally I think the whitelist is pretty useless...
> >>
> >> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
> >>
> >> >Not sure why the BlackBerry version white lists everything. We don't do
> >> >that in WebWorks ;)
> >> >
> >> >
> >> >
> >> >From: Steven Gill
> >> >To: dev@cordova.apache.org
> >> >Reply To: dev@cordova.apache.org
> >> >Re: Whitelist defaults
> >> >2012-11-01 10:30:42 PM
> >> >
> >> >
> >> >
> >> >+1 to point it out in the getting started guides.
> >> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
> >> >
> >> >> Also sounds like a good step/topic in the "getting started" guides.
> >> >>
> >> >> -- Marcel Kinard
> >> >>
> >> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
> >> >>
> >> >>> Yup agree it should whitelist nothing but it also needs to be very
> >> >>>clear
> >> >>> in
> >> >>> the log when we block a request that it's due to the whitelist.
> >> >>>
> >> >>> On Thursday, November 1, 2012, Shazron wrote:
> >> >>>
> >> >>> I concur with Kevin. It won't be much of a whitelist if no one uses
> it
> >> >>>> -- I
> >> >>>> would argue that if you set it to "*" by default, no dev will
> >> >>>>(usually)
> >> >>>> change that, especially if they don't know there is a whitelist in
> the
> >> >>>> first place.
> >> >>>>
> >> >>>>
> >> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> >> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
> >> >>>>
> >> >>>> From a security perspective, I'm partial to the iOS (nothing)
> default,
> >> >>>>> recognizing of course that there are certain usability drawbacks
> to
> >> >>>>>that
> >> >>>>> approach.
> >> >>>>>
> >> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
> >> >>>>>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
> >> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
> >> >>>>>>
> >> >>>>>> I'd like to see this unified across all platforms we support.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>
> >> >
> >> >---------------------------------------------------------------------
> >> >This transmission (including any attachments) may contain confidential
> >> >information, privileged material (including material protected by the
> >> >solicitor-client or other applicable privileges), or constitute
> >> >non-public information. Any use of this information by anyone other
> than
> >> >the intended recipient is prohibited. If you have received this
> >> >transmission in error, please immediately reply to the sender and
> delete
> >> >this information from your system. Use, dissemination, distribution, or
> >> >reproduction of this transmission by unintended recipients is not
> >> >authorized and may be unlawful.
> >>
> >>
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Whitelist defaults

Posted by Joe Bowser <bo...@gmail.com>.
On Fri, Nov 2, 2012 at 10:55 AM, Lorin Beer <lo...@gmail.com> wrote:
>
> BriBri Say

This is off topic, but I think this is the first time I've seen Brian
called this on the list.

Re: Whitelist defaults

Posted by Filip Maj <fi...@adobe.com>.
'Zactly.

On 11/2/12 10:55 AM, "Lorin Beer" <lo...@gmail.com> wrote:

>I'm not suggesting that it's useless, I think we are talking about '*'
>being the default, and adding documentation on securing your app.
>
>
>BriBri Say
>
>> The more I think about this the more I think the default should be * and
>> the functionality should be opt in with strong language in the
>> documentation recommending this as a part of securing the app for
>>release.
>
>
>yes, this. +1
>
>If 99% of people don't care, leave it to the 1% that does develop banking
>apps and other software that requires security.
>
>On Fri, Nov 2, 2012 at 9:36 AM, Anis KADRI <an...@gmail.com> wrote:
>
>> Just because you guys don't like/use it doesn't mean it is useless.
>>There
>> are multiple cases where you want to have an access control list [1] So
>> many apps can benefit from this features (I am thinking banking apps,
>> etc...).
>>
>> If you don't care about security or you're developing the next best
>>social
>> app (that opens links all over the place) then you can * everything.
>> However, I am sure that there are people out there that care about
>>security
>> and want this feature. While not protecting your app from every possible
>> attack it certainly doesn't hurt.
>>
>> I agree that this feature should be documented in the getting started
>>guide
>> as well.
>>
>> [1] http://www.w3.org/TR/widgets-access/
>>
>> On Fri, Nov 2, 2012 at 2:17 AM, Jesse <pu...@gmail.com> wrote:
>>
>> > I am with Fil, I never use it, and the first thing I do is * it.
>> >
>> > I think it also gives developers the impression that they just load
>> > arbitrary untrusted content into their apps, and the whitelist will
>> > protect them.
>> >
>> > Untrusted content will always need to be sanitized, however, having
>> > the whitelist even prevents use of the InAppBrowser ( formerly
>> > ChildBrowser ) plugin for it's main use-case.
>> > If I were to make a twitter client with cordova, I would have to * the
>> > whitelist so I could load links without exiting, and I would still
>> > have to sanitize the data ...
>> >
>> > What use cases are we enabling by having the whitelist?
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
>> > > I feel its a good feature for a release time but not so during
>> > development
>> > > time. So what ends up happening is the thing gets *, forgotten
>>about,
>> and
>> > > negates the usefulness.
>> > >
>> > > I'm in favor of opening it up and using docs to guide how ppl should
>> > secure
>> > > their app for release/production.
>> > >
>> > >
>> > > On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >
>> > >> Personally I think the whitelist is pretty useless...
>> > >>
>> > >> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
>> > >>
>> > >> >Not sure why the BlackBerry version white lists everything. We
>>don't
>> do
>> > >> >that in WebWorks ;)
>> > >> >
>> > >> >
>> > >> >
>> > >> >From: Steven Gill
>> > >> >To: dev@cordova.apache.org
>> > >> >Reply To: dev@cordova.apache.org
>> > >> >Re: Whitelist defaults
>> > >> >2012-11-01 10:30:42 PM
>> > >> >
>> > >> >
>> > >> >
>> > >> >+1 to point it out in the getting started guides.
>> > >> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
>> > >> >
>> > >> >> Also sounds like a good step/topic in the "getting started"
>>guides.
>> > >> >>
>> > >> >> -- Marcel Kinard
>> > >> >>
>> > >> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
>> > >> >>
>> > >> >>> Yup agree it should whitelist nothing but it also needs to be
>>very
>> > >> >>>clear
>> > >> >>> in
>> > >> >>> the log when we block a request that it's due to the whitelist.
>> > >> >>>
>> > >> >>> On Thursday, November 1, 2012, Shazron wrote:
>> > >> >>>
>> > >> >>> I concur with Kevin. It won't be much of a whitelist if no one
>> uses
>> > it
>> > >> >>>> -- I
>> > >> >>>> would argue that if you set it to "*" by default, no dev will
>> > >> >>>>(usually)
>> > >> >>>> change that, especially if they don't know there is a
>>whitelist
>> in
>> > the
>> > >> >>>> first place.
>> > >> >>>>
>> > >> >>>>
>> > >> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>> > >> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
>> > >> >>>>
>> > >> >>>> From a security perspective, I'm partial to the iOS (nothing)
>> > default,
>> > >> >>>>> recognizing of course that there are certain usability
>>drawbacks
>> > to
>> > >> >>>>>that
>> > >> >>>>> approach.
>> > >> >>>>>
>> > >> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
>> > >> >>>>>
>> > >> >>>> wrote:
>> > >> >>>>
>> > >> >>>>> Quick q: how come Android + BB's whitelists by default
>>whitelist
>> > >> >>>>>> everything (*), but iOS does the opposite (whitelist
>>nothing)?
>> > >> >>>>>>
>> > >> >>>>>> I'd like to see this unified across all platforms we
>>support.
>> > >> >>>>>>
>> > >> >>>>>>
>> > >> >>>>>>
>> > >> >>
>> > >> >
>> > >> 
>>>---------------------------------------------------------------------
>> > >> >This transmission (including any attachments) may contain
>> confidential
>> > >> >information, privileged material (including material protected by
>>the
>> > >> >solicitor-client or other applicable privileges), or constitute
>> > >> >non-public information. Any use of this information by anyone
>>other
>> > than
>> > >> >the intended recipient is prohibited. If you have received this
>> > >> >transmission in error, please immediately reply to the sender and
>> > delete
>> > >> >this information from your system. Use, dissemination,
>>distribution,
>> or
>> > >> >reproduction of this transmission by unintended recipients is not
>> > >> >authorized and may be unlawful.
>> > >>
>> > >>
>> >
>> >
>> >
>> > --
>> > @purplecabbage
>> > risingj.com
>> >
>>

Re: Whitelist defaults

Posted by Lorin Beer <lo...@gmail.com>.
I'm not suggesting that it's useless, I think we are talking about '*'
being the default, and adding documentation on securing your app.


BriBri Say

> The more I think about this the more I think the default should be * and
> the functionality should be opt in with strong language in the
> documentation recommending this as a part of securing the app for release.


yes, this. +1

If 99% of people don't care, leave it to the 1% that does develop banking
apps and other software that requires security.

On Fri, Nov 2, 2012 at 9:36 AM, Anis KADRI <an...@gmail.com> wrote:

> Just because you guys don't like/use it doesn't mean it is useless. There
> are multiple cases where you want to have an access control list [1] So
> many apps can benefit from this features (I am thinking banking apps,
> etc...).
>
> If you don't care about security or you're developing the next best social
> app (that opens links all over the place) then you can * everything.
> However, I am sure that there are people out there that care about security
> and want this feature. While not protecting your app from every possible
> attack it certainly doesn't hurt.
>
> I agree that this feature should be documented in the getting started guide
> as well.
>
> [1] http://www.w3.org/TR/widgets-access/
>
> On Fri, Nov 2, 2012 at 2:17 AM, Jesse <pu...@gmail.com> wrote:
>
> > I am with Fil, I never use it, and the first thing I do is * it.
> >
> > I think it also gives developers the impression that they just load
> > arbitrary untrusted content into their apps, and the whitelist will
> > protect them.
> >
> > Untrusted content will always need to be sanitized, however, having
> > the whitelist even prevents use of the InAppBrowser ( formerly
> > ChildBrowser ) plugin for it's main use-case.
> > If I were to make a twitter client with cordova, I would have to * the
> > whitelist so I could load links without exiting, and I would still
> > have to sanitize the data ...
> >
> > What use cases are we enabling by having the whitelist?
> >
> >
> >
> >
> >
> > On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
> > > I feel its a good feature for a release time but not so during
> > development
> > > time. So what ends up happening is the thing gets *, forgotten about,
> and
> > > negates the usefulness.
> > >
> > > I'm in favor of opening it up and using docs to guide how ppl should
> > secure
> > > their app for release/production.
> > >
> > >
> > > On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > >> Personally I think the whitelist is pretty useless...
> > >>
> > >> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
> > >>
> > >> >Not sure why the BlackBerry version white lists everything. We don't
> do
> > >> >that in WebWorks ;)
> > >> >
> > >> >
> > >> >
> > >> >From: Steven Gill
> > >> >To: dev@cordova.apache.org
> > >> >Reply To: dev@cordova.apache.org
> > >> >Re: Whitelist defaults
> > >> >2012-11-01 10:30:42 PM
> > >> >
> > >> >
> > >> >
> > >> >+1 to point it out in the getting started guides.
> > >> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
> > >> >
> > >> >> Also sounds like a good step/topic in the "getting started" guides.
> > >> >>
> > >> >> -- Marcel Kinard
> > >> >>
> > >> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
> > >> >>
> > >> >>> Yup agree it should whitelist nothing but it also needs to be very
> > >> >>>clear
> > >> >>> in
> > >> >>> the log when we block a request that it's due to the whitelist.
> > >> >>>
> > >> >>> On Thursday, November 1, 2012, Shazron wrote:
> > >> >>>
> > >> >>> I concur with Kevin. It won't be much of a whitelist if no one
> uses
> > it
> > >> >>>> -- I
> > >> >>>> would argue that if you set it to "*" by default, no dev will
> > >> >>>>(usually)
> > >> >>>> change that, especially if they don't know there is a whitelist
> in
> > the
> > >> >>>> first place.
> > >> >>>>
> > >> >>>>
> > >> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> > >> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
> > >> >>>>
> > >> >>>> From a security perspective, I'm partial to the iOS (nothing)
> > default,
> > >> >>>>> recognizing of course that there are certain usability drawbacks
> > to
> > >> >>>>>that
> > >> >>>>> approach.
> > >> >>>>>
> > >> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
> > >> >>>>>
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
> > >> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
> > >> >>>>>>
> > >> >>>>>> I'd like to see this unified across all platforms we support.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>
> > >> >
> > >> >---------------------------------------------------------------------
> > >> >This transmission (including any attachments) may contain
> confidential
> > >> >information, privileged material (including material protected by the
> > >> >solicitor-client or other applicable privileges), or constitute
> > >> >non-public information. Any use of this information by anyone other
> > than
> > >> >the intended recipient is prohibited. If you have received this
> > >> >transmission in error, please immediately reply to the sender and
> > delete
> > >> >this information from your system. Use, dissemination, distribution,
> or
> > >> >reproduction of this transmission by unintended recipients is not
> > >> >authorized and may be unlawful.
> > >>
> > >>
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>

Re: Whitelist defaults

Posted by Anis KADRI <an...@gmail.com>.
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 <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com> wrote:
> > >
> > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> > > >
> > >
> >
>

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
I mentioned this in another thread -- I'd like to migrate Cordova.plist to
config.xml so we can be consistent there. I believe Android has already
moved to config.xml already.



On Mon, Nov 5, 2012 at 4:14 PM, Jesse <pu...@gmail.com> wrote:

> Does this mean that whitelists should be added to Bada, Symbian,
> WebOS, Windows Phone, and Windows 8?
>
> Also, while we are discussing it, wouldn't it be good to have all
> platforms have a consistent way of defining access-permissions ?
>
> Android:: res/xml/cordova.xml
> Blackberry:: www/config.xml
> iOS:: Cordova.plist
> Tizen:: config.xml
>
>
>
>
>
> On Mon, Nov 5, 2012 at 3:58 PM, Shazron <sh...@gmail.com> wrote:
> > What Anis said last is what I meant. Since BB and Android have this
> > behaviour already this doesn't impact those platforms as much. Will wait
> > for comments until tomorrow then I will add some JIRA task(s).
> >
> >
> > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com> wrote:
> >
> >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >> > Why would we require a new property? We're just talking about adding
> * as
> >> > the default property.
> >> >
> >>
> >> I believe this applied only if we did a debug/release mode strategy.
> Adding
> >> (*) as default doesn't require a new property from what I understand.
> >>
> >>
> >> >
> >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed
> >> > frustration with our default.)
> >> >
> >> > I feel we have consensus enough to document and add this default.
> >> >
> >> >
> >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Whitelist defaults

Posted by Kevin Hawkins <ke...@gmail.com>.
Yeah, it's something we take care with in our implementation. Primarily, we
use the separation to include things wholesale in Debug that we don't want
in Release, such as TestFlight, and other performance gathering code that
is disabled in release builds.

On Tuesday, November 6, 2012, Andrew Grieve wrote:

> Adding * by default SGTM. Having separate debug/release whitelists sounds
> dangerous though. You don't want your app to work in debug mode and then be
> broken when you release it.
>
>
> On Mon, Nov 5, 2012 at 7:26 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > I confirm that Android also uses config.xml.
> >
> >
> > On Mon, Nov 5, 2012 at 4:22 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > I would think all unsupported devices for the whitelist feature remain
> > > unsupported (and is documented as such:
> > >
> > >
> >
> http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
> > > )
> > >
> > >
> > > On Mon, Nov 5, 2012 at 4:14 PM, Jesse <pu...@gmail.com> wrote:
> > >
> > > > Does this mean that whitelists should be added to Bada, Symbian,
> > > > WebOS, Windows Phone, and Windows 8?
> > > >
> > > > Also, while we are discussing it, wouldn't it be good to have all
> > > > platforms have a consistent way of defining access-permissions ?
> > > >
> > > > Android:: res/xml/cordova.xml
> > > > Blackberry:: www/config.xml
> > > > iOS:: Cordova.plist
> > > > Tizen:: config.xml
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron <sh...@gmail.com> wrote:
> > > > > What Anis said last is what I meant. Since BB and Android have this
> > > > > behaviour already this doesn't impact those platforms as much. Will
> > > wait
> > > > > for comments until tomorrow then I will add some JIRA task(s).
> > > > >
> > > > >
> > > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com>
> > > wrote:
> > > > >
> > > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
> > > > >>
> > > > >> > Why would we require a new property? We're just talking about
> > adding
> > > > * as
> > > > >> > the default property.
> > > > >> >
> > > > >>
> > > > >> I believe this applied only if we did a debug/release mode
> strategy.
> > > > Adding
> > > > >> (*) as default doesn't require a new property from what I
> > understand.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > (Also, Jesse, I have talked to many Cordova devs whom have
> > expressed
> > > > >> > frustration with our default.)
> > > > >> >
> > > > >> > I feel we have consensus enough to document and add this
> default.
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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.
> > > > >> > > >
> > >

Re: Whitelist defaults

Posted by Andrew Grieve <ag...@chromium.org>.
Adding * by default SGTM. Having separate debug/release whitelists sounds
dangerous though. You don't want your app to work in debug mode and then be
broken when you release it.


On Mon, Nov 5, 2012 at 7:26 PM, Anis KADRI <an...@gmail.com> wrote:

> I confirm that Android also uses config.xml.
>
>
> On Mon, Nov 5, 2012 at 4:22 PM, Shazron <sh...@gmail.com> wrote:
>
> > I would think all unsupported devices for the whitelist feature remain
> > unsupported (and is documented as such:
> >
> >
> http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
> > )
> >
> >
> > On Mon, Nov 5, 2012 at 4:14 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > Does this mean that whitelists should be added to Bada, Symbian,
> > > WebOS, Windows Phone, and Windows 8?
> > >
> > > Also, while we are discussing it, wouldn't it be good to have all
> > > platforms have a consistent way of defining access-permissions ?
> > >
> > > Android:: res/xml/cordova.xml
> > > Blackberry:: www/config.xml
> > > iOS:: Cordova.plist
> > > Tizen:: config.xml
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron <sh...@gmail.com> wrote:
> > > > What Anis said last is what I meant. Since BB and Android have this
> > > > behaviour already this doesn't impact those platforms as much. Will
> > wait
> > > > for comments until tomorrow then I will add some JIRA task(s).
> > > >
> > > >
> > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > > >
> > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
> > > >>
> > > >> > Why would we require a new property? We're just talking about
> adding
> > > * as
> > > >> > the default property.
> > > >> >
> > > >>
> > > >> I believe this applied only if we did a debug/release mode strategy.
> > > Adding
> > > >> (*) as default doesn't require a new property from what I
> understand.
> > > >>
> > > >>
> > > >> >
> > > >> > (Also, Jesse, I have talked to many Cordova devs whom have
> expressed
> > > >> > frustration with our default.)
> > > >> >
> > > >> > I feel we have consensus enough to document and add this default.
> > > >> >
> > > >> >
> > > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <sh...@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
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> > >
> > >
> > > --
> > > @purplecabbage
> > > risingj.com
> > >
> >
>

Re: Whitelist defaults

Posted by Anis KADRI <an...@gmail.com>.
I confirm that Android also uses config.xml.


On Mon, Nov 5, 2012 at 4:22 PM, Shazron <sh...@gmail.com> wrote:

> I would think all unsupported devices for the whitelist feature remain
> unsupported (and is documented as such:
>
> http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
> )
>
>
> On Mon, Nov 5, 2012 at 4:14 PM, Jesse <pu...@gmail.com> wrote:
>
> > Does this mean that whitelists should be added to Bada, Symbian,
> > WebOS, Windows Phone, and Windows 8?
> >
> > Also, while we are discussing it, wouldn't it be good to have all
> > platforms have a consistent way of defining access-permissions ?
> >
> > Android:: res/xml/cordova.xml
> > Blackberry:: www/config.xml
> > iOS:: Cordova.plist
> > Tizen:: config.xml
> >
> >
> >
> >
> >
> > On Mon, Nov 5, 2012 at 3:58 PM, Shazron <sh...@gmail.com> wrote:
> > > What Anis said last is what I meant. Since BB and Android have this
> > > behaviour already this doesn't impact those platforms as much. Will
> wait
> > > for comments until tomorrow then I will add some JIRA task(s).
> > >
> > >
> > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com>
> wrote:
> > >
> > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
> > >>
> > >> > Why would we require a new property? We're just talking about adding
> > * as
> > >> > the default property.
> > >> >
> > >>
> > >> I believe this applied only if we did a debug/release mode strategy.
> > Adding
> > >> (*) as default doesn't require a new property from what I understand.
> > >>
> > >>
> > >> >
> > >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed
> > >> > frustration with our default.)
> > >> >
> > >> > I feel we have consensus enough to document and add this default.
> > >> >
> > >> >
> > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
I would think all unsupported devices for the whitelist feature remain
unsupported (and is documented as such:
http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
)


On Mon, Nov 5, 2012 at 4:14 PM, Jesse <pu...@gmail.com> wrote:

> Does this mean that whitelists should be added to Bada, Symbian,
> WebOS, Windows Phone, and Windows 8?
>
> Also, while we are discussing it, wouldn't it be good to have all
> platforms have a consistent way of defining access-permissions ?
>
> Android:: res/xml/cordova.xml
> Blackberry:: www/config.xml
> iOS:: Cordova.plist
> Tizen:: config.xml
>
>
>
>
>
> On Mon, Nov 5, 2012 at 3:58 PM, Shazron <sh...@gmail.com> wrote:
> > What Anis said last is what I meant. Since BB and Android have this
> > behaviour already this doesn't impact those platforms as much. Will wait
> > for comments until tomorrow then I will add some JIRA task(s).
> >
> >
> > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com> wrote:
> >
> >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >> > Why would we require a new property? We're just talking about adding
> * as
> >> > the default property.
> >> >
> >>
> >> I believe this applied only if we did a debug/release mode strategy.
> Adding
> >> (*) as default doesn't require a new property from what I understand.
> >>
> >>
> >> >
> >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed
> >> > frustration with our default.)
> >> >
> >> > I feel we have consensus enough to document and add this default.
> >> >
> >> >
> >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com>
> >> > wrote:
> >> > > > >
> >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Whitelist defaults

Posted by Jesse <pu...@gmail.com>.
Does this mean that whitelists should be added to Bada, Symbian,
WebOS, Windows Phone, and Windows 8?

Also, while we are discussing it, wouldn't it be good to have all
platforms have a consistent way of defining access-permissions ?

Android:: res/xml/cordova.xml
Blackberry:: www/config.xml
iOS:: Cordova.plist
Tizen:: config.xml





On Mon, Nov 5, 2012 at 3:58 PM, Shazron <sh...@gmail.com> wrote:
> What Anis said last is what I meant. Since BB and Android have this
> behaviour already this doesn't impact those platforms as much. Will wait
> for comments until tomorrow then I will add some JIRA task(s).
>
>
> On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com> wrote:
>
>> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
>>
>> > Why would we require a new property? We're just talking about adding * as
>> > the default property.
>> >
>>
>> I believe this applied only if we did a debug/release mode strategy. Adding
>> (*) as default doesn't require a new property from what I understand.
>>
>>
>> >
>> > (Also, Jesse, I have talked to many Cordova devs whom have expressed
>> > frustration with our default.)
>> >
>> > I feel we have consensus enough to document and add this default.
>> >
>> >
>> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com>
>> > wrote:
>> > > > >
>> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>



-- 
@purplecabbage
risingj.com

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
What Anis said last is what I meant. Since BB and Android have this
behaviour already this doesn't impact those platforms as much. Will wait
for comments until tomorrow then I will add some JIRA task(s).


On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI <an...@gmail.com> wrote:

> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Why would we require a new property? We're just talking about adding * as
> > the default property.
> >
>
> I believe this applied only if we did a debug/release mode strategy. Adding
> (*) as default doesn't require a new property from what I understand.
>
>
> >
> > (Also, Jesse, I have talked to many Cordova devs whom have expressed
> > frustration with our default.)
> >
> > I feel we have consensus enough to document and add this default.
> >
> >
> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com>
> > wrote:
> > > > >
> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Whitelist defaults

Posted by Anis KADRI <an...@gmail.com>.
On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:

> Why would we require a new property? We're just talking about adding * as
> the default property.
>

I believe this applied only if we did a debug/release mode strategy. Adding
(*) as default doesn't require a new property from what I understand.


>
> (Also, Jesse, I have talked to many Cordova devs whom have expressed
> frustration with our default.)
>
> I feel we have consensus enough to document and add this default.
>
>
> On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com>
> wrote:
> > > >
> > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> > > > >
> > > >
> > >
> >
>

Re: Whitelist defaults

Posted by Brian LeRoux <b...@brian.io>.
Why would we require a new property? We're just talking about adding * as
the default property.

(Also, Jesse, I have talked to many Cordova devs whom have expressed
frustration with our default.)

I feel we have consensus enough to document and add this default.


On Mon, Nov 5, 2012 at 3:26 PM, Shazron <sh...@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 <an...@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 <sh...@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 <bo...@gmail.com> wrote:
> > >
> > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> > > >
> > >
> >
>

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
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 <an...@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 <sh...@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 <bo...@gmail.com> wrote:
> >
> > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> > >
> >
>

Re: Whitelist defaults

Posted by Jesse <pu...@gmail.com>.
I have relaxed my position, as I can work around whatever the choice is.
It might be prudent to ask our users though.


On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI <an...@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 <sh...@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 <bo...@gmail.com> wrote:
>>
>> > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
>> >
>>



-- 
@purplecabbage
risingj.com

Re: Whitelist defaults

Posted by Kevin Hawkins <ke...@gmail.com>.
In our customizations of our Cordova app, that's exactly what we did.  We
created a Cordova-Debug.plist and Cordova-Release.plist, and synced them
back to Cordova.plist as a Build Phase step.  I don't know that it's the
default behavior the Cordova community would want for template apps, but it
is doable anyway.

On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI <an...@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 <sh...@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 <bo...@gmail.com> wrote:
> >
> > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> > >
> >
>

Re: Whitelist defaults

Posted by Anis KADRI <an...@gmail.com>.
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 <sh...@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 <bo...@gmail.com> wrote:
>
> > On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
> >
>

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
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 <bo...@gmail.com> wrote:

> On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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
>

Re: Whitelist defaults

Posted by Joe Bowser <bo...@gmail.com>.
On Fri, Nov 2, 2012 at 10:59 AM, Shazron <sh...@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

Re: Whitelist defaults

Posted by Simon MacDonald <si...@gmail.com>.
On Fri, Nov 2, 2012 at 1:59 PM, Shazron <sh...@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.
>

Thirding the paranoid corporate types. I mean if they even knew I was
typing thi

BLAM! THUD.

Simon Mac Donald
http://hi.im/simonmacdonald

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
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.


On Fri, Nov 2, 2012 at 9:36 AM, Anis KADRI <an...@gmail.com> wrote:

> Just because you guys don't like/use it doesn't mean it is useless. There
> are multiple cases where you want to have an access control list [1] So
> many apps can benefit from this features (I am thinking banking apps,
> etc...).
>
> If you don't care about security or you're developing the next best social
> app (that opens links all over the place) then you can * everything.
> However, I am sure that there are people out there that care about security
> and want this feature. While not protecting your app from every possible
> attack it certainly doesn't hurt.
>
> I agree that this feature should be documented in the getting started guide
> as well.
>
> [1] http://www.w3.org/TR/widgets-access/
>
> On Fri, Nov 2, 2012 at 2:17 AM, Jesse <pu...@gmail.com> wrote:
>
> > I am with Fil, I never use it, and the first thing I do is * it.
> >
> > I think it also gives developers the impression that they just load
> > arbitrary untrusted content into their apps, and the whitelist will
> > protect them.
> >
> > Untrusted content will always need to be sanitized, however, having
> > the whitelist even prevents use of the InAppBrowser ( formerly
> > ChildBrowser ) plugin for it's main use-case.
> > If I were to make a twitter client with cordova, I would have to * the
> > whitelist so I could load links without exiting, and I would still
> > have to sanitize the data ...
> >
> > What use cases are we enabling by having the whitelist?
> >
> >
> >
> >
> >
> > On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
> > > I feel its a good feature for a release time but not so during
> > development
> > > time. So what ends up happening is the thing gets *, forgotten about,
> and
> > > negates the usefulness.
> > >
> > > I'm in favor of opening it up and using docs to guide how ppl should
> > secure
> > > their app for release/production.
> > >
> > >
> > > On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > >> Personally I think the whitelist is pretty useless...
> > >>
> > >> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
> > >>
> > >> >Not sure why the BlackBerry version white lists everything. We don't
> do
> > >> >that in WebWorks ;)
> > >> >
> > >> >
> > >> >
> > >> >From: Steven Gill
> > >> >To: dev@cordova.apache.org
> > >> >Reply To: dev@cordova.apache.org
> > >> >Re: Whitelist defaults
> > >> >2012-11-01 10:30:42 PM
> > >> >
> > >> >
> > >> >
> > >> >+1 to point it out in the getting started guides.
> > >> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
> > >> >
> > >> >> Also sounds like a good step/topic in the "getting started" guides.
> > >> >>
> > >> >> -- Marcel Kinard
> > >> >>
> > >> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
> > >> >>
> > >> >>> Yup agree it should whitelist nothing but it also needs to be very
> > >> >>>clear
> > >> >>> in
> > >> >>> the log when we block a request that it's due to the whitelist.
> > >> >>>
> > >> >>> On Thursday, November 1, 2012, Shazron wrote:
> > >> >>>
> > >> >>> I concur with Kevin. It won't be much of a whitelist if no one
> uses
> > it
> > >> >>>> -- I
> > >> >>>> would argue that if you set it to "*" by default, no dev will
> > >> >>>>(usually)
> > >> >>>> change that, especially if they don't know there is a whitelist
> in
> > the
> > >> >>>> first place.
> > >> >>>>
> > >> >>>>
> > >> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> > >> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
> > >> >>>>
> > >> >>>> From a security perspective, I'm partial to the iOS (nothing)
> > default,
> > >> >>>>> recognizing of course that there are certain usability drawbacks
> > to
> > >> >>>>>that
> > >> >>>>> approach.
> > >> >>>>>
> > >> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
> > >> >>>>>
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
> > >> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
> > >> >>>>>>
> > >> >>>>>> I'd like to see this unified across all platforms we support.
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>
> > >> >
> > >> >---------------------------------------------------------------------
> > >> >This transmission (including any attachments) may contain
> confidential
> > >> >information, privileged material (including material protected by the
> > >> >solicitor-client or other applicable privileges), or constitute
> > >> >non-public information. Any use of this information by anyone other
> > than
> > >> >the intended recipient is prohibited. If you have received this
> > >> >transmission in error, please immediately reply to the sender and
> > delete
> > >> >this information from your system. Use, dissemination, distribution,
> or
> > >> >reproduction of this transmission by unintended recipients is not
> > >> >authorized and may be unlawful.
> > >>
> > >>
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>

Re: Whitelist defaults

Posted by Anis KADRI <an...@gmail.com>.
Just because you guys don't like/use it doesn't mean it is useless. There
are multiple cases where you want to have an access control list [1] So
many apps can benefit from this features (I am thinking banking apps,
etc...).

If you don't care about security or you're developing the next best social
app (that opens links all over the place) then you can * everything.
However, I am sure that there are people out there that care about security
and want this feature. While not protecting your app from every possible
attack it certainly doesn't hurt.

I agree that this feature should be documented in the getting started guide
as well.

[1] http://www.w3.org/TR/widgets-access/

On Fri, Nov 2, 2012 at 2:17 AM, Jesse <pu...@gmail.com> wrote:

> I am with Fil, I never use it, and the first thing I do is * it.
>
> I think it also gives developers the impression that they just load
> arbitrary untrusted content into their apps, and the whitelist will
> protect them.
>
> Untrusted content will always need to be sanitized, however, having
> the whitelist even prevents use of the InAppBrowser ( formerly
> ChildBrowser ) plugin for it's main use-case.
> If I were to make a twitter client with cordova, I would have to * the
> whitelist so I could load links without exiting, and I would still
> have to sanitize the data ...
>
> What use cases are we enabling by having the whitelist?
>
>
>
>
>
> On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
> > I feel its a good feature for a release time but not so during
> development
> > time. So what ends up happening is the thing gets *, forgotten about, and
> > negates the usefulness.
> >
> > I'm in favor of opening it up and using docs to guide how ppl should
> secure
> > their app for release/production.
> >
> >
> > On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> Personally I think the whitelist is pretty useless...
> >>
> >> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
> >>
> >> >Not sure why the BlackBerry version white lists everything. We don't do
> >> >that in WebWorks ;)
> >> >
> >> >
> >> >
> >> >From: Steven Gill
> >> >To: dev@cordova.apache.org
> >> >Reply To: dev@cordova.apache.org
> >> >Re: Whitelist defaults
> >> >2012-11-01 10:30:42 PM
> >> >
> >> >
> >> >
> >> >+1 to point it out in the getting started guides.
> >> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
> >> >
> >> >> Also sounds like a good step/topic in the "getting started" guides.
> >> >>
> >> >> -- Marcel Kinard
> >> >>
> >> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
> >> >>
> >> >>> Yup agree it should whitelist nothing but it also needs to be very
> >> >>>clear
> >> >>> in
> >> >>> the log when we block a request that it's due to the whitelist.
> >> >>>
> >> >>> On Thursday, November 1, 2012, Shazron wrote:
> >> >>>
> >> >>> I concur with Kevin. It won't be much of a whitelist if no one uses
> it
> >> >>>> -- I
> >> >>>> would argue that if you set it to "*" by default, no dev will
> >> >>>>(usually)
> >> >>>> change that, especially if they don't know there is a whitelist in
> the
> >> >>>> first place.
> >> >>>>
> >> >>>>
> >> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> >> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
> >> >>>>
> >> >>>> From a security perspective, I'm partial to the iOS (nothing)
> default,
> >> >>>>> recognizing of course that there are certain usability drawbacks
> to
> >> >>>>>that
> >> >>>>> approach.
> >> >>>>>
> >> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
> >> >>>>>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
> >> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
> >> >>>>>>
> >> >>>>>> I'd like to see this unified across all platforms we support.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>
> >> >
> >> >---------------------------------------------------------------------
> >> >This transmission (including any attachments) may contain confidential
> >> >information, privileged material (including material protected by the
> >> >solicitor-client or other applicable privileges), or constitute
> >> >non-public information. Any use of this information by anyone other
> than
> >> >the intended recipient is prohibited. If you have received this
> >> >transmission in error, please immediately reply to the sender and
> delete
> >> >this information from your system. Use, dissemination, distribution, or
> >> >reproduction of this transmission by unintended recipients is not
> >> >authorized and may be unlawful.
> >>
> >>
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Whitelist defaults

Posted by Jesse <pu...@gmail.com>.
I am with Fil, I never use it, and the first thing I do is * it.

I think it also gives developers the impression that they just load
arbitrary untrusted content into their apps, and the whitelist will
protect them.

Untrusted content will always need to be sanitized, however, having
the whitelist even prevents use of the InAppBrowser ( formerly
ChildBrowser ) plugin for it's main use-case.
If I were to make a twitter client with cordova, I would have to * the
whitelist so I could load links without exiting, and I would still
have to sanitize the data ...

What use cases are we enabling by having the whitelist?





On Fri, Nov 2, 2012 at 12:27 AM, Brian LeRoux <b...@brian.io> wrote:
> I feel its a good feature for a release time but not so during development
> time. So what ends up happening is the thing gets *, forgotten about, and
> negates the usefulness.
>
> I'm in favor of opening it up and using docs to guide how ppl should secure
> their app for release/production.
>
>
> On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Personally I think the whitelist is pretty useless...
>>
>> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
>>
>> >Not sure why the BlackBerry version white lists everything. We don't do
>> >that in WebWorks ;)
>> >
>> >
>> >
>> >From: Steven Gill
>> >To: dev@cordova.apache.org
>> >Reply To: dev@cordova.apache.org
>> >Re: Whitelist defaults
>> >2012-11-01 10:30:42 PM
>> >
>> >
>> >
>> >+1 to point it out in the getting started guides.
>> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
>> >
>> >> Also sounds like a good step/topic in the "getting started" guides.
>> >>
>> >> -- Marcel Kinard
>> >>
>> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
>> >>
>> >>> Yup agree it should whitelist nothing but it also needs to be very
>> >>>clear
>> >>> in
>> >>> the log when we block a request that it's due to the whitelist.
>> >>>
>> >>> On Thursday, November 1, 2012, Shazron wrote:
>> >>>
>> >>> I concur with Kevin. It won't be much of a whitelist if no one uses it
>> >>>> -- I
>> >>>> would argue that if you set it to "*" by default, no dev will
>> >>>>(usually)
>> >>>> change that, especially if they don't know there is a whitelist in the
>> >>>> first place.
>> >>>>
>> >>>>
>> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
>> >>>>
>> >>>> From a security perspective, I'm partial to the iOS (nothing) default,
>> >>>>> recognizing of course that there are certain usability drawbacks to
>> >>>>>that
>> >>>>> approach.
>> >>>>>
>> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
>> >>>>>
>> >>>> wrote:
>> >>>>
>> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
>> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
>> >>>>>>
>> >>>>>> I'd like to see this unified across all platforms we support.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>
>> >
>> >---------------------------------------------------------------------
>> >This transmission (including any attachments) may contain confidential
>> >information, privileged material (including material protected by the
>> >solicitor-client or other applicable privileges), or constitute
>> >non-public information. Any use of this information by anyone other than
>> >the intended recipient is prohibited. If you have received this
>> >transmission in error, please immediately reply to the sender and delete
>> >this information from your system. Use, dissemination, distribution, or
>> >reproduction of this transmission by unintended recipients is not
>> >authorized and may be unlawful.
>>
>>



-- 
@purplecabbage
risingj.com

Re: Whitelist defaults

Posted by Brian LeRoux <b...@brian.io>.
I feel its a good feature for a release time but not so during development
time. So what ends up happening is the thing gets *, forgotten about, and
negates the usefulness.

I'm in favor of opening it up and using docs to guide how ppl should secure
their app for release/production.


On Thu, Nov 1, 2012 at 10:30 PM, Filip Maj <fi...@adobe.com> wrote:

> Personally I think the whitelist is pretty useless...
>
> On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:
>
> >Not sure why the BlackBerry version white lists everything. We don't do
> >that in WebWorks ;)
> >
> >
> >
> >From: Steven Gill
> >To: dev@cordova.apache.org
> >Reply To: dev@cordova.apache.org
> >Re: Whitelist defaults
> >2012-11-01 10:30:42 PM
> >
> >
> >
> >+1 to point it out in the getting started guides.
> >On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
> >
> >> Also sounds like a good step/topic in the "getting started" guides.
> >>
> >> -- Marcel Kinard
> >>
> >> On 11/1/2012 8:36 PM, Dave Johnson wrote:
> >>
> >>> Yup agree it should whitelist nothing but it also needs to be very
> >>>clear
> >>> in
> >>> the log when we block a request that it's due to the whitelist.
> >>>
> >>> On Thursday, November 1, 2012, Shazron wrote:
> >>>
> >>> I concur with Kevin. It won't be much of a whitelist if no one uses it
> >>>> -- I
> >>>> would argue that if you set it to "*" by default, no dev will
> >>>>(usually)
> >>>> change that, especially if they don't know there is a whitelist in the
> >>>> first place.
> >>>>
> >>>>
> >>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> >>>> kevin.hawkins.cordova@gmail.**com > wrote:
> >>>>
> >>>> From a security perspective, I'm partial to the iOS (nothing) default,
> >>>>> recognizing of course that there are certain usability drawbacks to
> >>>>>that
> >>>>> approach.
> >>>>>
> >>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
> >>>>>
> >>>> wrote:
> >>>>
> >>>>> Quick q: how come Android + BB's whitelists by default whitelist
> >>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
> >>>>>>
> >>>>>> I'd like to see this unified across all platforms we support.
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> >
> >---------------------------------------------------------------------
> >This transmission (including any attachments) may contain confidential
> >information, privileged material (including material protected by the
> >solicitor-client or other applicable privileges), or constitute
> >non-public information. Any use of this information by anyone other than
> >the intended recipient is prohibited. If you have received this
> >transmission in error, please immediately reply to the sender and delete
> >this information from your system. Use, dissemination, distribution, or
> >reproduction of this transmission by unintended recipients is not
> >authorized and may be unlawful.
>
>

Re: Whitelist defaults

Posted by Filip Maj <fi...@adobe.com>.
Personally I think the whitelist is pretty useless...

On 11/1/12 7:32 PM, "Ken Wallis" <kw...@rim.com> wrote:

>Not sure why the BlackBerry version white lists everything. We don't do
>that in WebWorks ;)
>
>
>
>From: Steven Gill
>To: dev@cordova.apache.org
>Reply To: dev@cordova.apache.org
>Re: Whitelist defaults
>2012-11-01 10:30:42 PM
>
>
>
>+1 to point it out in the getting started guides.
>On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:
>
>> Also sounds like a good step/topic in the "getting started" guides.
>>
>> -- Marcel Kinard
>>
>> On 11/1/2012 8:36 PM, Dave Johnson wrote:
>>
>>> Yup agree it should whitelist nothing but it also needs to be very
>>>clear
>>> in
>>> the log when we block a request that it's due to the whitelist.
>>>
>>> On Thursday, November 1, 2012, Shazron wrote:
>>>
>>> I concur with Kevin. It won't be much of a whitelist if no one uses it
>>>> -- I
>>>> would argue that if you set it to "*" by default, no dev will
>>>>(usually)
>>>> change that, especially if they don't know there is a whitelist in the
>>>> first place.
>>>>
>>>>
>>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>>>> kevin.hawkins.cordova@gmail.**com > wrote:
>>>>
>>>> From a security perspective, I'm partial to the iOS (nothing) default,
>>>>> recognizing of course that there are certain usability drawbacks to
>>>>>that
>>>>> approach.
>>>>>
>>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
>>>>>
>>>> wrote:
>>>>
>>>>> Quick q: how come Android + BB's whitelists by default whitelist
>>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
>>>>>>
>>>>>> I'd like to see this unified across all platforms we support.
>>>>>>
>>>>>>
>>>>>>
>>
>
>---------------------------------------------------------------------
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.

Re: Whitelist defaults

Posted by Ken Wallis <kw...@rim.com>.
Not sure why the BlackBerry version white lists everything. We don't do that in WebWorks ;)



From: Steven Gill
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Re: Whitelist defaults
2012-11-01 10:30:42 PM



+1 to point it out in the getting started guides.
On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:

> Also sounds like a good step/topic in the "getting started" guides.
>
> -- Marcel Kinard
>
> On 11/1/2012 8:36 PM, Dave Johnson wrote:
>
>> Yup agree it should whitelist nothing but it also needs to be very clear
>> in
>> the log when we block a request that it's due to the whitelist.
>>
>> On Thursday, November 1, 2012, Shazron wrote:
>>
>> I concur with Kevin. It won't be much of a whitelist if no one uses it
>>> -- I
>>> would argue that if you set it to "*" by default, no dev will (usually)
>>> change that, especially if they don't know there is a whitelist in the
>>> first place.
>>>
>>>
>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>>> kevin.hawkins.cordova@gmail.**com > wrote:
>>>
>>> From a security perspective, I'm partial to the iOS (nothing) default,
>>>> recognizing of course that there are certain usability drawbacks to that
>>>> approach.
>>>>
>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >
>>>>
>>> wrote:
>>>
>>>> Quick q: how come Android + BB's whitelists by default whitelist
>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
>>>>>
>>>>> I'd like to see this unified across all platforms we support.
>>>>>
>>>>>
>>>>>
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Whitelist defaults

Posted by Steven Gill <st...@gmail.com>.
+1 to point it out in the getting started guides.
On Nov 1, 2012 6:35 PM, "Marcel Kinard" <cm...@gmail.com> wrote:

> Also sounds like a good step/topic in the "getting started" guides.
>
> -- Marcel Kinard
>
> On 11/1/2012 8:36 PM, Dave Johnson wrote:
>
>> Yup agree it should whitelist nothing but it also needs to be very clear
>> in
>> the log when we block a request that it's due to the whitelist.
>>
>> On Thursday, November 1, 2012, Shazron wrote:
>>
>>  I concur with Kevin. It won't be much of a whitelist if no one uses it
>>> -- I
>>> would argue that if you set it to "*" by default, no dev will (usually)
>>> change that, especially if they don't know there is a whitelist in the
>>> first place.
>>>
>>>
>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>>> kevin.hawkins.cordova@gmail.**com <ke...@gmail.com><javascript:;>> wrote:
>>>
>>>   From a security perspective, I'm partial to the iOS (nothing) default,
>>>> recognizing of course that there are certain usability drawbacks to that
>>>> approach.
>>>>
>>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj <fil@adobe.com<javascript:;>>
>>>>
>>> wrote:
>>>
>>>> Quick q: how come Android + BB's whitelists by default whitelist
>>>>> everything (*), but iOS does the opposite (whitelist nothing)?
>>>>>
>>>>> I'd like to see this unified across all platforms we support.
>>>>>
>>>>>
>>>>>
>

Re: Whitelist defaults

Posted by Marcel Kinard <cm...@gmail.com>.
Also sounds like a good step/topic in the "getting started" guides.

-- Marcel Kinard

On 11/1/2012 8:36 PM, Dave Johnson wrote:
> Yup agree it should whitelist nothing but it also needs to be very clear in
> the log when we block a request that it's due to the whitelist.
>
> On Thursday, November 1, 2012, Shazron wrote:
>
>> I concur with Kevin. It won't be much of a whitelist if no one uses it -- I
>> would argue that if you set it to "*" by default, no dev will (usually)
>> change that, especially if they don't know there is a whitelist in the
>> first place.
>>
>>
>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>> kevin.hawkins.cordova@gmail.com <javascript:;>> wrote:
>>
>>>  From a security perspective, I'm partial to the iOS (nothing) default,
>>> recognizing of course that there are certain usability drawbacks to that
>>> approach.
>>>
>>> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj <fil@adobe.com <javascript:;>>
>> wrote:
>>>> Quick q: how come Android + BB's whitelists by default whitelist
>>>> everything (*), but iOS does the opposite (whitelist nothing)?
>>>>
>>>> I'd like to see this unified across all platforms we support.
>>>>
>>>>

Re: Whitelist defaults

Posted by Dave Johnson <da...@gmail.com>.
Yup agree it should whitelist nothing but it also needs to be very clear in
the log when we block a request that it's due to the whitelist.

On Thursday, November 1, 2012, Shazron wrote:

> I concur with Kevin. It won't be much of a whitelist if no one uses it -- I
> would argue that if you set it to "*" by default, no dev will (usually)
> change that, especially if they don't know there is a whitelist in the
> first place.
>
>
> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
> kevin.hawkins.cordova@gmail.com <javascript:;>> wrote:
>
> > From a security perspective, I'm partial to the iOS (nothing) default,
> > recognizing of course that there are certain usability drawbacks to that
> > approach.
> >
> > On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj <fil@adobe.com <javascript:;>>
> wrote:
> >
> > > Quick q: how come Android + BB's whitelists by default whitelist
> > > everything (*), but iOS does the opposite (whitelist nothing)?
> > >
> > > I'd like to see this unified across all platforms we support.
> > >
> > >
> >
>

Re: Whitelist defaults

Posted by Shazron <sh...@gmail.com>.
I concur with Kevin. It won't be much of a whitelist if no one uses it -- I
would argue that if you set it to "*" by default, no dev will (usually)
change that, especially if they don't know there is a whitelist in the
first place.


On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
kevin.hawkins.cordova@gmail.com> wrote:

> From a security perspective, I'm partial to the iOS (nothing) default,
> recognizing of course that there are certain usability drawbacks to that
> approach.
>
> On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > Quick q: how come Android + BB's whitelists by default whitelist
> > everything (*), but iOS does the opposite (whitelist nothing)?
> >
> > I'd like to see this unified across all platforms we support.
> >
> >
>

Re: Whitelist defaults

Posted by Kevin Hawkins <ke...@gmail.com>.
>From a security perspective, I'm partial to the iOS (nothing) default,
recognizing of course that there are certain usability drawbacks to that
approach.

On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj <fi...@adobe.com> wrote:

> Quick q: how come Android + BB's whitelists by default whitelist
> everything (*), but iOS does the opposite (whitelist nothing)?
>
> I'd like to see this unified across all platforms we support.
>
>