Great write-up - thanks Jesse and all. Response to: 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 )
Answer: I envision a token based system -- the ChildBrowser (or any other plugin), generates a token, and a plugin name identifier - , and registers it with the CDVURLProtocol. The plugin then sets a known http header (tbd) that it will set with the token value. This exception when encountered will bypass the whitelist, and is logged to console (just in case of shenanigans). eg https://github.com/phonegap/phonegap-plugins/blob/master/iOS/ChildBrowser/ChildBrowserViewController.m#L184 Instead of a NSURLRequest, create a NSMutableURLRequest and set the expected header with token. In here we do the whitelist exception decision based on the header+token: https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Classes/CDVURLProtocol.m#L41 On Thu, Aug 9, 2012 at 11:33 AM, Jesse <[email protected]> wrote: > Can we get more than an hour? > > On Thu, Aug 9, 2012 at 11:24 AM, Brian LeRoux <[email protected]> wrote: > >> So---is this solid enough ground to open some issues / make this a part of >> 2.1? >> >> (end of september) >> >> >> >> >> On Thu, Aug 9, 2012 at 10:59 AM, Michael Brooks >> <[email protected]> wrote: >> > Nice Dave, those conditions make sense to me. >> > >> > On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson <[email protected] >> >wrote: >> > >> >> These are the window.open calls that we need to consider: >> >> >> >> 1) window.open('local-url.html', '_self'); // >> >> loads in CordovaView. _parent and _top same thing >> >> 2) window.open('local-url.html', '_blank'); // loads >> >> in InAppBrowser >> >> 3) window.open('http://whitelisted-url.com', '_self'); // loads in >> >> CordovaView >> >> 4) window.open('http://whitelisted-url.com', '_blank'); // loads in >> >> InAppBrowser >> >> 5) window.open('http://random-url.com', '_self'); // loads in >> >> InAppBrowser >> >> 6) window.open('http://random-url.com', '_blank'); // native >> browser >> >> >> >> window.location = 'foo' is equivalent to the '_self' options above. >> >> >> >> I'm operating under the assumption that local and whitelisted URLs >> >> should be opened with Cordova functionality by default (_self) and you >> >> have to be explicit if you want those trusted resources opened without >> >> Cordova functionality (_blank). >> >> >> >> >> >> On Wed, Aug 8, 2012 at 12:13 PM, Brian LeRoux <[email protected]> wrote: >> >> > I'd rather we continue to encourage single page apps as the best >> >> > practice for building apps w/ html, css, and js. The many views >> >> > architecture seems like it would create a strong coupling to the >> >> > native side (for transitioning esp so). >> >> > >> >> > I view the cleaver-ing as creating a transition path for native apps >> >> > to cordova apps and/or allowing the facebook/linkedin/twitter webview >> >> > with native chrome use case (which I do not love but understand the >> >> > desire for it in some cases). >> >> > >> >> > >> >> > On Wed, Aug 8, 2012 at 11:55 AM, Jesse MacFadyen >> >> > <[email protected]> wrote: >> >> >> In the future we may want to allow multi-view apps, as this was part >> >> >> of the reasoning for cleaving the view... >> >> >> does this change anything? >> >> >> >> >> >> Cheers, >> >> >> Jesse >> >> >> >> >> >> Sent from my iPhone >> >> >> >> >> >> On 2012-08-08, at 11:28 AM, Brian LeRoux <[email protected]> wrote: >> >> >> >> >> >>> Meant to reply to this. I think Mike is correct: >> >> >>> >> >> >>> _blank === system browser >> >> >>> _self === child browser >> >> >>> >> >> >>> Thoughts? >> >> >>> >> >> >>> >> >> >>> * * * >> >> >>> >> >> >>> ChildBrowser === InAppBrowser <---not perfect but it gets rid of >> >> pedobear jokes >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Tue, Aug 7, 2012 at 5:04 PM, Michael Brooks < >> >> [email protected]> wrote: >> >> >>>>> >> >> >>>>> 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 ) >> >> >>>> >> >> >>>> >> >> >>>> Can we consider using the other anchor frame types? [1] To me, >> _blank >> >> >>>> should still exit the app and open the default browser. Perhaps >> _self, >> >> >>>> _parent, or _top can be intercepted to invoke the Child Browser >> (name >> >> >>>> change pending)? >> >> >>>> >> >> >>>> - _blank: The user agent should load the designated document in a >> new, >> >> >>>> unnamed window. >> >> >>>> - _self: The user agent should load the document in the same frame >> as >> >> the >> >> >>>> element that refers to this target. >> >> >>>> - _parent: The user agent should load the document into the >> immediate >> >> >>>> FRAMESET parent of the current frame. This value is equivalent to >> >> _self if >> >> >>>> the current frame has no parent. >> >> >>>> - _top: The user agent should load the document into the full, >> >> original >> >> >>>> window (thus canceling all other frames). This value is equivalent >> to >> >> _self >> >> >>>> if the current frame has no parent. >> >> >>>> >> >> >>>> [1] http://www.w3.org/TR/html401/types.html#type-frame-target >> >> >>>> >> >> >>>> Michael >> >> >>>> >> >> >>>> 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
