hello hadders,
Glad to hear you’ve enjoyed your Shake and the various applications we’ve created to make the data both useful and interesting, it never gets old for the team to read this type of feedback. And thanks for you post, this will allow me to respond here directly to clarify a few design and security points for your benefit as well as that of any other readers coming across this thread.
You’ve touched on several issues in your post that I will endeavor to address here, each in turn.
As you note, the security related to all types of devices is ever-present and an increasing concern over all time. Indeed, notepad++ was very recently hacked; Microsoft allowed a 3rd party security firm to release an update that resulted in disruption of air travel all over the world last year; openAI was recently hacked; and the list goes on. I do not list these examples to suggest exceptional risk everywhere, but to illustrate that updates and services provided on-line each require the end-user to both trust and hand responsibility of security over to the provider. This aspect of vendor / end-user relationship is a universal feature of modern software systems, and not a Shake-specific design choice. Thus, like any internet-connected device, the Shake must be configured by both us and the end-user such that the ability of a malicious actor to compromise it is mitigated to the greatest extent possible.
I will repeat here the security measures that are baked-in, which can also be found in the on-line documentation:
- No Shake servers “reach in” to the Shake to do any work, ever. There is no requirement to “punch holes” through the firewall to make access possible in this manner
- Shake documentation strongly advises to place the Shake behind a router / firewall, in order to take advantage of all the protections this provides.
- In fact, when the assigned IP address is recognized to be public, at boot-up, a warning message is printed to the
postboot.logfile, strongly suggesting this is a bad idea
- In fact, when the assigned IP address is recognized to be public, at boot-up, a warning message is printed to the
rootlogin access from outside the Pi is not possible, access to root functionality can only occur once logged in to the Pi using themyshakeuser- Changing the
myshakepassword is also strongly encouraged during the initial configuration phase - Thus, when all the suggestions are followed, we believe the Shake is more secure than most other devices connected to the internet from inside a router-protected LAN. This is especially true since the Shake is not a type of device that downloads both apps and data from unknown and untrusted sources, (unlike a phone / tablet / computer / etc., for example).
- Of note: in the eight+ years the Shakes have been on-line, we are unaware of a single instance in which a unit has been compromised in the field, in any way
Regarding the automatic updates: First, the Shake is designed and supported as an appliance, not a general-purpose computer. Second, the updates are documented in a few places in the online manual, most obviously as part of the Quick-Start Guide. A change log is available for each release, making all modifications as transparent as possible. Unattended updates are the standard operating model for appliance and IoT types of devices, precisely because user interaction with the underlying OS is neither expected nor reliable. These updates allow us to enhance the system to provide richer functionality over the life-time of the instrument. Not to mention, updating all instruments equally keeps the fleet of Shakes distributed throughout the world all running the same version. Given that we are the party responsible for keeping the Shake up-and-running, applying updates automatically is crucial to the overall health of the global network.
The “what if?” question you pose is tempting to consider, and I can do nothing more than reassure you that our servers are secure. But again, this risk is in now way specific to Shake instruments: all devices which download updates are vulnerable in this manner. It is unclear why this risk would be considered higher for Shake instruments than for any other device that receives software updates, it is not.
As for OS updates, since the Pi is not locked down in any way, you are free to try to update the OS as you please. But, as stated in the manual, we provide no guarantee that it will continue to work as expected / required. This is because the Shake-OS contains a few minor tweaks to the underlying OS which are necessary for the Shake use-case scenario. And while the underlying version of the Pi-OS may be beyond its LTS date, when the above-listed security measures are implemented, there is no increase in security risk resulting from the OS being post-LTS.
And lastly, the docker containers are nothing more than the programs running the overall Shake system. That they are docker containers is 100% irrelevant to any issue of security risk. They should be seen and understood no differently than when the containerized programs were running directly on the host-side Pi itself.
I hope this clarifies the design intent and security guidelines and principles of the Shake platform.
Richard
Raspberry Shake