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 <[email protected]> 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 <[email protected]> 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 <[email protected] > >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 <[email protected]> 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 <[email protected]> wrote: > >> > > >> > > On Mon, Aug 6, 2012 at 3:52 PM, Jesse MacFadyen < > >> [email protected] > >> > > >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
