Accurate, live in the area and I've noticed he guts any protections & laws as soon as his corporate sponsors say anything. He's a useless wet paper towel trying to impersonate a seatbelt.

Right, "more powerful" or "less powerful" are completely meaningless without context. E.g.: hollow knight has some serious bugs on the controller input (for some popular controllers like 8bit do ones) on the Linux version due to some outdated version of a library they use on some input modes. Silksong doesn't even register the inputs for that same setup. Both work perfectly on proton with the same hardware. Drivers and software play a more important role in playability than raw specs and benchmarks.

Surely you meant someone like John Stuart.

You are more optimistic than the maintainers of those older projects that have started to ban LLM generated bug reports. They tend to be a waste of time for the maintainers (e.g.: cURL project).

Macroslop*

I found a git repo with docker compose and the config files works well enough as long as you are willing to maintain a backup of the volumes and an .env file on KeePass (also backed up) for anything that might not be OK on a repo (even if private) like passwords and keys.

At least they ran trials. I feel the federal gov't would just buy the shit with our taxes.

What's the expected volume of records planned to be stored?

For a small volume on a school assignment (a few thousand records on each query), I would do a processor/filter on my base database access layer and do the encryption and decryption there for any field annotated as @Encrypt at the field level or similar (language dependent, not sure what you are using).

Some libraries use a similar approach during serialization and deserialization steps. I'm guessing you are required to write the whole thing, but reading how those work might give you ideas since they tend to have hooks to wire custom logic during the process.

This would add overhead during read and create, but would be pretty transparent to the rest business logic and as mentioned, as long as the requirements don't say you need to support searching over a few million records in X amount of time, it might be OK.

The hash idea sounds quicker at first (hashing vs on the fly encryption/decryption), but it does not sound like it would scale well either unless the message size is constrained like you mentioned. Another problem us that it could be extremely easy to brute force with a rainbow table which kind of defeats encrypting it to begin with. If pursuing that approach, you'd need to also store a salt with each hash to prevent that attack type.

Custom encryption solutions and security through obscurity tend to be the weakest points in an implementation, which sounds like is part of the assignment to think about.

There's going to be plenty of idiots that will see the never proven mostly unusable robot as a good thing for the company. Another trillion dollar bonus package approved!

That's how you could get to voicemail with no pin. Phone companies had/have the crappiest security.

Or just not use racist coloring with no context.

Biker mice from mars mixed with TMNT vibes!