> > 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 <purplecabb...@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 <f...@adobe.com> wrote: > > > >> Personally I think the whitelist is pretty useless... > >> > >> On 11/1/12 7:32 PM, "Ken Wallis" <kwal...@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 >