development process

As with most technical problems, solutions exist -- usually within the existing frameworks.

In my case, I built a compressed image of the "system disk" and installed it on a portion of the disk that wasn't accessible to the OS (nowadays, disks support such things via HPA and DSO).

Then, configured the machine to reboot on logout and a "loader" that would drag the compressed image back in and decompress it onto the "real" portion of the disk.

This is similar to how "recovery" partitions now work. It's costly to do on each boot. But, if you limit the amount of "stuff" on the disk, it doesn't take long to perform these steps.

Nowadays, you can deploy a sandbox and let the user work entirely in the sandbox, then delete and recreate it on reboot. This protects the current machine from PERSISTENT alterations (but doesn't protect data from being siphoned off the machine as the sandbox only works one way -- blocking writes)

E.g., I designed an electronic kilowatt-hour meter in the 80's. Relatively easy to solve in terms of electronics, software, etc.

But, there were no tariffs in place (e.g., telco) to facilitate remote collection of the data. So, it cut down on SOME of the cost of reading a meter -- and improved accuracy, timestamps, etc. -- but the meter-reader still had to visit the premises.

A 50c meter read may have become a 47c read but not enough to justify the cost of replacing meters, wholesale (and, replacing them piecemeal saves almost nothing!)

Conside computer laboratory for students. Not exactly public space but almost: anybody could came from outside and have access to computers (but only valid users had accounts). We had password on BIOS, password on bootloader. BIOS was configured to boot only from hard drive. Some machines were Linux-only, some dual booted to Linux and Windows. In the Windows 98 era Windows partition was rewriten overnight using image stored on the server. Later this process was broken by changes to Windows, but Windows security get a bit better, so we relied just on Windows security.

There was also a machine running DOS program available to general public. This DOS program run inside DOSEMU, machine booted to Linux and automatically logged in DOSEMU user, startup environement for that user started DOSEMU, so for users that looked just as a DOS machine, except for that files were subject to Linux permissions. The actual reason for doing this was that the DOS program accessed data on several CD-s. Linux allowed storing CD-s on HDD, so everything just worked from HDD which was nicer than dealing with CD-s.

Certainly this was breakable. One possible way would be for one student to leave a program displying something like a system login screen trying to get a password from fellow students. Most students learned to use magic key combination to force logout of previous user, so this was not a big problem. Another way would be to exchange keyboard for a modified one which logged keystrokes. Keyboard is somewhat bulky and somebody binging in new keyboard could be noticed, but equvalent effect could be obtainde by adding some tiny extender plug for keyboard.

On the really public machine above user did not need to provide a password and was not expected to enter any passwords, so protecting users was not a problem.

In practice we had no traces of anybody trying to setup a keylogger. OTOH, RAM in one machine got stolen (after that we installed locks on computer cases).

There are no "accounts"; Windows just thinks of you as "User" (and not "Administrator"). No passwords, etc. No antivirus software to require updating. No blocks on sites that you can visit (because all those things require maintenance and someone to perform that on a continuing basis)

I overwrote the image each time the previous user logged out. So, a user just saw THEIR machine as "booting up" (if they happened to come right on the heels of the previous user logging out)

No server to maintain, just a hidden portion of THAT disk drive.

If the shared printer ran out of paper or died, some "staff" person would have to take care of that.

You don't have to install a keylogger or otherwise try to "hack" the next user in order to "compromise the followon user's use of that machine".

You could change settings to create confusion as the user is expecting the machine to behave a particular way (i.e., the way it did YESTERDAY).

You could replace "New Text Document.txt" that the user had left on the desktop with your own "New Text Document.txt" causing the first user to wonder why it is no longer what he expected it to be.

You could change browser defaults (search engines, etc.). Or, alter the system default printer.

All things that don't require any special "privilege" as they are all happening on the *one* "User" account. (creating an account for each possible user on each possible machine would be ridiculous; setting up an authentication server would require maintenance)

Note that none of these are intentionally malicious; you're just leaving things the way YOU like them -- at the expense of the next user's expectations for them to be the way they were previously. There's no one on-hand to assist the users so the machine(s) have to behave in a predictable manner.

Note that these students GOT to the lab on public transportation so don't have much choice as to when they will arrive. And, will depart on the same mechanism -- so have to watch those schedules lest they end up sitting around waiting for another bus, etc. Wasting even a few minutes of their time on something unexpected has more consequences than delaying your DRIVE home.

Life is already hard for them so any inconvenience just makes it harder for them as they *try* to complete their goals.

In college, we weren't as "accommodating" of our fellow students. It was a relatively common practice to crash the server (no individual workstations back then -- PC's didn't exist) just after you finished YOUR homework... to encourage your classmates to do THEIRS before "the last minute" (particularly effective for classes early on Monday morning where there were no staff on hand to reboot the machine).