cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [Android] SecureToken/NoFrak feature addition
Date Fri, 31 Jan 2014 21:27:02 GMT
On Fri, Jan 31, 2014 at 4:13 PM, Martin Georgiev <mgeorgiev@utexas.edu>wrote:

> On Fri, Jan 31, 2014 at 2:58 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> > Ha! Well that's pretty clear. :) I don't think having JS generate it is a
> > good idea then.
>
> It is not. You as an app developer do not control who puts where their JS.
>
>
> > Still, there might be an easier way than going through persistent
> storage.
>
> The reason for localStorage is cause it leverages SOP. If you find
> another way to leverage SOP, that would be fine too.
>

Providing bridge access to all frames of the same domain is harder than
providing it to just the top-frame, which is our current promise. To make
the bridge respect SOP, we'd need to make changes across all platforms (no
idea how you'd do this on iOS). Since same-domain frames run in the same JS
context, I think it's better to just continue to promise the bridge be
available to the top frame.

I *do* like the idea of explicitly blocking access to non-same-domain
iframes though.


>
> > Next idea:
> > How about having the Java side tell the JS side during start-up what the
> > token is?
> > E.g.: loadUrl(javascript:void(execToken=FOO)). JS can then get the token
> > from there when they want to use exec().
>
> Can't do that, cause loadUrl *is* insecure! Next idea please ;)
>

Why is loadUrl insecure? (hopefully something less horrible than
addJsInterface pre JB... :P)

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