Security in this key logger

[TheFern2]

I like this logger, however, it does present a security risk. I know you said it doesn't do it on mac, but that's a big what IF. It would be much better to actually just keep the count in a table instead of a view and not log date and key. In the rare event someone gets a hold of the sqlite file and the sequential keys for a password are stored you're pretty much screwed.

What I would do is run the app, keep a dictionary for all the keys in memory and update the count there. Then every N minutes push to table, that way there's no overhead for writing straight to disk in real time.

[Ga68]

It's a great idea. I'd add it as an optional feature as you do lose the flexibility to do future ad hoc analysis, for example bi and tri grams. Of course that could be accounted for up front the same way you suggested for individual keys, so long as you did it at the time, but you would lose the ability to decide later on to look at something in a unique way you didn't think of up front. Ex. How often do I start sentences (first word after a period) with the word "the".

The security gains are great, and it's just a trade off for flexibility. You are definitely right that if you give away access to that one file you're in some trouble!

[TheFern2]

I agree n-grams are a useful statistic, along with modifier(s) + key although I think these are easier to catch since they are pressed simultaneously. For n-grams you could do the same and keep a count of all bi and tri grams although that list could grow big could maybe reset ngram count every 24hours.