Re: Whitelist defaults
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 anis.ka...@gmail.com wrote: I confirm that Android also uses config.xml. On Mon, Nov 5, 2012 at 4:22 PM, Shazron shaz...@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 purplecabb...@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 shaz...@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 anis.ka...@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 shaz...@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.ka...@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 shaz...@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 bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@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
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 anis.ka...@gmail.com wrote: I confirm that Android also uses config.xml. On Mon, Nov 5, 2012 at 4:22 PM, Shazron shaz...@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 purplecabb...@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 shaz...@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 anis.ka...@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 shaz...@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.ka...@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
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 bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@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
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 shaz...@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 bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@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
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 anis.ka...@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 shaz...@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 bows...@gmail.com wrote: On Fri, Nov 2, 2012 at 10:59 AM, Shazron shaz...@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
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
Re: Whitelist defaults
On Fri, Nov 2, 2012 at 10:55 AM, Lorin Beer lorin.beer@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
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.cord...@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 f...@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.
