ESC combo to update?

[oorzkws]

I would appreciate if this was possible, however there are two points that immediately come to mind as possible issues.

1. Adding self-update capability in a robust way isn't a one line change
2. When a version adds new config sections, what is the correct action to take?
   A. Interactive diff/merge?
   B. Append?
   C. What do we do with multiple configs?

Edits below

---

3. What is the preferred behavior for which builds to grab?
   A. Only major versions?
   B. Include minor versions?

[cajhin]

Some thoughts on that...

• as a user, I'm tired of manually updating the dozens of softwares I use. My AHK is still from 2016 I think, because I only update when something's broken.
• updating capsicain is usually just copying the latest .exe from code/x64/release. The .dll never changes.
• "keyboard low-level access" combined with "internet connection" would make me a bit nervous if I didn't know the code
• auto updates as an option would still be a good thing
• ideally you can choose between "all latest releases" and "known stable tested versions only"
• the config won't be updated. I don't think people use my config. The issue is if the config syntax changes, which happens occasionally. I guess I must ensure that it's always backwards compatible (I usually but not always do that).
• Alternative: maintain a config "updater" that, for example, automatically replaces "PAUSE:10" with "SLEEP: 1000" in your config

Would be a good feature.
I'm not gonna code this in C though; I'll wait for the next major rewrite, which should have a C# frontend if all goes well.

[bitoj]

I strongly agree with your third point. But security concerns would be less with a separate updater. Perhaps there are even standard solutions for this rather uncomplicated case.

Only (optionally) notifying a user about a new release, with a link, would already be an improvement.

[oorzkws]

I've been giving the third point some thought, would it be possible to release a pgp archived version? At the very least that establishes a basic chain of trust.

[bitoj]

That certainly wouldn't hurt, but the main issues would remain unresolved. Security is not only a matter of trust between a developer and a user installing software, but also a subject of policy. Additionally, a developer should evaluate the risk of its products being blocked or reported by the unpredictable behavior ("heuristics") of malware detection software on a user computer.

Suppose you work with sensitive data. (See GDPR for backgound information, but personal data is certainly not the only example.)

The information security policy of your organization would describe some things you should and should not do on computers you use to access protected data or the servers on which they are stored. In general, only install and use what is needed for that task, and do other things on other computers. Internet access for Windows Update OK, Spotify not OK. Other applications: it depends.

Software for malware detection or auditing security compliance, that your information security officer of your organization prescribes, will use some combination of static analysis and monitoring activity.

• A digitally signed device driver with EV certificate might be OK, if it only uses API's that are needed for operating that device. So the Interception driver probably conforms, since it doesn't seem to do things with other devices than HID equipment and does not link to networking stuff.
• A regular application that uses only local resources and interacts with the user using normal patterns, like a Windows event loop, might be OK.

Capsicain already is somewhat suspect for that kind of software, because

• it is not digitally signed by a big corporation;
• its installed base is very small;
• it works in the background most of the time, monitoring all keyboard activity on the system;
• it has a built-in capability to communicate with the outside world by starting other processes (used for AHK).

You could limit the suspicion by not using it with AHK in such an environment.

Access to the outside world using network protocols in combination with low level keyboard access would be a major red flag. That is obviously a keylogger that should be quarantined. You would probably be reported and be subject to a review of compliance with corporate security policy.

[oorzkws]

That's an entirely valid point (aside from a note that, in the presence of any doubt, permission is infinitely preferable to asking forgiveness). I agree with an updater being separate for that reason, and also to allow users to limit risk (or take risks) as they see fit.