We had two female black cats named Midnight and Luna,
When guests would come over ask about our young children about the cats, a child would explain to the adult guests that Midnight and Luna were our ladies of the night, explaining that Luna means moon.
I use QGIS, which needs to stay in sync with a number of Python packages and plugins. I have thought of using Nix for that, but am not sure if everything I need is packaged for Nix.
I’m using Conda now, a Python package member which seems more popular for this niche need.
I agree. Flatpak could be used to further lockdown what Firefox can do, but it has so much features and complexity that I also expect it to be difficult to successfully lockdown.
I would either start with a product that explicitly has just the features a web-kiosk needs or use something based on ChromeOS, which explicitly has a set of enterprise policies that are there to allow admins to lock down a fleet of Chromebooks as they need.
This is based on the security principle that a system is far more secure if you explicitly allow what you need vs trying to explicitly block or disable all the things you don’t want.
Over time, the features you need to allow your web kiosk needs maybe somewhat static and in your control, while all the features you need to disable in Firefox could be constantly evolving and put of your control if you are keeping Firefox up to date.
I had a friend who liked to sulk around in a trench coat. He bought a grocery store donut and promptly tossed the receipt.
He was soon stopped by grocery security for theft. After some hassle they tracked down his receipt and let him go, but yeah that’s what donut receipts are for.
Good example. It’s true that an even a GET request not designed to mutate data might still fail to validate input, allowing a SQL injection attack or other attack that escalates to the privileges that the running app has.
As a popular open source project, that would be e glaring security hole.
Using this proxy puts the trust in a far less popular project with fewer eyeballs on it, and introduces new risks that the author's Github account is hacked or there's vulnerability in he supply chain of this docker container.
It's also not true that you "never need to touch it again" . It's based on Node whose security update expire every two years. New image should be built at least every two years to keep to update with the latest Node security updates, which have often been in their HTTP/HTTPS protocol implementations, so they affect a range of Node apps directly exposed to the internet.
What do you check two hours later?