You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2014/02/01 02:38:44 UTC

Re: [Android] SecureToken/NoFrak feature addition

On Fri, Jan 31, 2014 at 5:46 PM, Joe Bowser <bo...@gmail.com> wrote:

> OK, in the interest of moving things along, I think we agreed to the
> following:
>
> 1. Adding a SecureToken is a good idea and we should implement this somehow
> 2. We should stop supporting the 2.9.x branch of Cordova like we said we
> would
> 3. We should disable addJavascriptInterface for any level below API level
> 17
>
Yep, these all sound good! Just need to hash out how to do #1, (2 and #3
don't depend on it).


>
> I'd like to preserve our old behaviour of blocking anything not
> explicitly whitelisted, and have the ability to turn on mixed content
> in iFrames with a configuration setting.  How can we move forward with
> this?
>
Not sure what you mean about turning on mixed content.



>
> On Fri, Jan 31, 2014 at 1:45 PM, Joe Bowser <bo...@gmail.com> wrote:
> > Not if your certificate is compromised.  Remember our Certificate
> > Pinning discussion!
> >
> > On Fri, Jan 31, 2014 at 1:43 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >> On Fri, Jan 31, 2014 at 4:34 PM, Martin Georgiev <mgeorgiev@utexas.edu
> >wrote:
> >>
> >>> On Fri, Jan 31, 2014 at 3:27 PM, Andrew Grieve <ag...@chromium.org>
> >>> wrote:
> >>> > Why is loadUrl insecure? (hopefully something less horrible than
> >>> > addJsInterface pre JB... :P)
> >>>
> >>> Think about the usecase where a benign website is framed by a
> >>> malicious one. Again, this is server side. The app developer can't
> >>> prevent it from happening. The framework developer must make sure that
> >>> all usecases are handled properly.
> >>>
> >>
> >>
> >> Ah, I hadn't considered that the main frame might be malicious.
> >>
> >> I don't see how this would happen with a Cordova app though. We strongly
> >> encourage users to use file:/// URLs for their app. For those that use
> >> HTTP, that's insecure anyways and would be whitelisted by this scheme.
> If
> >> you use HTTPS, then you should be fine, no?
>