incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [DISCUSS] window.open target blank
Date Tue, 07 Aug 2012 23:44:49 GMT
Great writeup Jesse.

I agree with your reasoning and I like that Child Browser is not ruled by
the domain whitelist.

One concern that I have is around other plugins. Consider the scenario of
an asset downloader that may download an archive (tar, gzip, etc), extract
it, and inject the assets into the application's DOM. Off the top of my
head, this sort of plugin should be restricted by the domain whitelist.

Michael

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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message