incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Wed, 08 Aug 2012 00:32:44 GMT
Ha, that was _emphasis_ not shouting.

The current iOS codebase applies the whitelist globally to all URLRequests,
it is the simplest implementation.  This prevents all code from accessing
non-whitelisted domains.

Restricting access based on what code is requesting it is more work, and
non-trivial.


On Tue, Aug 7, 2012 at 5:08 PM, Brian LeRoux <b@brian.io> wrote:

> 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
>



-- 
@purplecabbage
risingj.com

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