Lately I’ve fielded a couple of different queries about long pauses in applications using the EncryptedLocalStore (ELS) and DRM capabilities in Adobe AIR. Two questions on the same topic in one week is usually a good indication that some additional explanation is required, so here it is.
As you are probably aware, AIR applications are protected during deployment by digital signatures. These signatures are checked at installation time in order to verify that the application has not been tampered with and, when possible, to reliably display the application’s publisher.
The signatures are preserved by the installation process but are not normally checked when an application is running. However, there are two exceptions to this: the signature is validated when the application uses the ELS or DRM APIs. This is done to prevent attacks on the application’s protected data that operate by modifying the application itself–any such modification would invalidate the signature.
When we designed this mechanism, we targeted applications in the 1 MB to 10 MB size range. This is important because checking the signature requires computing hashes over the entire application. For these sizes we determined that we could compute hashes over the entire application without significant delay, and so we went with the straightforward implementation that does just that. Larger applications, however–and I’ve seen examples of applications over 1 GB in size–will suffer painful delays during these signature validation pauses.
Our current recommendation is that you avoid making applications this big. That may sound trite, but every large application I’ve seen so far was that big because it included assets, such as videos, that consumed the majority of the space. Moving these kinds of non-code-containing assets out of the application itself–for example, downloading them separately into the application storage directory–is a straightforward way to reduce the application to a tractable size.
For completeness, I’ll note that it is possible to design a validation mechanism that works incrementally. For example, Mac OS uses a clever scheme that hashes each page of the executable separately; the kernel can then amortize validation cost across each page as it is first referenced. (If the page is never referenced, it doesn’t matter if it has been modified.) At this time, however, we have no plans to adopt such a scheme for AIR.
One final note: This signature validation usually occurs just once, the first time either the ELS or DRM capabilities are used. However, if you set “stronglyBound” to true when using the ELS API, signature validation will occur on every access. I don’t recommend using this stronglyBound feature, for this and other reasons.