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: local policy)
Message-ID: <a4aa7b5f3a9ca26b94e5936b3dd36fc2.squirrel@webmail2.colokoe.net>
In-Reply-To: 
 <CABiQX1VhTVJ0fJ+r01Ba0kXEk+nKhCNNbWKzmwLNQ00b4qLvMw@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>
Date: Fri, 31 Jan 2014 17:57:34 +0100
Subject: Re: [Android] SecureToken/NoFrak feature addition
From: "Bas Bosman" <mail@nazgul.nu>
To: dev@cordova.apache.org
Cc: "bowserj@apache.org" <bowserj@apache.org>
Reply-To: mail@nazgul.nu
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

>> >> * Drop support for Android 2.3.x - I don't care if it's 20% of the
>> >> market, if an insecure 20% and people need to stop targeting it
>> >> because of how insecure it is.  We can't fix it, and Google and
>> >> handset makers have no interest in fixing it either.  It's the IE6 of
>> >> Mobile, and Android 2.3.x needs to die.  (In hindsight, I feel bad
>> >> for giving a friend of mine my old HTC Desire HD. :( )
Because 20% is still a rather large number I would not be in favor of
dropping support for 2.3.x. Looking at my apps it's even closer to 30%. I
would be in favor though of having 2.3.x support switched off by default,
where people developing apps using Cordova have to explicitly turn that
support on and we can give them good documentation on what that will mean
and how to mitigate risks where possible.

>> >   2. Use a shared secret to authenticate communication across the
>> > bridge  (this is a good idea, probably on all platforms -- I
>> > think there may be better ways of doing this though)
>> I like how NoFrak hijacks localStorage to do it.  If I didn't, I
>> wouldn't recommend we use it. :P
>>
> What's the reason for doing this? E.g. we could
> 1 - Have JS create a random # on start-up
> 2 - Have JS tell the native side the number
> 3 - Have the native side ignore any exec calls that doesn't include that
> number.
>
> Does using localstorage do something more?

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.

Bas