Re: whitelist as a plugin
I'd like to see this tie into Pluggable WebViews because based on the work I'm doing on MozillaView, I think we're going to need it broken out into a plugin and an API added for it. That said, I'm hoping the delta isn't too different, because if we decide to completely redesign the Pluggable WebView API, I think it'll be another six months until this feature sees the light of day. On Fri, Oct 10, 2014 at 8:17 AM, Ian Clelland wrote: > I'm still thinking in the old CadVer world here -- yes, it is a breaking > change, and would absolutely require a major version change. 3.7.0 is > certainly not a possible version number for it. > > I suppose the issue of master vs. 4.0.x in my head was whether the feature > branch should be rooted on the branch named "4.0.x", and so depend on > pluggable-webviews, or rooted on where master is today, and so be eligible > for landing before the webview breakout. > > Of course, I'd really love both for pluggable webviews to ship, and to not > have to do the whitelist work twice, so I'm happy with basing it on the > 4.0.x branch. > > > On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve > wrote: > > > It's technically a breaking change, so agree 4.0.x makes sense. > > > > On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser wrote: > > > > > This should land in 4.0.x > > > On Oct 9, 2014 7:38 AM, "Ian Clelland" wrote: > > > > > > > I'm running into more and more problems caused by the whitelist > (today, > > > > it's because of the dual use of the internal whitelist for "should be > > > able > > > > to navigate to URL" and "should be able to XHR from URL") > > > > > > > > I'm going to start to pull it out, on a topic branch based off of > > Android > > > > 4.0.x right now. I'll create a JIRA issue to track the work. > > > > > > > > Is 4.0.x the best place for this to land, or is there any support for > > > > putting it on master as well, for an eventual 3.7 release? > > > > > > > > > > > > On Wed, Jul 9, 2014 at 1:22 PM, Shazron wrote: > > > > > > > > > +1 to remove it for all the above reasons (and WKWebView in iOS 8) > > > > > Those interested in this security blanket for checkmark ✓ purposes > > can > > > > > install the plugin, and perhaps maintain it as well. > > > > > > > > > > On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: > > > > > > Or remove it altogether and let the evolution of that code be > > > > maintained > > > > > by > > > > > > those interested in the narrative it provides? :) > > > > > > > > > > > > On Wednesday, July 9, 2014, Andrew Grieve > > > > wrote: > > > > > > > > > > > >> Sounds like we both agree that it doesn't work and adds a false > > > sense > > > > of > > > > > >> security (to those that do opt into it) :P. > > > > > >> > > > > > >> Maybe what we should do is redesign the whitelist to do > something > > > more > > > > > >> useful. > > > > > >> > > > > > >> e.g. A whitelist that says what URLs you can navigate to is > useful > > > and > > > > > easy > > > > > >> to implement. Let's just drop the trying to stop network > requests > > > > > aspect of > > > > > >> it? > > > > > >> > > > > > >> > > > > > >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > > > > >> > wrote: > > > > > >> > > > > > >> > I'm in agreement with Andrew on this one. If we can get CSP > > > > working, > > > > > >> > that's a far better solution than our Whitelist, which was > done > > > > > >> > because it was needed at the time for the enterprise use case > > that > > > > IBM > > > > > >> > had. I don't think we're ever going to stop are users from > > doing > > > > dumb > > > > > >> > things like including > thirdpartyadnetworkthatdoesnoteusehttps.js > > > in > > > > > >> > their apps any time soon, but they'll have to jump through > more > > > > hoops > > > > > >> > to do dumb things, and making dumb things harder is a good > > thing. > > > > > >> > > > > > > >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > > > > > > > > > >> wrote: > > > > > >> > > Heh. Why do we always seem to be at the opposite end of > > > > > considerations? > > > > > >> > > (Not a bad thing anyhow. ;) > > > > > >> > > > > > > > >> > > So making whitelist a plugin would most certainly isolate > the > > > code > > > > > >> which > > > > > >> > > would help us better understand: > > > > > >> > > > > > > > >> > > 1.) where the surface for bugs are (we seem to miss/find new > > > > > security > > > > > >> > holes > > > > > >> > > each quarter…) > > > > > >> > > 2.) if people actually use it > > > > > >> > > > > > > > >> > > I'm more interested in #2. I suspect the only people whom do > > use > > > > it > > > > > are > > > > > >> > > security researchers disproving the whitelist veracity. I > feel > > > > this > > > > > API > > > > > >> > was > > > > > >> > > a mistake, is misleading, and ultimately leads to poor web > > > > security > > > > > >> > > practices wrt 3rd part scripts. I'd like the evidence to > > remove > > > it > > > > > >> > > completely and making it a plugin would do that. (And stil
Re: whitelist as a plugin
I'm still thinking in the old CadVer world here -- yes, it is a breaking change, and would absolutely require a major version change. 3.7.0 is certainly not a possible version number for it. I suppose the issue of master vs. 4.0.x in my head was whether the feature branch should be rooted on the branch named "4.0.x", and so depend on pluggable-webviews, or rooted on where master is today, and so be eligible for landing before the webview breakout. Of course, I'd really love both for pluggable webviews to ship, and to not have to do the whitelist work twice, so I'm happy with basing it on the 4.0.x branch. On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve wrote: > It's technically a breaking change, so agree 4.0.x makes sense. > > On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser wrote: > > > This should land in 4.0.x > > On Oct 9, 2014 7:38 AM, "Ian Clelland" wrote: > > > > > I'm running into more and more problems caused by the whitelist (today, > > > it's because of the dual use of the internal whitelist for "should be > > able > > > to navigate to URL" and "should be able to XHR from URL") > > > > > > I'm going to start to pull it out, on a topic branch based off of > Android > > > 4.0.x right now. I'll create a JIRA issue to track the work. > > > > > > Is 4.0.x the best place for this to land, or is there any support for > > > putting it on master as well, for an eventual 3.7 release? > > > > > > > > > On Wed, Jul 9, 2014 at 1:22 PM, Shazron wrote: > > > > > > > +1 to remove it for all the above reasons (and WKWebView in iOS 8) > > > > Those interested in this security blanket for checkmark ✓ purposes > can > > > > install the plugin, and perhaps maintain it as well. > > > > > > > > On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: > > > > > Or remove it altogether and let the evolution of that code be > > > maintained > > > > by > > > > > those interested in the narrative it provides? :) > > > > > > > > > > On Wednesday, July 9, 2014, Andrew Grieve > > > wrote: > > > > > > > > > >> Sounds like we both agree that it doesn't work and adds a false > > sense > > > of > > > > >> security (to those that do opt into it) :P. > > > > >> > > > > >> Maybe what we should do is redesign the whitelist to do something > > more > > > > >> useful. > > > > >> > > > > >> e.g. A whitelist that says what URLs you can navigate to is useful > > and > > > > easy > > > > >> to implement. Let's just drop the trying to stop network requests > > > > aspect of > > > > >> it? > > > > >> > > > > >> > > > > >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > > > >> > wrote: > > > > >> > > > > >> > I'm in agreement with Andrew on this one. If we can get CSP > > > working, > > > > >> > that's a far better solution than our Whitelist, which was done > > > > >> > because it was needed at the time for the enterprise use case > that > > > IBM > > > > >> > had. I don't think we're ever going to stop are users from > doing > > > dumb > > > > >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js > > in > > > > >> > their apps any time soon, but they'll have to jump through more > > > hoops > > > > >> > to do dumb things, and making dumb things harder is a good > thing. > > > > >> > > > > > >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > > > > > > > >> wrote: > > > > >> > > Heh. Why do we always seem to be at the opposite end of > > > > considerations? > > > > >> > > (Not a bad thing anyhow. ;) > > > > >> > > > > > > >> > > So making whitelist a plugin would most certainly isolate the > > code > > > > >> which > > > > >> > > would help us better understand: > > > > >> > > > > > > >> > > 1.) where the surface for bugs are (we seem to miss/find new > > > > security > > > > >> > holes > > > > >> > > each quarter…) > > > > >> > > 2.) if people actually use it > > > > >> > > > > > > >> > > I'm more interested in #2. I suspect the only people whom do > use > > > it > > > > are > > > > >> > > security researchers disproving the whitelist veracity. I feel > > > this > > > > API > > > > >> > was > > > > >> > > a mistake, is misleading, and ultimately leads to poor web > > > security > > > > >> > > practices wrt 3rd part scripts. I'd like the evidence to > remove > > it > > > > >> > > completely and making it a plugin would do that. (And still > > allow > > > > for > > > > >> its > > > > >> > > existence to those whom want to contribute to a "marketing" > > based > > > > api.) > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve < > > > agri...@chromium.org > > > > >> > > > > > >> > wrote: > > > > >> > > > > > > >> > >> I don't think moving the whitelist to a plugin would aid in > its > > > > >> > >> understanding. Right now the whitelist is used for two > things: > > > > >> > >> > > > > >> > >> 1. Whether to allow network requests through (although this > is > > > > broken > > > > >> > for > > > > >> > >> / on iOS, and broken for them + websockets on > > > Android > > > >
Re: whitelist as a plugin
It's technically a breaking change, so agree 4.0.x makes sense. On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser wrote: > This should land in 4.0.x > On Oct 9, 2014 7:38 AM, "Ian Clelland" wrote: > > > I'm running into more and more problems caused by the whitelist (today, > > it's because of the dual use of the internal whitelist for "should be > able > > to navigate to URL" and "should be able to XHR from URL") > > > > I'm going to start to pull it out, on a topic branch based off of Android > > 4.0.x right now. I'll create a JIRA issue to track the work. > > > > Is 4.0.x the best place for this to land, or is there any support for > > putting it on master as well, for an eventual 3.7 release? > > > > > > On Wed, Jul 9, 2014 at 1:22 PM, Shazron wrote: > > > > > +1 to remove it for all the above reasons (and WKWebView in iOS 8) > > > Those interested in this security blanket for checkmark ✓ purposes can > > > install the plugin, and perhaps maintain it as well. > > > > > > On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: > > > > Or remove it altogether and let the evolution of that code be > > maintained > > > by > > > > those interested in the narrative it provides? :) > > > > > > > > On Wednesday, July 9, 2014, Andrew Grieve > > wrote: > > > > > > > >> Sounds like we both agree that it doesn't work and adds a false > sense > > of > > > >> security (to those that do opt into it) :P. > > > >> > > > >> Maybe what we should do is redesign the whitelist to do something > more > > > >> useful. > > > >> > > > >> e.g. A whitelist that says what URLs you can navigate to is useful > and > > > easy > > > >> to implement. Let's just drop the trying to stop network requests > > > aspect of > > > >> it? > > > >> > > > >> > > > >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > > >> > wrote: > > > >> > > > >> > I'm in agreement with Andrew on this one. If we can get CSP > > working, > > > >> > that's a far better solution than our Whitelist, which was done > > > >> > because it was needed at the time for the enterprise use case that > > IBM > > > >> > had. I don't think we're ever going to stop are users from doing > > dumb > > > >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js > in > > > >> > their apps any time soon, but they'll have to jump through more > > hoops > > > >> > to do dumb things, and making dumb things harder is a good thing. > > > >> > > > > >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > > > > > >> wrote: > > > >> > > Heh. Why do we always seem to be at the opposite end of > > > considerations? > > > >> > > (Not a bad thing anyhow. ;) > > > >> > > > > > >> > > So making whitelist a plugin would most certainly isolate the > code > > > >> which > > > >> > > would help us better understand: > > > >> > > > > > >> > > 1.) where the surface for bugs are (we seem to miss/find new > > > security > > > >> > holes > > > >> > > each quarter…) > > > >> > > 2.) if people actually use it > > > >> > > > > > >> > > I'm more interested in #2. I suspect the only people whom do use > > it > > > are > > > >> > > security researchers disproving the whitelist veracity. I feel > > this > > > API > > > >> > was > > > >> > > a mistake, is misleading, and ultimately leads to poor web > > security > > > >> > > practices wrt 3rd part scripts. I'd like the evidence to remove > it > > > >> > > completely and making it a plugin would do that. (And still > allow > > > for > > > >> its > > > >> > > existence to those whom want to contribute to a "marketing" > based > > > api.) > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve < > > agri...@chromium.org > > > >> > > > > >> > wrote: > > > >> > > > > > >> > >> I don't think moving the whitelist to a plugin would aid in its > > > >> > >> understanding. Right now the whitelist is used for two things: > > > >> > >> > > > >> > >> 1. Whether to allow network requests through (although this is > > > broken > > > >> > for > > > >> > >> / on iOS, and broken for them + websockets on > > Android > > > >> > >> 2. Whether to allow top frame navigations (e.g. clicking a link > > to > > > >> > http:// > > > >> > >> * > > > >> > >> opens in system browser vs. webview) > > > >> > >> > > > >> > >> #1 doesn't work very well due to technical limitations. > > > >> > >> #2 is actually the more import one security-wise I think, and I > > > don't > > > >> > think > > > >> > >> should be relegated to a plugin. > > > >> > >> > > > >> > >> I'm hoping medium-term that CSP can replace the use-case of #1. > > > >> > >> > > > >> > >> > > > >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland < > > > iclell...@chromium.org > > > >> > > > > >> > >> wrote: > > > >> > >> > > > >> > >> > What would be the security implication of removing it from > > core? > > > No > > > >> > >> access > > > >> > >> > at all by default? Or unlimited access by default? > > > >> > >> > > > > >> > >> > I suspect that if the default policy with no plugin ins
Re: whitelist as a plugin
This should land in 4.0.x On Oct 9, 2014 7:38 AM, "Ian Clelland" wrote: > I'm running into more and more problems caused by the whitelist (today, > it's because of the dual use of the internal whitelist for "should be able > to navigate to URL" and "should be able to XHR from URL") > > I'm going to start to pull it out, on a topic branch based off of Android > 4.0.x right now. I'll create a JIRA issue to track the work. > > Is 4.0.x the best place for this to land, or is there any support for > putting it on master as well, for an eventual 3.7 release? > > > On Wed, Jul 9, 2014 at 1:22 PM, Shazron wrote: > > > +1 to remove it for all the above reasons (and WKWebView in iOS 8) > > Those interested in this security blanket for checkmark ✓ purposes can > > install the plugin, and perhaps maintain it as well. > > > > On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: > > > Or remove it altogether and let the evolution of that code be > maintained > > by > > > those interested in the narrative it provides? :) > > > > > > On Wednesday, July 9, 2014, Andrew Grieve > wrote: > > > > > >> Sounds like we both agree that it doesn't work and adds a false sense > of > > >> security (to those that do opt into it) :P. > > >> > > >> Maybe what we should do is redesign the whitelist to do something more > > >> useful. > > >> > > >> e.g. A whitelist that says what URLs you can navigate to is useful and > > easy > > >> to implement. Let's just drop the trying to stop network requests > > aspect of > > >> it? > > >> > > >> > > >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > >> > wrote: > > >> > > >> > I'm in agreement with Andrew on this one. If we can get CSP > working, > > >> > that's a far better solution than our Whitelist, which was done > > >> > because it was needed at the time for the enterprise use case that > IBM > > >> > had. I don't think we're ever going to stop are users from doing > dumb > > >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in > > >> > their apps any time soon, but they'll have to jump through more > hoops > > >> > to do dumb things, and making dumb things harder is a good thing. > > >> > > > >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > > > >> wrote: > > >> > > Heh. Why do we always seem to be at the opposite end of > > considerations? > > >> > > (Not a bad thing anyhow. ;) > > >> > > > > >> > > So making whitelist a plugin would most certainly isolate the code > > >> which > > >> > > would help us better understand: > > >> > > > > >> > > 1.) where the surface for bugs are (we seem to miss/find new > > security > > >> > holes > > >> > > each quarter…) > > >> > > 2.) if people actually use it > > >> > > > > >> > > I'm more interested in #2. I suspect the only people whom do use > it > > are > > >> > > security researchers disproving the whitelist veracity. I feel > this > > API > > >> > was > > >> > > a mistake, is misleading, and ultimately leads to poor web > security > > >> > > practices wrt 3rd part scripts. I'd like the evidence to remove it > > >> > > completely and making it a plugin would do that. (And still allow > > for > > >> its > > >> > > existence to those whom want to contribute to a "marketing" based > > api.) > > >> > > > > >> > > > > >> > > > > >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve < > agri...@chromium.org > > >> > > > >> > wrote: > > >> > > > > >> > >> I don't think moving the whitelist to a plugin would aid in its > > >> > >> understanding. Right now the whitelist is used for two things: > > >> > >> > > >> > >> 1. Whether to allow network requests through (although this is > > broken > > >> > for > > >> > >> / on iOS, and broken for them + websockets on > Android > > >> > >> 2. Whether to allow top frame navigations (e.g. clicking a link > to > > >> > http:// > > >> > >> * > > >> > >> opens in system browser vs. webview) > > >> > >> > > >> > >> #1 doesn't work very well due to technical limitations. > > >> > >> #2 is actually the more import one security-wise I think, and I > > don't > > >> > think > > >> > >> should be relegated to a plugin. > > >> > >> > > >> > >> I'm hoping medium-term that CSP can replace the use-case of #1. > > >> > >> > > >> > >> > > >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland < > > iclell...@chromium.org > > >> > > > >> > >> wrote: > > >> > >> > > >> > >> > What would be the security implication of removing it from > core? > > No > > >> > >> access > > >> > >> > at all by default? Or unlimited access by default? > > >> > >> > > > >> > >> > I suspect that if the default policy with no plugin installed > is > > the > > >> > >> > latter, then we will be given the impression that it's not > > important > > >> > at > > >> > >> all > > >> > >> > :) > > >> > >> > > > >> > >> > I had considered just turning the whitelist settings into a > > plugin > > >> -- > > >> > >> > either leaving the default rules as they are, and writing a > > >> > >> > "cordova-security" plugin that locks it down, or tig
Re: whitelist as a plugin
CB-7747, for those following along at home. On Thu, Oct 9, 2014 at 10:38 AM, Ian Clelland wrote: > I'm running into more and more problems caused by the whitelist (today, > it's because of the dual use of the internal whitelist for "should be able > to navigate to URL" and "should be able to XHR from URL") > > I'm going to start to pull it out, on a topic branch based off of Android > 4.0.x right now. I'll create a JIRA issue to track the work. > > Is 4.0.x the best place for this to land, or is there any support for > putting it on master as well, for an eventual 3.7 release? > > > On Wed, Jul 9, 2014 at 1:22 PM, Shazron wrote: > >> +1 to remove it for all the above reasons (and WKWebView in iOS 8) >> Those interested in this security blanket for checkmark ✓ purposes can >> install the plugin, and perhaps maintain it as well. >> >> On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: >> > Or remove it altogether and let the evolution of that code be >> maintained by >> > those interested in the narrative it provides? :) >> > >> > On Wednesday, July 9, 2014, Andrew Grieve wrote: >> > >> >> Sounds like we both agree that it doesn't work and adds a false sense >> of >> >> security (to those that do opt into it) :P. >> >> >> >> Maybe what we should do is redesign the whitelist to do something more >> >> useful. >> >> >> >> e.g. A whitelist that says what URLs you can navigate to is useful and >> easy >> >> to implement. Let's just drop the trying to stop network requests >> aspect of >> >> it? >> >> >> >> >> >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > >> > wrote: >> >> >> >> > I'm in agreement with Andrew on this one. If we can get CSP working, >> >> > that's a far better solution than our Whitelist, which was done >> >> > because it was needed at the time for the enterprise use case that >> IBM >> >> > had. I don't think we're ever going to stop are users from doing >> dumb >> >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in >> >> > their apps any time soon, but they'll have to jump through more hoops >> >> > to do dumb things, and making dumb things harder is a good thing. >> >> > >> >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > >> >> wrote: >> >> > > Heh. Why do we always seem to be at the opposite end of >> considerations? >> >> > > (Not a bad thing anyhow. ;) >> >> > > >> >> > > So making whitelist a plugin would most certainly isolate the code >> >> which >> >> > > would help us better understand: >> >> > > >> >> > > 1.) where the surface for bugs are (we seem to miss/find new >> security >> >> > holes >> >> > > each quarter…) >> >> > > 2.) if people actually use it >> >> > > >> >> > > I'm more interested in #2. I suspect the only people whom do use >> it are >> >> > > security researchers disproving the whitelist veracity. I feel >> this API >> >> > was >> >> > > a mistake, is misleading, and ultimately leads to poor web security >> >> > > practices wrt 3rd part scripts. I'd like the evidence to remove it >> >> > > completely and making it a plugin would do that. (And still allow >> for >> >> its >> >> > > existence to those whom want to contribute to a "marketing" based >> api.) >> >> > > >> >> > > >> >> > > >> >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve < >> agri...@chromium.org >> >> > >> >> > wrote: >> >> > > >> >> > >> I don't think moving the whitelist to a plugin would aid in its >> >> > >> understanding. Right now the whitelist is used for two things: >> >> > >> >> >> > >> 1. Whether to allow network requests through (although this is >> broken >> >> > for >> >> > >> / on iOS, and broken for them + websockets on >> Android >> >> > >> 2. Whether to allow top frame navigations (e.g. clicking a link to >> >> > http:// >> >> > >> * >> >> > >> opens in system browser vs. webview) >> >> > >> >> >> > >> #1 doesn't work very well due to technical limitations. >> >> > >> #2 is actually the more import one security-wise I think, and I >> don't >> >> > think >> >> > >> should be relegated to a plugin. >> >> > >> >> >> > >> I'm hoping medium-term that CSP can replace the use-case of #1. >> >> > >> >> >> > >> >> >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland < >> iclell...@chromium.org >> >> > >> >> > >> wrote: >> >> > >> >> >> > >> > What would be the security implication of removing it from >> core? No >> >> > >> access >> >> > >> > at all by default? Or unlimited access by default? >> >> > >> > >> >> > >> > I suspect that if the default policy with no plugin installed >> is the >> >> > >> > latter, then we will be given the impression that it's not >> important >> >> > at >> >> > >> all >> >> > >> > :) >> >> > >> > >> >> > >> > I had considered just turning the whitelist settings into a >> plugin >> >> -- >> >> > >> > either leaving the default rules as they are, and writing a >> >> > >> > "cordova-security" plugin that locks it down, or tighten >> everything >> >> by >> >> > >> > default, and tell people to install "cordova-plugin-insecurity"
Re: whitelist as a plugin
I'm running into more and more problems caused by the whitelist (today, it's because of the dual use of the internal whitelist for "should be able to navigate to URL" and "should be able to XHR from URL") I'm going to start to pull it out, on a topic branch based off of Android 4.0.x right now. I'll create a JIRA issue to track the work. Is 4.0.x the best place for this to land, or is there any support for putting it on master as well, for an eventual 3.7 release? On Wed, Jul 9, 2014 at 1:22 PM, Shazron wrote: > +1 to remove it for all the above reasons (and WKWebView in iOS 8) > Those interested in this security blanket for checkmark ✓ purposes can > install the plugin, and perhaps maintain it as well. > > On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: > > Or remove it altogether and let the evolution of that code be maintained > by > > those interested in the narrative it provides? :) > > > > On Wednesday, July 9, 2014, Andrew Grieve wrote: > > > >> Sounds like we both agree that it doesn't work and adds a false sense of > >> security (to those that do opt into it) :P. > >> > >> Maybe what we should do is redesign the whitelist to do something more > >> useful. > >> > >> e.g. A whitelist that says what URLs you can navigate to is useful and > easy > >> to implement. Let's just drop the trying to stop network requests > aspect of > >> it? > >> > >> > >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser >> > wrote: > >> > >> > I'm in agreement with Andrew on this one. If we can get CSP working, > >> > that's a far better solution than our Whitelist, which was done > >> > because it was needed at the time for the enterprise use case that IBM > >> > had. I don't think we're ever going to stop are users from doing dumb > >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in > >> > their apps any time soon, but they'll have to jump through more hoops > >> > to do dumb things, and making dumb things harder is a good thing. > >> > > >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > >> wrote: > >> > > Heh. Why do we always seem to be at the opposite end of > considerations? > >> > > (Not a bad thing anyhow. ;) > >> > > > >> > > So making whitelist a plugin would most certainly isolate the code > >> which > >> > > would help us better understand: > >> > > > >> > > 1.) where the surface for bugs are (we seem to miss/find new > security > >> > holes > >> > > each quarter…) > >> > > 2.) if people actually use it > >> > > > >> > > I'm more interested in #2. I suspect the only people whom do use it > are > >> > > security researchers disproving the whitelist veracity. I feel this > API > >> > was > >> > > a mistake, is misleading, and ultimately leads to poor web security > >> > > practices wrt 3rd part scripts. I'd like the evidence to remove it > >> > > completely and making it a plugin would do that. (And still allow > for > >> its > >> > > existence to those whom want to contribute to a "marketing" based > api.) > >> > > > >> > > > >> > > > >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve >> > > >> > wrote: > >> > > > >> > >> I don't think moving the whitelist to a plugin would aid in its > >> > >> understanding. Right now the whitelist is used for two things: > >> > >> > >> > >> 1. Whether to allow network requests through (although this is > broken > >> > for > >> > >> / on iOS, and broken for them + websockets on Android > >> > >> 2. Whether to allow top frame navigations (e.g. clicking a link to > >> > http:// > >> > >> * > >> > >> opens in system browser vs. webview) > >> > >> > >> > >> #1 doesn't work very well due to technical limitations. > >> > >> #2 is actually the more import one security-wise I think, and I > don't > >> > think > >> > >> should be relegated to a plugin. > >> > >> > >> > >> I'm hoping medium-term that CSP can replace the use-case of #1. > >> > >> > >> > >> > >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland < > iclell...@chromium.org > >> > > >> > >> wrote: > >> > >> > >> > >> > What would be the security implication of removing it from core? > No > >> > >> access > >> > >> > at all by default? Or unlimited access by default? > >> > >> > > >> > >> > I suspect that if the default policy with no plugin installed is > the > >> > >> > latter, then we will be given the impression that it's not > important > >> > at > >> > >> all > >> > >> > :) > >> > >> > > >> > >> > I had considered just turning the whitelist settings into a > plugin > >> -- > >> > >> > either leaving the default rules as they are, and writing a > >> > >> > "cordova-security" plugin that locks it down, or tighten > everything > >> by > >> > >> > default, and tell people to install "cordova-plugin-insecurity" > if > >> > they > >> > >> > want to open it up :) > >> > >> > > >> > >> > I like the idea of making the entire whitelist architecture into > a > >> > >> plugin, > >> > >> > though. If nothing else, it should be easier to reason about it, > and > >> > >> easier > >> > >> > to
Re: whitelist as a plugin
+1 to remove it for all the above reasons (and WKWebView in iOS 8) Those interested in this security blanket for checkmark ✓ purposes can install the plugin, and perhaps maintain it as well. On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux wrote: > Or remove it altogether and let the evolution of that code be maintained by > those interested in the narrative it provides? :) > > On Wednesday, July 9, 2014, Andrew Grieve wrote: > >> Sounds like we both agree that it doesn't work and adds a false sense of >> security (to those that do opt into it) :P. >> >> Maybe what we should do is redesign the whitelist to do something more >> useful. >> >> e.g. A whitelist that says what URLs you can navigate to is useful and easy >> to implement. Let's just drop the trying to stop network requests aspect of >> it? >> >> >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > > wrote: >> >> > I'm in agreement with Andrew on this one. If we can get CSP working, >> > that's a far better solution than our Whitelist, which was done >> > because it was needed at the time for the enterprise use case that IBM >> > had. I don't think we're ever going to stop are users from doing dumb >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in >> > their apps any time soon, but they'll have to jump through more hoops >> > to do dumb things, and making dumb things harder is a good thing. >> > >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > >> wrote: >> > > Heh. Why do we always seem to be at the opposite end of considerations? >> > > (Not a bad thing anyhow. ;) >> > > >> > > So making whitelist a plugin would most certainly isolate the code >> which >> > > would help us better understand: >> > > >> > > 1.) where the surface for bugs are (we seem to miss/find new security >> > holes >> > > each quarter…) >> > > 2.) if people actually use it >> > > >> > > I'm more interested in #2. I suspect the only people whom do use it are >> > > security researchers disproving the whitelist veracity. I feel this API >> > was >> > > a mistake, is misleading, and ultimately leads to poor web security >> > > practices wrt 3rd part scripts. I'd like the evidence to remove it >> > > completely and making it a plugin would do that. (And still allow for >> its >> > > existence to those whom want to contribute to a "marketing" based api.) >> > > >> > > >> > > >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve > > >> > wrote: >> > > >> > >> I don't think moving the whitelist to a plugin would aid in its >> > >> understanding. Right now the whitelist is used for two things: >> > >> >> > >> 1. Whether to allow network requests through (although this is broken >> > for >> > >> / on iOS, and broken for them + websockets on Android >> > >> 2. Whether to allow top frame navigations (e.g. clicking a link to >> > http:// >> > >> * >> > >> opens in system browser vs. webview) >> > >> >> > >> #1 doesn't work very well due to technical limitations. >> > >> #2 is actually the more import one security-wise I think, and I don't >> > think >> > >> should be relegated to a plugin. >> > >> >> > >> I'm hoping medium-term that CSP can replace the use-case of #1. >> > >> >> > >> >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland > > >> > >> wrote: >> > >> >> > >> > What would be the security implication of removing it from core? No >> > >> access >> > >> > at all by default? Or unlimited access by default? >> > >> > >> > >> > I suspect that if the default policy with no plugin installed is the >> > >> > latter, then we will be given the impression that it's not important >> > at >> > >> all >> > >> > :) >> > >> > >> > >> > I had considered just turning the whitelist settings into a plugin >> -- >> > >> > either leaving the default rules as they are, and writing a >> > >> > "cordova-security" plugin that locks it down, or tighten everything >> by >> > >> > default, and tell people to install "cordova-plugin-insecurity" if >> > they >> > >> > want to open it up :) >> > >> > >> > >> > I like the idea of making the entire whitelist architecture into a >> > >> plugin, >> > >> > though. If nothing else, it should be easier to reason about it, and >> > >> easier >> > >> > to fix or replace it in the future if we need to. >> > >> > >> > >> > >> > >> > On Mon, Jul 7, 2014 at 3:55 PM, Shazron > > wrote: >> > >> > >> > >> > > Actually it's already possible in any iOS version, we just have to >> > >> > > make sure the plugin loads at startup. This is for UIWebView only, >> > >> > > WKWebView has this issue: >> > >> > > https://issues.apache.org/jira/browse/CB-7049 - you can't >> intercept >> > >> > > any requests from it currently (not sure if anything changed in >> iOS >> > 8 >> > >> > > beta 3) >> > >> > > >> > >> > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux > > wrote: >> > >> > > > Was discussing this w/ Shaz and Joe and, in theory, this is >> > possible >> > >> > from >> > >> > > > iOS8 onward and possibly w/ some refactoring in the 4.x series >> of >> > >> >
Re: whitelist as a plugin
Or remove it altogether and let the evolution of that code be maintained by those interested in the narrative it provides? :) On Wednesday, July 9, 2014, Andrew Grieve wrote: > Sounds like we both agree that it doesn't work and adds a false sense of > security (to those that do opt into it) :P. > > Maybe what we should do is redesign the whitelist to do something more > useful. > > e.g. A whitelist that says what URLs you can navigate to is useful and easy > to implement. Let's just drop the trying to stop network requests aspect of > it? > > > On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser > wrote: > > > I'm in agreement with Andrew on this one. If we can get CSP working, > > that's a far better solution than our Whitelist, which was done > > because it was needed at the time for the enterprise use case that IBM > > had. I don't think we're ever going to stop are users from doing dumb > > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in > > their apps any time soon, but they'll have to jump through more hoops > > to do dumb things, and making dumb things harder is a good thing. > > > > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux > > wrote: > > > Heh. Why do we always seem to be at the opposite end of considerations? > > > (Not a bad thing anyhow. ;) > > > > > > So making whitelist a plugin would most certainly isolate the code > which > > > would help us better understand: > > > > > > 1.) where the surface for bugs are (we seem to miss/find new security > > holes > > > each quarter…) > > > 2.) if people actually use it > > > > > > I'm more interested in #2. I suspect the only people whom do use it are > > > security researchers disproving the whitelist veracity. I feel this API > > was > > > a mistake, is misleading, and ultimately leads to poor web security > > > practices wrt 3rd part scripts. I'd like the evidence to remove it > > > completely and making it a plugin would do that. (And still allow for > its > > > existence to those whom want to contribute to a "marketing" based api.) > > > > > > > > > > > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve > > > wrote: > > > > > >> I don't think moving the whitelist to a plugin would aid in its > > >> understanding. Right now the whitelist is used for two things: > > >> > > >> 1. Whether to allow network requests through (although this is broken > > for > > >> / on iOS, and broken for them + websockets on Android > > >> 2. Whether to allow top frame navigations (e.g. clicking a link to > > http:// > > >> * > > >> opens in system browser vs. webview) > > >> > > >> #1 doesn't work very well due to technical limitations. > > >> #2 is actually the more import one security-wise I think, and I don't > > think > > >> should be relegated to a plugin. > > >> > > >> I'm hoping medium-term that CSP can replace the use-case of #1. > > >> > > >> > > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland > > > >> wrote: > > >> > > >> > What would be the security implication of removing it from core? No > > >> access > > >> > at all by default? Or unlimited access by default? > > >> > > > >> > I suspect that if the default policy with no plugin installed is the > > >> > latter, then we will be given the impression that it's not important > > at > > >> all > > >> > :) > > >> > > > >> > I had considered just turning the whitelist settings into a plugin > -- > > >> > either leaving the default rules as they are, and writing a > > >> > "cordova-security" plugin that locks it down, or tighten everything > by > > >> > default, and tell people to install "cordova-plugin-insecurity" if > > they > > >> > want to open it up :) > > >> > > > >> > I like the idea of making the entire whitelist architecture into a > > >> plugin, > > >> > though. If nothing else, it should be easier to reason about it, and > > >> easier > > >> > to fix or replace it in the future if we need to. > > >> > > > >> > > > >> > On Mon, Jul 7, 2014 at 3:55 PM, Shazron > wrote: > > >> > > > >> > > Actually it's already possible in any iOS version, we just have to > > >> > > make sure the plugin loads at startup. This is for UIWebView only, > > >> > > WKWebView has this issue: > > >> > > https://issues.apache.org/jira/browse/CB-7049 - you can't > intercept > > >> > > any requests from it currently (not sure if anything changed in > iOS > > 8 > > >> > > beta 3) > > >> > > > > >> > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux > wrote: > > >> > > > Was discussing this w/ Shaz and Joe and, in theory, this is > > possible > > >> > from > > >> > > > iOS8 onward and possibly w/ some refactoring in the 4.x series > of > > >> > > Android. > > >> > > > > > >> > > > Its also probably the single most problematic areas of > > >> misunderstanding > > >> > > as > > >> > > > it relates to security we have. Isolating it from core would > give > > us > > >> a > > >> > > > better picture of how important it truly is. > > >> > > > > > >> > > > Thoughts? > > >> > > > > >> > > > >> > > >
Re: whitelist as a plugin
Sounds like we both agree that it doesn't work and adds a false sense of security (to those that do opt into it) :P. Maybe what we should do is redesign the whitelist to do something more useful. e.g. A whitelist that says what URLs you can navigate to is useful and easy to implement. Let's just drop the trying to stop network requests aspect of it? On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser wrote: > I'm in agreement with Andrew on this one. If we can get CSP working, > that's a far better solution than our Whitelist, which was done > because it was needed at the time for the enterprise use case that IBM > had. I don't think we're ever going to stop are users from doing dumb > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in > their apps any time soon, but they'll have to jump through more hoops > to do dumb things, and making dumb things harder is a good thing. > > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux wrote: > > Heh. Why do we always seem to be at the opposite end of considerations? > > (Not a bad thing anyhow. ;) > > > > So making whitelist a plugin would most certainly isolate the code which > > would help us better understand: > > > > 1.) where the surface for bugs are (we seem to miss/find new security > holes > > each quarter…) > > 2.) if people actually use it > > > > I'm more interested in #2. I suspect the only people whom do use it are > > security researchers disproving the whitelist veracity. I feel this API > was > > a mistake, is misleading, and ultimately leads to poor web security > > practices wrt 3rd part scripts. I'd like the evidence to remove it > > completely and making it a plugin would do that. (And still allow for its > > existence to those whom want to contribute to a "marketing" based api.) > > > > > > > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve > wrote: > > > >> I don't think moving the whitelist to a plugin would aid in its > >> understanding. Right now the whitelist is used for two things: > >> > >> 1. Whether to allow network requests through (although this is broken > for > >> / on iOS, and broken for them + websockets on Android > >> 2. Whether to allow top frame navigations (e.g. clicking a link to > http:// > >> * > >> opens in system browser vs. webview) > >> > >> #1 doesn't work very well due to technical limitations. > >> #2 is actually the more import one security-wise I think, and I don't > think > >> should be relegated to a plugin. > >> > >> I'm hoping medium-term that CSP can replace the use-case of #1. > >> > >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland > >> wrote: > >> > >> > What would be the security implication of removing it from core? No > >> access > >> > at all by default? Or unlimited access by default? > >> > > >> > I suspect that if the default policy with no plugin installed is the > >> > latter, then we will be given the impression that it's not important > at > >> all > >> > :) > >> > > >> > I had considered just turning the whitelist settings into a plugin -- > >> > either leaving the default rules as they are, and writing a > >> > "cordova-security" plugin that locks it down, or tighten everything by > >> > default, and tell people to install "cordova-plugin-insecurity" if > they > >> > want to open it up :) > >> > > >> > I like the idea of making the entire whitelist architecture into a > >> plugin, > >> > though. If nothing else, it should be easier to reason about it, and > >> easier > >> > to fix or replace it in the future if we need to. > >> > > >> > > >> > On Mon, Jul 7, 2014 at 3:55 PM, Shazron wrote: > >> > > >> > > Actually it's already possible in any iOS version, we just have to > >> > > make sure the plugin loads at startup. This is for UIWebView only, > >> > > WKWebView has this issue: > >> > > https://issues.apache.org/jira/browse/CB-7049 - you can't intercept > >> > > any requests from it currently (not sure if anything changed in iOS > 8 > >> > > beta 3) > >> > > > >> > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux wrote: > >> > > > Was discussing this w/ Shaz and Joe and, in theory, this is > possible > >> > from > >> > > > iOS8 onward and possibly w/ some refactoring in the 4.x series of > >> > > Android. > >> > > > > >> > > > Its also probably the single most problematic areas of > >> misunderstanding > >> > > as > >> > > > it relates to security we have. Isolating it from core would give > us > >> a > >> > > > better picture of how important it truly is. > >> > > > > >> > > > Thoughts? > >> > > > >> > > >> >
Re: whitelist as a plugin
I'm in agreement with Andrew on this one. If we can get CSP working, that's a far better solution than our Whitelist, which was done because it was needed at the time for the enterprise use case that IBM had. I don't think we're ever going to stop are users from doing dumb things like including thirdpartyadnetworkthatdoesnoteusehttps.js in their apps any time soon, but they'll have to jump through more hoops to do dumb things, and making dumb things harder is a good thing. On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux wrote: > Heh. Why do we always seem to be at the opposite end of considerations? > (Not a bad thing anyhow. ;) > > So making whitelist a plugin would most certainly isolate the code which > would help us better understand: > > 1.) where the surface for bugs are (we seem to miss/find new security holes > each quarter…) > 2.) if people actually use it > > I'm more interested in #2. I suspect the only people whom do use it are > security researchers disproving the whitelist veracity. I feel this API was > a mistake, is misleading, and ultimately leads to poor web security > practices wrt 3rd part scripts. I'd like the evidence to remove it > completely and making it a plugin would do that. (And still allow for its > existence to those whom want to contribute to a "marketing" based api.) > > > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve wrote: > >> I don't think moving the whitelist to a plugin would aid in its >> understanding. Right now the whitelist is used for two things: >> >> 1. Whether to allow network requests through (although this is broken for >> / on iOS, and broken for them + websockets on Android >> 2. Whether to allow top frame navigations (e.g. clicking a link to http:// >> * >> opens in system browser vs. webview) >> >> #1 doesn't work very well due to technical limitations. >> #2 is actually the more import one security-wise I think, and I don't think >> should be relegated to a plugin. >> >> I'm hoping medium-term that CSP can replace the use-case of #1. >> >> >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland >> wrote: >> >> > What would be the security implication of removing it from core? No >> access >> > at all by default? Or unlimited access by default? >> > >> > I suspect that if the default policy with no plugin installed is the >> > latter, then we will be given the impression that it's not important at >> all >> > :) >> > >> > I had considered just turning the whitelist settings into a plugin -- >> > either leaving the default rules as they are, and writing a >> > "cordova-security" plugin that locks it down, or tighten everything by >> > default, and tell people to install "cordova-plugin-insecurity" if they >> > want to open it up :) >> > >> > I like the idea of making the entire whitelist architecture into a >> plugin, >> > though. If nothing else, it should be easier to reason about it, and >> easier >> > to fix or replace it in the future if we need to. >> > >> > >> > On Mon, Jul 7, 2014 at 3:55 PM, Shazron wrote: >> > >> > > Actually it's already possible in any iOS version, we just have to >> > > make sure the plugin loads at startup. This is for UIWebView only, >> > > WKWebView has this issue: >> > > https://issues.apache.org/jira/browse/CB-7049 - you can't intercept >> > > any requests from it currently (not sure if anything changed in iOS 8 >> > > beta 3) >> > > >> > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux wrote: >> > > > Was discussing this w/ Shaz and Joe and, in theory, this is possible >> > from >> > > > iOS8 onward and possibly w/ some refactoring in the 4.x series of >> > > Android. >> > > > >> > > > Its also probably the single most problematic areas of >> misunderstanding >> > > as >> > > > it relates to security we have. Isolating it from core would give us >> a >> > > > better picture of how important it truly is. >> > > > >> > > > Thoughts? >> > > >> > >>
Re: whitelist as a plugin
Heh. Why do we always seem to be at the opposite end of considerations? (Not a bad thing anyhow. ;) So making whitelist a plugin would most certainly isolate the code which would help us better understand: 1.) where the surface for bugs are (we seem to miss/find new security holes each quarter…) 2.) if people actually use it I'm more interested in #2. I suspect the only people whom do use it are security researchers disproving the whitelist veracity. I feel this API was a mistake, is misleading, and ultimately leads to poor web security practices wrt 3rd part scripts. I'd like the evidence to remove it completely and making it a plugin would do that. (And still allow for its existence to those whom want to contribute to a "marketing" based api.) On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve wrote: > I don't think moving the whitelist to a plugin would aid in its > understanding. Right now the whitelist is used for two things: > > 1. Whether to allow network requests through (although this is broken for > / on iOS, and broken for them + websockets on Android > 2. Whether to allow top frame navigations (e.g. clicking a link to http:// > * > opens in system browser vs. webview) > > #1 doesn't work very well due to technical limitations. > #2 is actually the more import one security-wise I think, and I don't think > should be relegated to a plugin. > > I'm hoping medium-term that CSP can replace the use-case of #1. > > > On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland > wrote: > > > What would be the security implication of removing it from core? No > access > > at all by default? Or unlimited access by default? > > > > I suspect that if the default policy with no plugin installed is the > > latter, then we will be given the impression that it's not important at > all > > :) > > > > I had considered just turning the whitelist settings into a plugin -- > > either leaving the default rules as they are, and writing a > > "cordova-security" plugin that locks it down, or tighten everything by > > default, and tell people to install "cordova-plugin-insecurity" if they > > want to open it up :) > > > > I like the idea of making the entire whitelist architecture into a > plugin, > > though. If nothing else, it should be easier to reason about it, and > easier > > to fix or replace it in the future if we need to. > > > > > > On Mon, Jul 7, 2014 at 3:55 PM, Shazron wrote: > > > > > Actually it's already possible in any iOS version, we just have to > > > make sure the plugin loads at startup. This is for UIWebView only, > > > WKWebView has this issue: > > > https://issues.apache.org/jira/browse/CB-7049 - you can't intercept > > > any requests from it currently (not sure if anything changed in iOS 8 > > > beta 3) > > > > > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux wrote: > > > > Was discussing this w/ Shaz and Joe and, in theory, this is possible > > from > > > > iOS8 onward and possibly w/ some refactoring in the 4.x series of > > > Android. > > > > > > > > Its also probably the single most problematic areas of > misunderstanding > > > as > > > > it relates to security we have. Isolating it from core would give us > a > > > > better picture of how important it truly is. > > > > > > > > Thoughts? > > > > > >
Re: whitelist as a plugin
I don't think moving the whitelist to a plugin would aid in its understanding. Right now the whitelist is used for two things: 1. Whether to allow network requests through (although this is broken for / on iOS, and broken for them + websockets on Android 2. Whether to allow top frame navigations (e.g. clicking a link to http://* opens in system browser vs. webview) #1 doesn't work very well due to technical limitations. #2 is actually the more import one security-wise I think, and I don't think should be relegated to a plugin. I'm hoping medium-term that CSP can replace the use-case of #1. On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland wrote: > What would be the security implication of removing it from core? No access > at all by default? Or unlimited access by default? > > I suspect that if the default policy with no plugin installed is the > latter, then we will be given the impression that it's not important at all > :) > > I had considered just turning the whitelist settings into a plugin -- > either leaving the default rules as they are, and writing a > "cordova-security" plugin that locks it down, or tighten everything by > default, and tell people to install "cordova-plugin-insecurity" if they > want to open it up :) > > I like the idea of making the entire whitelist architecture into a plugin, > though. If nothing else, it should be easier to reason about it, and easier > to fix or replace it in the future if we need to. > > > On Mon, Jul 7, 2014 at 3:55 PM, Shazron wrote: > > > Actually it's already possible in any iOS version, we just have to > > make sure the plugin loads at startup. This is for UIWebView only, > > WKWebView has this issue: > > https://issues.apache.org/jira/browse/CB-7049 - you can't intercept > > any requests from it currently (not sure if anything changed in iOS 8 > > beta 3) > > > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux wrote: > > > Was discussing this w/ Shaz and Joe and, in theory, this is possible > from > > > iOS8 onward and possibly w/ some refactoring in the 4.x series of > > Android. > > > > > > Its also probably the single most problematic areas of misunderstanding > > as > > > it relates to security we have. Isolating it from core would give us a > > > better picture of how important it truly is. > > > > > > Thoughts? > > >
Re: whitelist as a plugin
What would be the security implication of removing it from core? No access at all by default? Or unlimited access by default? I suspect that if the default policy with no plugin installed is the latter, then we will be given the impression that it's not important at all :) I had considered just turning the whitelist settings into a plugin -- either leaving the default rules as they are, and writing a "cordova-security" plugin that locks it down, or tighten everything by default, and tell people to install "cordova-plugin-insecurity" if they want to open it up :) I like the idea of making the entire whitelist architecture into a plugin, though. If nothing else, it should be easier to reason about it, and easier to fix or replace it in the future if we need to. On Mon, Jul 7, 2014 at 3:55 PM, Shazron wrote: > Actually it's already possible in any iOS version, we just have to > make sure the plugin loads at startup. This is for UIWebView only, > WKWebView has this issue: > https://issues.apache.org/jira/browse/CB-7049 - you can't intercept > any requests from it currently (not sure if anything changed in iOS 8 > beta 3) > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux wrote: > > Was discussing this w/ Shaz and Joe and, in theory, this is possible from > > iOS8 onward and possibly w/ some refactoring in the 4.x series of > Android. > > > > Its also probably the single most problematic areas of misunderstanding > as > > it relates to security we have. Isolating it from core would give us a > > better picture of how important it truly is. > > > > Thoughts? >
Re: whitelist as a plugin
Actually it's already possible in any iOS version, we just have to make sure the plugin loads at startup. This is for UIWebView only, WKWebView has this issue: https://issues.apache.org/jira/browse/CB-7049 - you can't intercept any requests from it currently (not sure if anything changed in iOS 8 beta 3) On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux wrote: > Was discussing this w/ Shaz and Joe and, in theory, this is possible from > iOS8 onward and possibly w/ some refactoring in the 4.x series of Android. > > Its also probably the single most problematic areas of misunderstanding as > it relates to security we have. Isolating it from core would give us a > better picture of how important it truly is. > > Thoughts?
