Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY slow combination. Locks up the app for at least 10 seconds. This is regarding both setItem and getItem. The removeItem is actually very fast. No, I haven't tested this outside of ADL.
Turning stronglyBound to false value makes it fast again. Is there anything I can do to optimize that? How about a feature request for AIR 2/3? Seriously... if I need to generate my own CRC checksum or whatever the heck, I'll do it. Or heck, make the function asynchronous and give me an event when done, that's cool too.
I have also been curious about possible race conditions when using
EncryptedLocalStore since it has no event fired when complete. I
guess you can assume that when reading/writing to ELS that the
function following the action does not fire until the read/write is
complete. Going under that big ol assumption, you can fire your own
complete event after the read/write calls. I remain skeptical
though...
On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
> Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY slow
> combination. Locks up the app for at least 10 seconds. This is regarding
> both setItem and getItem. The removeItem is actually very fast.
> No, I haven't tested this outside of ADL.
> Turning stronglyBound to false value makes it fast again. Is there anything
> I can do to optimize that? How about a feature request for AIR 2/3?
> Seriously... if I need to generate my own CRC checksum or whatever the
> heck, I'll do it. Or heck, make the function asynchronous and give me an
> event when done, that's cool too.
On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com> wrote:
> I have also been curious about possible race conditions when using
> EncryptedLocalStore since it has no event fired when complete. I
> guess you can assume that when reading/writing to ELS that the
> function following the action does not fire until the read/write is
> complete. Going under that big ol assumption, you can fire your own
> complete event after the read/write calls. I remain skeptical
> though...
> On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
> > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY slow
> > combination. Locks up the app for at least 10 seconds. This is
> regarding
> > both setItem and getItem. The removeItem is actually very fast.
> > No, I haven't tested this outside of ADL.
> > Turning stronglyBound to false value makes it fast again. Is there
> anything
> > I can do to optimize that? How about a feature request for AIR 2/3?
> > Seriously... if I need to generate my own CRC checksum or whatever the
> > heck, I'll do it. Or heck, make the function asynchronous and give me an
> > event when done, that's cool too.
I do not have race conditions, she works every time. It's just the "working
part" is slow.
The data I'm storing is like less than a couple k; a username and password,
each about 10 characters long. However, my AIR file is 6.4 megs, so I'm
assuming it first has to generate a crc checksum of my AIR file, and then
use that in the comparison via Keychain.
On Fri, Jul 10, 2009 at 1:23 PM, Damon Edwards <dzedw...@gmail.com> wrote:
> What's the rough size of data you're setting?
> On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com>wrote:
>> I have also been curious about possible race conditions when using
>> EncryptedLocalStore since it has no event fired when complete. I
>> guess you can assume that when reading/writing to ELS that the
>> function following the action does not fire until the read/write is
>> complete. Going under that big ol assumption, you can fire your own
>> complete event after the read/write calls. I remain skeptical
>> though...
>> On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
>> > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY slow
>> > combination. Locks up the app for at least 10 seconds. This is
>> regarding
>> > both setItem and getItem. The removeItem is actually very fast.
>> > No, I haven't tested this outside of ADL.
>> > Turning stronglyBound to false value makes it fast again. Is there
>> anything
>> > I can do to optimize that? How about a feature request for AIR 2/3?
>> > Seriously... if I need to generate my own CRC checksum or whatever the
>> > heck, I'll do it. Or heck, make the function asynchronous and give me
>> an
>> > event when done, that's cool too.
The EncryptedLocalStore API operates synchronously; there is no need
to worry about race conditions.
The "strongly bound" feature does indeed checksum the entire
application, which is why it's slow. Frankly, I don't recommend ever
setting this option to true. For storing things like a username/ password pair, you're not getting any real security benefit. And your
cached passwords will be inaccessible after an application update,
which is probably not what you want.
Hope this helps,
Oliver Goldman
Adobe AIR Engineering
> I do not have race conditions, she works every time. It's just the
> "working part" is slow.
> The data I'm storing is like less than a couple k; a username and
> password, each about 10 characters long. However, my AIR file is
> 6.4 megs, so I'm assuming it first has to generate a crc checksum of
> my AIR file, and then use that in the comparison via Keychain.
> On Fri, Jul 10, 2009 at 1:23 PM, Damon Edwards <dzedw...@gmail.com>
> wrote:
> What's the rough size of data you're setting?
> On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com>
> wrote:
> I have also been curious about possible race conditions when using
> EncryptedLocalStore since it has no event fired when complete. I
> guess you can assume that when reading/writing to ELS that the
> function following the action does not fire until the read/write is
> complete. Going under that big ol assumption, you can fire your own
> complete event after the read/write calls. I remain skeptical
> though...
> On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
> > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY
> slow
> > combination. Locks up the app for at least 10 seconds. This is
> regarding
> > both setItem and getItem. The removeItem is actually very fast.
> > No, I haven't tested this outside of ADL.
> > Turning stronglyBound to false value makes it fast again. Is
> there anything
> > I can do to optimize that? How about a feature request for AIR 2/3?
> > Seriously... if I need to generate my own CRC checksum or
> whatever the
> > heck, I'll do it. Or heck, make the function asynchronous and
> give me an
> > event when done, that's cool too.
On Fri, Jul 10, 2009 at 5:02 PM, Oliver Goldman <ogold...@adobe.com> wrote:
> The EncryptedLocalStore API operates synchronously; there is no need to
> worry about race conditions.
> The
> "strongly bound" feature does indeed checksum the entire application, which is why it's slow. Frankly, I don't recommend ever setting this option to true. For storing things like a username/password pair, you're not getting any real security benefit. And your cached passwords will be inaccessible after an application update, which is probably not what you want.
> Hope this helps,
> Oliver Goldman
> Adobe AIR Engineering
> On Jul 10, 2009, at 10:27 AM, Jesse Warden wrote:
> I do not have race conditions, she works every time. It's just the
> "working part" is slow.
> The data I'm storing is like less than a couple k; a username and password,
> each about 10 characters long. However, my AIR file is 6.4 megs, so I'm
> assuming it first has to generate a crc checksum of my AIR file, and then
> use that in the comparison via Keychain.
> On Fri, Jul 10, 2009 at 1:23 PM, Damon Edwards <dzedw...@gmail.com> wrote:
>> What's the rough size of data you're setting?
>> On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com>wrote:
>>> I have also been curious about possible race conditions when using
>>> EncryptedLocalStore since it has no event fired when complete. I
>>> guess you can assume that when reading/writing to ELS that the
>>> function following the action does not fire until the read/write is
>>> complete. Going under that big ol assumption, you can fire your own
>>> complete event after the read/write calls. I remain skeptical
>>> though...
>>> On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
>>> > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY slow
>>> > combination. Locks up the app for at least 10 seconds. This is
>>> regarding
>>> > both setItem and getItem. The removeItem is actually very fast.
>>> > No, I haven't tested this outside of ADL.
>>> > Turning stronglyBound to false value makes it fast again. Is there
>>> anything
>>> > I can do to optimize that? How about a feature request for AIR 2/3?
>>> > Seriously... if I need to generate my own CRC checksum or whatever the
>>> > heck, I'll do it. Or heck, make the function asynchronous and give me
>>> an
>>> > event when done, that's cool too.
It seems like AIR is generating some kind of checksum of the entire
app regardless of whether or not I'm using the strongly bound feature.
When a user starts my app, the first thing I do is read some data from
EncryptedLocalStore - and it hangs for 20-30 seconds. My app is 200
megs in size (several videos), if I build a version without the videos
the delay is much slower.
It's definitely EncryptedLocalStore, if I disable the ELS.getItem()
call at startup there is no delay at first, but the delay happens as
soon as I call EncryptedLocalStore.getItem().
Please tell me there's a workaround!
On Jul 10, 2:02 pm, Oliver Goldman <ogold...@adobe.com> wrote:
> The EncryptedLocalStore API operates synchronously; there is no need
> to worry about race conditions.
> The "strongly bound" feature does indeed checksum the entire
> application, which is why it's slow. Frankly, I don't recommend ever
> setting this option to true. For storing things like a username/
> password pair, you're not getting any real security benefit. And your
> cached passwords will be inaccessible after an application update,
> which is probably not what you want.
> Hope this helps,
> Oliver Goldman
> Adobe AIR Engineering
> On Jul 10, 2009, at 10:27 AM, Jesse Warden wrote:
> > I do not have race conditions, she works every time. It's just the
> > "working part" is slow.
> > The data I'm storing is like less than a couple k; a username and
> > password, each about 10 characters long. However, my AIR file is
> > 6.4 megs, so I'm assuming it first has to generate a crc checksum of
> > my AIR file, and then use that in the comparison via Keychain.
> > On Fri, Jul 10, 2009 at 1:23 PM, Damon Edwards <dzedw...@gmail.com>
> > wrote:
> > What's the rough size of data you're setting?
> > On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com>
> > wrote:
> > I have also been curious about possible race conditions when using
> > EncryptedLocalStore since it has no event fired when complete. I
> > guess you can assume that when reading/writing to ELS that the
> > function following the action does not fire until the read/write is
> > complete. Going under that big ol assumption, you can fire your own
> > complete event after the read/write calls. I remain skeptical
> > though...
> > On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
> > > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY
> > slow
> > > combination. Locks up the app for at least 10 seconds. This is
> > regarding
> > > both setItem and getItem. The removeItem is actually very fast.
> > > No, I haven't tested this outside of ADL.
> > > Turning stronglyBound to false value makes it fast again. Is
> > there anything
> > > I can do to optimize that? How about a feature request for AIR 2/3?
> > > Seriously... if I need to generate my own CRC checksum or
> > whatever the
> > > heck, I'll do it. Or heck, make the function asynchronous and
> > give me an
> > > event when done, that's cool too.
On Thu, Jul 30, 2009 at 4:12 PM, Evan <evancoon...@gmail.com> wrote:
> It seems like AIR is generating some kind of checksum of the entire
> app regardless of whether or not I'm using the strongly bound feature.
> When a user starts my app, the first thing I do is read some data from
> EncryptedLocalStore - and it hangs for 20-30 seconds. My app is 200
> megs in size (several videos), if I build a version without the videos
> the delay is much slower.
> It's definitely EncryptedLocalStore, if I disable the ELS.getItem()
> call at startup there is no delay at first, but the delay happens as
> soon as I call EncryptedLocalStore.getItem().
> Please tell me there's a workaround!
> On Jul 10, 2:02 pm, Oliver Goldman <ogold...@adobe.com> wrote:
> > The EncryptedLocalStore API operates synchronously; there is no need
> > to worry about race conditions.
> > The "strongly bound" feature does indeed checksum the entire
> > application, which is why it's slow. Frankly, I don't recommend ever
> > setting this option to true. For storing things like a username/
> > password pair, you're not getting any real security benefit. And your
> > cached passwords will be inaccessible after an application update,
> > which is probably not what you want.
> > Hope this helps,
> > Oliver Goldman
> > Adobe AIR Engineering
> > On Jul 10, 2009, at 10:27 AM, Jesse Warden wrote:
> > > I do not have race conditions, she works every time. It's just the
> > > "working part" is slow.
> > > The data I'm storing is like less than a couple k; a username and
> > > password, each about 10 characters long. However, my AIR file is
> > > 6.4 megs, so I'm assuming it first has to generate a crc checksum of
> > > my AIR file, and then use that in the comparison via Keychain.
> > > On Fri, Jul 10, 2009 at 1:23 PM, Damon Edwards <dzedw...@gmail.com>
> > > wrote:
> > > What's the rough size of data you're setting?
> > > On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com>
> > > wrote:
> > > I have also been curious about possible race conditions when using
> > > EncryptedLocalStore since it has no event fired when complete. I
> > > guess you can assume that when reading/writing to ELS that the
> > > function following the action does not fire until the read/write is
> > > complete. Going under that big ol assumption, you can fire your own
> > > complete event after the read/write calls. I remain skeptical
> > > though...
> > > On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
> > > > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY
> > > slow
> > > > combination. Locks up the app for at least 10 seconds. This is
> > > regarding
> > > > both setItem and getItem. The removeItem is actually very fast.
> > > > No, I haven't tested this outside of ADL.
> > > > Turning stronglyBound to false value makes it fast again. Is
> > > there anything
> > > > I can do to optimize that? How about a feature request for AIR 2/3?
> > > > Seriously... if I need to generate my own CRC checksum or
> > > whatever the
> > > > heck, I'll do it. Or heck, make the function asynchronous and
> > > give me an
> > > > event when done, that's cool too.
> Don't use strongly bound, worked for me since I have a large AIR file too.
> On Thu, Jul 30, 2009 at 4:12 PM, Evan <evancoon...@gmail.com> wrote:
> > It seems like AIR is generating some kind of checksum of the entire
> > app regardless of whether or not I'm using the strongly bound feature.
> > When a user starts my app, the first thing I do is read some data from
> > EncryptedLocalStore - and it hangs for 20-30 seconds. My app is 200
> > megs in size (several videos), if I build a version without the videos
> > the delay is much slower.
> > It's definitely EncryptedLocalStore, if I disable the ELS.getItem()
> > call at startup there is no delay at first, but the delay happens as
> > soon as I call EncryptedLocalStore.getItem().
> > Please tell me there's a workaround!
> > On Jul 10, 2:02 pm, Oliver Goldman <ogold...@adobe.com> wrote:
> > > The EncryptedLocalStore API operates synchronously; there is no need
> > > to worry about race conditions.
> > > The "strongly bound" feature does indeed checksum the entire
> > > application, which is why it's slow. Frankly, I don't recommend ever
> > > setting this option to true. For storing things like a username/
> > > password pair, you're not getting any real security benefit. And your
> > > cached passwords will be inaccessible after an application update,
> > > which is probably not what you want.
> > > Hope this helps,
> > > Oliver Goldman
> > > Adobe AIR Engineering
> > > On Jul 10, 2009, at 10:27 AM, Jesse Warden wrote:
> > > > I do not have race conditions, she works every time. It's just the
> > > > "working part" is slow.
> > > > The data I'm storing is like less than a couple k; a username and
> > > > password, each about 10 characters long. However, my AIR file is
> > > > 6.4 megs, so I'm assuming it first has to generate a crc checksum of
> > > > my AIR file, and then use that in the comparison via Keychain.
> > > > On Fri, Jul 10, 2009 at 1:23 PM, Damon Edwards <dzedw...@gmail.com>
> > > > wrote:
> > > > What's the rough size of data you're setting?
> > > > On Fri, Jul 10, 2009 at 10:15 AM, Mister <michael.ritc...@gmail.com>
> > > > wrote:
> > > > I have also been curious about possible race conditions when using
> > > > EncryptedLocalStore since it has no event fired when complete. I
> > > > guess you can assume that when reading/writing to ELS that the
> > > > function following the action does not fire until the read/write is
> > > > complete. Going under that big ol assumption, you can fire your own
> > > > complete event after the read/write calls. I remain skeptical
> > > > though...
> > > > On Jul 9, 5:57 pm, Jesse Warden <jesse.war...@gmail.com> wrote:
> > > > > Dude, Mac + ADL + EncryptedLocalStore + stronglyBound is a REALLY
> > > > slow
> > > > > combination. Locks up the app for at least 10 seconds. This is
> > > > regarding
> > > > > both setItem and getItem. The removeItem is actually very fast.
> > > > > No, I haven't tested this outside of ADL.
> > > > > Turning stronglyBound to false value makes it fast again. Is
> > > > there anything
> > > > > I can do to optimize that? How about a feature request for AIR 2/3?
> > > > > Seriously... if I need to generate my own CRC checksum or
> > > > whatever the
> > > > > heck, I'll do it. Or heck, make the function asynchronous and
> > > > give me an
> > > > > event when done, that's cool too.
I would guess that the "bound or not" setting might be disregarded after the store is first created, since the app would need to be able to open it up and use the same method to decrypt as was used to crypt it. You might try deleting the crypted datastore file and recreating it again with stronglyBound=false.
-Cameron
On Thu, Jul 30, 2009 at 5:35 PM, Evan<evancoon...@gmail.com> wrote:
> See, that's the thing- I'm NOT using strongly bound, and it's taking > forever anyway.
Good thinking, but this is happening on a fresh install.
I'll just have to store the user's serial number in a plaintext file,
that's all I'm using ELS for. Easy workaround, I'm just happy to have
figured out what was causing the slowdown.
On Jul 30, 2:42 pm, Cameron Childress <camer...@gmail.com> wrote:
> I would guess that the "bound or not" setting might be disregarded
> after the store is first created, since the app would need to be able
> to open it up and use the same method to decrypt as was used to crypt
> it. You might try deleting the crypted datastore file and recreating
> it again with stronglyBound=false.
> -Cameron
> On Thu, Jul 30, 2009 at 5:35 PM, Evan<evancoon...@gmail.com> wrote:
> > See, that's the thing- I'm NOT using strongly bound, and it's taking
> > forever anyway.
The first time ELS is accessed the application's signature needs to be
verified, regardless of whether or not stronglyBound is set. If
stronglyBound is set, then the signature is re-verified as the
application is running. Either way, it's expensive if you have a big
application.
> Good thinking, but this is happening on a fresh install.
> I'll just have to store the user's serial number in a plaintext file,
> that's all I'm using ELS for. Easy workaround, I'm just happy to have
> figured out what was causing the slowdown.
> On Jul 30, 2:42 pm, Cameron Childress <camer...@gmail.com> wrote:
>> I would guess that the "bound or not" setting might be disregarded
>> after the store is first created, since the app would need to be able
>> to open it up and use the same method to decrypt as was used to crypt
>> it. You might try deleting the crypted datastore file and recreating
>> it again with stronglyBound=false.
>> -Cameron
>> On Thu, Jul 30, 2009 at 5:35 PM, Evan<evancoon...@gmail.com> wrote:
>>> See, that's the thing- I'm NOT using strongly bound, and it's taking
>>> forever anyway.
