Should encrypted store fail to open when passphrase is wrong?
by Tadeas Kriz
Hey,
I know we’ve been discussing this before, but with no solution. I myself think, that the store should fail to open when the passphrase is wrong, because that’s where you’d like to have your “try .. catch ..” to handle the problem, not elsewhere, when you want to actually read/write/delete from the store, that’s just not very user friendly.
If the answer to that is YES, then the next question is, how to decide when the passphrase is right and when it isn’t. Again I’ll write more ways I’ve got on mind, that’d solve this. Important is, that none of them actually stores the passphrase!
On each call of ‘open()’:
1. do ‘readAll()’ to ensure the passphrase is right. Basically, that’s what user has to do now to find out if the passphrase is right.
2. read the first row and if the read is successful, then the passphrase is right. In this case, we’d have to be 100% sure that there is no way to put data into the store with different key and thus all the rows are encrypted with the same passphrase.
3. Save some metadata for each data model, that would be encrypted with the same passphrase and we’d read them and if successful, the passphrase is right. This has two possible implementations.
a. The first row in the data model table would be reserved for the metadata, so the verification would work similarly to the option 2.
b. There would be separate table, in which we’d add a row for each data model table. Again, very similar to a. but without the pain of having different data in the same table. Also, if the implementation of SQLStore will become multi-table (instead of multi-database which is now), there would be only one table for all the metadata.
So, what do you think?
PS: For abstractj, I’ve been trying to find any library that would do the encryption on high-level, as AeroGear does, but couldn’t find any. There are many ways to encrypt SQLite database though they work on different approach of encrypting the whole database file, not just rows themselves.
—
Tadeas Kriz
tkriz(a)redhat.com
12 years, 3 months
Encrypted Store
by Summers Pittman
Hi.
On Android and iOS you CAN mix data keys in the datastore, but this will
cause the readAll method to fail.
On Android we are planning on fixing this (there is a JIRA somewhere) to
make it so that we will do simple key checks.
How does JavaScript do encrypted stores and how does it work when you
begin mixing/matching keys.
12 years, 3 months
JS Future Roadmap
by Lucas Holmquist
I was having some thoughts on the future of AeroGear.js that i needed to share.
Experimental Branch
I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…
I feel this is the only way to drive innovation
I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.
I still however want the code in this branch to be complete, not just random crap
2.0
I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.
The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point
I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size
1.X Branch
Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority
This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )
12 years, 3 months
iOS Factory Classes
by Summers Pittman
One of the things I brought up in the review of the iOS OAUTH2 PR was
that the Authz factory class, AGAuthorizer, does not allow injection of
custom Authorizors.
Corrine mentioned that this wasn't done for any of the other classes
(Pipeline, Authentication, etc). I know Android does this (via an add
method and also allows you to supply a custom builder) and I am pretty
sure JavaScript has an add method as well.
Just wanted to bring up this place where the platforms diverged and get
community input.
Back to coffee,
Summers
12 years, 3 months
Re: [aerogear-dev] does aerogear supported by mobile firefox
by Lucas Holmquist
On Jan 20, 2014, at 12:04 PM, naveenraj bala <mailnaveenraj(a)gmail.com> wrote:
> I would be glad if i also knew about both . You made me courious. Do you have road map for FireFox OS . I never saw any like that.
we don't have anything currently on the Road Map for FFoS, but the the "apps" you create for it are all html/javascript/css based, so our JS libs should work fine with it.
as for Firefox Mobile on Android, we are in the process of revamping our supported browser targets, but there is no reason that it, aerogear.js, shouldn't work fine since we currently use jQuery behind the scenes to do ajax
>
> Thanks,
> Naveen Raj Balasubramaniam
>
>
> On Mon, Jan 20, 2014 at 7:25 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
> Hi, are you talking about FireFox OS or the firefox Mobile Browser on Android?
>
> On Jan 19, 2014, at 4:06 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> Hello Naveenraj,
>>
>> Besides the mentioned app, last week Erik Jan also did create an new app, for FirefoxOS:
>>
>> https://github.com/edewit/aerogear-aerodoc-firefoxos
>>
>> It is basically a port of our 'push show case'.
>>
>> I think these two different apps should give you a good starting point, how to use AeroGear APIs on a FirefoxOS device
>>
>> Greetings,
>> Matthias
>>
>>
>> On Sun, Jan 19, 2014 at 9:49 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>> Good morning my friend, not yet. But if you want to start with something, Daniel Passos wrote an application using AeroGear JS (https://github.com/danielpassos/call4paperz4FirefoxOS)
>>
>>
>>
>> --
>> abstractj
>>
>> On January 18, 2014 at 5:22:42 PM, Naveenraj (mailnaveenraj(a)gmail.com) wrote:
>> > > I just wantbto know if mozilla Firefox mobile is supported or
>> > not.
>> > In the tbd of mobile browser I am not able to find Firefox mobile.
>> > .
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
12 years, 3 months
AeroGear January sync release postponed
by Jay Balunas
Hi All,
We've been making a lot of progress on sync, but as many of you likely already know it is not ready for a full focused release. Much like encryption, sync is a significant feature and is still in active R&D and likely needs multiple iterations given its complexity. Its much better to let this mature organically that force it out the door before its out of diapers :-)
So with that said, I propose postponing the planned January umbrella release. I think we should revisit our roadmaps and plans during this time, before trying to set new release dates. While we do this we should make sure to add in time for updates to docs, examples, getting started items, site, cookbooks, etc...
Thoughts?
Jay
12 years, 3 months
