incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [DISCUSS] window.open target blank
Date Wed, 08 Aug 2012 00:08:13 GMT
so given that it does NOT impl any bridge access why would we have any
discussion around whitelisting? what precisely are we concerned about
security wise? (pls help me completely understand.)

also, no need to shout. ;)

On Tue, Aug 7, 2012 at 4:58 PM, Jesse <purplecabbage@gmail.com> wrote:
> Brian,
> The ChildBrowser does NOT allow bridge access, it is a dumb view.
> The only way that it can communicate with the host app is via url changes (
> a'la OAuth, NOT a'la PhoneGap gap:// commands. )
>
> Michael,
> When you install a plugin, you should be aware of what the plugin does.
>  This is a developer decision and not a framework responsibility IMHO.
>
> ChildBrowser name suggestions? Separate thread?
>
>
>
> On Tue, Aug 7, 2012 at 4:44 PM, Michael Brooks <michael@michaelbrooks.ca>wrote:
>
>> 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
>> >
>>
>
>
>
> --
> @purplecabbage
> risingj.com

Mime
View raw message