Our first stretch goal has been met! Command line tools and “pass” password database integration will be available when the devices ship. To enable command line tools to interact with the device, I will separate the parts of the current application that communicate with the device into a daemon that will listen for requests from both the GUI and the command line tools. Once the command line work is completed it will be possible to perform all tasks that can currently be performed from the GUI on the command line. It will still be possible to deploy the application as a single self-contained binary by making the application take on different roles depending on the command line arguments passed, starting an instance of itself in daemon mode if neccesary.
The next stretch goal is for browser plugins, which will be unlocked at $10,000 USD. Upon meeting this goal, the Firefox plugin will be made available within three weeks of the shipment date, followed by a Chrome plugin within six weeks of shipment. I will develop the plugins even if we miss this goal, but I wont be able to take additional time off my day job to meet this tighter schedule.
The browser plugins will take advantage of the same client/server architecture that will be developed to support the command line tools. Instead of needing to directly access the hardware, the plugins will send commands to the daemon to figure out which field is needed and request its value.
Just as with the GUI, a button press will be required to fetch the data. This should be somewhat more convienent than using the GUI, but slower than autofilling browser plugins. You should still feel much more confident about the security of your data: there have been cases where autofilling browser plugins have leaked information to attackers. While this cannot be ruled out with the Signet plugins, the scope of the data that might be lost is conserably less because the plugin never receives a snapshot of the database, encrypted or unencrypted: only the specific data needed to fill the selected form field.
A small change has been made to the production PCB design that should interest anyone who would like to experiment with other hardware applications: I am adding a boot mode selection DIP switch to the back of the board, which will allow users to swtich between the application and the factory bootloader without having to do any temporary soldering. You do not need to use this to upgrade the Signet firmware, since a pure software method for that is available within the Signet firmware. However this feature makes it much easier to develop completely new firmware for the hardware, as some users have expressed interest in. The switch could be used if a firmware update went wrong, which would prevent the standard update method from being used to recover the device.
Many thanks to everyone for their support, great questions, and feedback.