>However, I don't know how this survey was advertised, so the results may just be sampling bias.
I created this survey. I originally posted it to the CL subreddit and the CL IRC channel, so somewhat limited communication channels. Maybe there are other, better places to post it?
There's a list of Common Lisp resources on Xach's blog [1] that includes communities, which remains relevant despite being an old post.
Also, contacting one of the people associated with a blog listed on Planet Lisp [2] would ensure that it appears there and might be seen by a wide yet relevant audience.
That channel however is plagued by spam, robots and trolls, i.e. very low signal/noise ratio. I got the impression that many users/developers stick to mailing lists of the various projects/vendors.
With the decline in Usenet traffic, that's much less of a problem nowadays. I haven't seen any spam in comp.lang.lisp for the last 2 years at least. It's pretty much all signal, and mostly high quality too.
You must have some kind of spam filter. Of the 6 (six!) postings to comp.lang.lisp over the last week, half of them were some political anti-cryptocurrency campaing in Italian. But yes, a few years ago it was much worse.
In the early years of Android Studio, I generally preferred IntelliJ. I have since converted our application and main library (SQLCipher for Android) to use Gradle. I have Instant Run disabled, but otherwise I haven't run into many issues with Android Studio. We still coordinate our library build with a Makefile.
This paper highlights various possible attack vectors. SQLCipher would still be vulnerable to scenarios such as an active attacker on device/machine where the key is resident in RAM. If you are interested in the design features of SQLCipher, I would recommend reading this: https://www.zetetic.net/sqlcipher/design/
To protect against an attacker with physical access to a machine may indeed be futile, but it should be possible to provide some measure of security against a malicious process running on the machine.
Defending sensitive data if the DB process itself is compromised, again, seems pretty difficult. That was the original goal of the academic proposals like CryptDB or Cipherbase - defense even against a fully malicious database server.
>I'd like to see the same speed measurements done for mobile.
While not exactly what you are looking for I can understand the sentiment. SQLCipher provides a project to time the performance of queries when run against standard SQLite vs. SQLCipher on iOS.
We have done some work on a branch in SQLCipher that allows for adaptive key derivation length based on the device it runs on. The iteration length will be computed per device where time is the constraint. We presented our initial findings last year at PasswordsCon 14.
Isn't that the standard? We always time the iterations for a specific time delay on the specific device and use that, and that's what, for example, LastPass (IIRC) does.
That still does nothing for the fact that a GPU will be thousands of times faster than a mobile.
SQLCipher uses PBKDF2 as a standard mechanism to compute a key, however by default it uses a static iteration length, currently 64,000.
The problem is often that the device spread varies greatly and often a given application will target more than one device. You can watch our presentation covering the details here:
