Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.215.175 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: 
 <CAKP6k2uEo2wk6VCjFDjHhr_SjNs6GRy_v14NV--i0sv_qLwr8Q@mail.gmail.com>
References: <812916889958891609@unknownmsgid>
	<CADVgkyMVLgyZLE0_A31GY5BaABBVHxnKnp=Ge3pEQrG=Fpa8jQ@mail.gmail.com>
	<CAE6O_-Z8ADWC0eauvif5AbNFem_jCNLyJ3vGZVvk7WHnH5N6bw@mail.gmail.com>
	<CAE6O_-aWnfpmD9yfmEgT7oLk9b-d6O=qMSdd-Cp3Sti2rq9S_w@mail.gmail.com>
	<-2592107845858267218@unknownmsgid>
	<CAFnWYTn0LzWa61f_gWQ4eLQ4TS6gG98B8Nuus+XXmiCdUr_r9g@mail.gmail.com>
	<CAKP6k2uEo2wk6VCjFDjHhr_SjNs6GRy_v14NV--i0sv_qLwr8Q@mail.gmail.com>
Date: Tue, 7 Aug 2012 16:44:13 -0700
Message-ID: 
 <CADVgkyM3DAXuXCjPL7to3Zb7NGu4NGod7S+MwPMD9OamXC4g6Q@mail.gmail.com>
Subject: Re: [DISCUSS] window.open target blank
From: Brian LeRoux <b@brian.io>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Jesse: I like it.

My personal take is the primary use case we want to fulfill is the
ability to see content in a browser. Unfortunately iOS this means
leaving the app context which isn't the best experience thus the need
for a ChildBrowser.

For this use case I do not see the need for access to the native
bridge. Maybe I'm missing something but would it not reduce the
complexity if the childbrowser had no bridge capability? is there a
drawback if this is the case? (Obv the system browser has no native
bridge.)

Also, we really should come up with a better name than 'Child Browser'. =/


On Tue, Aug 7, 2012 at 4:30 PM, Jesse <purplecabbage@gmail.com> wrote:
> Brion:
> Yes, this should be considered part of the API, the 'how' is yet to be
> defined, but apps need the ability to specifically target both the default
> system browser AND the ChildBrowser.
>
> ===
>
> Re: My Proposal, ( I have officially flipped ... )
>
> After writing/sending my proposal, I thought back to the origins of the
> ChildBrowser plugin.  Back when Shaz and I wrote it some 2+ years ago, the
> goal was to allow non-secure content to be loaded into the application
> without offering any chance of the app/dom being hijacked.  At the time,
> there was no whitelist, and all was fine.
>
> Now that we have a whitelist, I think we need to re-evaluate it's purpose.
>  IMHO the ChildBrowser should NOT be restricted to domains in the
> whitelist.  If you imagine attempting to develop a twitter clone, it would
> be impossible to display links in tweets unless you either, jumped out to
> the system browser, or had an allow * in the whitelist.  IMO this is a
> perfectly valid use case for building a phonegap app.
>
> Displaying content from ANY domain should be a perfectly acceptable
> practice.
> Running JS code inside the ChildBrowser from ANY domain should be
> acceptable as well. ( XHR cross-domain requests should continue to be
> governed by the security already present in the browser control itself )
> Mixing code/content from the internet domain with the app domain SHOULD be
> governed by the whitelist.
>
> The ChildBrowser already shields the app from unsafe internet code, in that
> it does NOT allow any of the APIs that phonegap does.  This is in harmony
> with the initial intent of the plugin, to safely display some content ...
> and not lose the app context.
>
> My adjusted proposal follows :
>
> 1. The security/whitelist checking should be adjusted to only apply to
> access attempts by the CDVViewController, and not the entire application. (
> not easy, I know Shaz, I can help )
> 2. If ChildBrowser is present, it should include code to intercept
> target._blank and polyfil window.open to its own API. (JS POC needed)
> 3. ChildBrowser should get an additional API to specifically target
> the system default browser. ( API details TBD )
>
> Cheers,
>   Jesse
>
>
>
>
> On Mon, Aug 6, 2012 at 4:55 PM, Brion Vibber <brion@pobox.com> wrote:
>
>> On Mon, Aug 6, 2012 at 3:52 PM, Jesse MacFadyen <purplecabbage@gmail.com
>> >wrote:
>>
>> > [PROPOSAL]
>> >
>> > 1. If a URL is not in the whitelist, it will be passed to the default
>> > system browser regardless of any other rule. ( this will be handled on
>> > the native side, by the framework and the JS side may not even know it
>> > has happened. )
>> >
>>
>> If the URL *is* in the whitelist, can we send it to the default system
>> browser too when calling window.open?
>>
>> For lots of our usage at Wikimedia, we need to whitelist Wikipedia sites in
>> order to do API calls via XHR (at least on iOS), but also want to be able
>> to open specific pages in the system browser.
>>
>> 2. If ChildBrowser is present, it should include code to intercept
>> > target._blank and polyfil window.open to its own API.
>> > 3. ChildBrowser should get an additional API to specifically target
>> > the system default browser.
>> >
>>
>> -- brion vibber (brion @ pobox.com / brion @ wikimedia.org)
>>
>
>
>
> --
> @purplecabbage
> risingj.com