Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.220.48 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAOBL_k7dQ34kLFp5iAAy9car_vXay3OyK-bcvVF6fau=1qV0Cg@mail.gmail.com>
References: 
 <CAOBL_k5oqzLMCx5_X0p94uSfA1Jy=gUWr+_p4j-6m6ry0+33Mw@mail.gmail.com>
 <CAK_TSXJbjLPmh8SjhK2q=24VQ59ConxJzu8YyV_ZZN7RWO34mw@mail.gmail.com>
 <CAOBL_k70J6bZjUdZed3gTEejWsn-xbu-6JoD70njOhnJo9pwEA@mail.gmail.com>
 <CABiQX1VhTVJ0fJ+r01Ba0kXEk+nKhCNNbWKzmwLNQ00b4qLvMw@mail.gmail.com>
 <a4aa7b5f3a9ca26b94e5936b3dd36fc2.squirrel@webmail2.colokoe.net>
 <CAOBL_k7dQ34kLFp5iAAy9car_vXay3OyK-bcvVF6fau=1qV0Cg@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Fri, 31 Jan 2014 14:01:55 -0500
Message-ID: 
 <CABiQX1WozRbdkKT1a1XURk1a4z9UB4FDp4Vb+T4coqQr7cpxSA@mail.gmail.com>
Subject: Re: [Android] SecureToken/NoFrak feature addition
To: dev <dev@cordova.apache.org>, "bowserj@apache.org" <bowserj@apache.org>
Cc: mail@nazgul.nu
Content-Type: multipart/alternative; boundary=e89a8f923df2f1672404f148cf48

--e89a8f923df2f1672404f148cf48
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 31, 2014 at 1:32 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Fri, Jan 31, 2014 at 8:57 AM, Bas Bosman <mail@nazgul.nu> wrote:
> >
> > LocalStorage leverages the browser's same origin policy to ensure that
> > content from other origins cannot read the token and thus cannot access
> > the bridge. If we use vanilla JS there is nothing stopping the malicious
> > code from reading the random # itself before calling the bridge.
> >
>
> We're not using Vanilla JS.  Tokens have to be added for all
> whitelisted domains natively.  This is done to solve the whole Chicken
> and the Egg problem that we have with our config.xml.  The value
> should exist when the browser gets access to the storage, and it has
> to match what it is natively, which I believed is stored in memory, so
> even if the value was added in Vanilla JS, it would be caught and set
> as invalid.  I haven't tested that.
>

localstorage would allow iframes on different domains than the top one to
use the bridge. I don't think that's very compelling. iframes can use
postMessage() to talk to the main frame, which in turn can call exec. If
you really wanted to, you could provide the token to the iframe via
postMessage. Localstorage seems like overkill to me still though.

I don't think there's a chicken and egg problem:
State 0 - Native has no token, JS has no token
State 1 - JS in main frame include cordova.js
State 2 - JS in main frame generates a token, and provides it to native
State 3 - Native, not already having a token, accepts it and saves it.

Now both JS and native have the same token in memory without needing to go
through localstorage.

--e89a8f923df2f1672404f148cf48--