Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D5869DEEC for ; Mon, 5 Nov 2012 23:44:02 +0000 (UTC) Received: (qmail 91417 invoked by uid 500); 5 Nov 2012 23:44:02 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 91374 invoked by uid 500); 5 Nov 2012 23:44:02 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 91365 invoked by uid 99); 5 Nov 2012 23:44:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2012 23:44:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of anis.kadri@gmail.com designates 209.85.160.175 as permitted sender) Received: from [209.85.160.175] (HELO mail-gh0-f175.google.com) (209.85.160.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2012 23:43:57 +0000 Received: by mail-gh0-f175.google.com with SMTP id z2so1155823ghb.6 for ; Mon, 05 Nov 2012 15:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rPlHDsJpTwaA3+pKO9GFUeO1DgIlwSu2+D7j0+9fcKU=; b=E23b9cHHMDm99jNZEe//jT8OCC6DtbAJX4YEO1p/ovaMyZDPg40NHtmcUJsmSOjiSq 0gcZgFrDy1W491/ctjxpAodQ8h8/LKBZj9WLxfMjoKQ1v+duD0gn7JvSvVnzakhQ+Tek hA5nkgHKl2+xphlic3PZbprahQ9oDbl/3CxvwibiXN/+iAjR0S+R1MHfF3X8T32dEKvs RJWt83WEKFlBKdkt+Y2irA6zt1wFyq96V25QhSgoK6SxSxerMjgnn8w756aCtWiVIO8u nzpCZGci6SuBpHua12bXJcW9MHaHZiuBMfvXnOpVCkgIr4Jo1zLknVp+4x9/LAvZ2v+r afAw== MIME-Version: 1.0 Received: by 10.236.85.196 with SMTP id u44mr10577980yhe.49.1352159016861; Mon, 05 Nov 2012 15:43:36 -0800 (PST) Received: by 10.236.148.41 with HTTP; Mon, 5 Nov 2012 15:43:36 -0800 (PST) In-Reply-To: References: <20121102023230.7774340.57294.351@rim.com> Date: Mon, 5 Nov 2012 15:43:36 -0800 Message-ID: Subject: Re: Whitelist defaults From: Anis KADRI To: dev@cordova.apache.org Content-Type: multipart/alternative; boundary=20cf300e4e91e140a804cdc80d34 X-Virus-Checked: Checked by ClamAV on apache.org --20cf300e4e91e140a804cdc80d34 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux 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 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 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 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 > wrote: > > > > > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron > 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 > > > > > > > > > > > > > > > --20cf300e4e91e140a804cdc80d34--