and the reason i ask is that some of the findings, i have seen, would apply to google.com, yet no one would consider them "high risk", so why do this to other services?

this effort would be better served by raising attention to truly important issues, or defects, than to try to identify as many problems as possible, and for lack of a better word, presenting the results in a away that's unnecessarily dramatic

there are quite a few like this, that on close inspection, are just fine

a loved one, gun to the head: "please pay the ransom, i don't want to die!"

what's your play now? save loved one, and go to prison? or worse, bank blocks transfer, and they die?

go ahead and tax ransom payments (0 tax if human life at risk, 10x otherwise) if you have to, but making it illegal feels disconnected from the messiness of the real world. then, go after the attackers.

ex: main.db + fts.db. reading and writing to main.db is always available; updating the fts index can be done without blocking the main database — it only needs to read, the reads can be chunked, and delayed. fts.db keeps the index + a cursor table — an id or last change ts

could also use a shard to handle tables for metrics, or simply move old data out of main.db

* some examples:

  conn = sqlite3.connect("data.db")
  conn.execute("PRAGMA journal_mode=WAL")        # concurrent reads (see above)
  conn.execute("PRAGMA synchronous=NORMAL")      # fsync at checkpoint, not every commit
  conn.execute("PRAGMA cache_size=-62500")       # ~61 MB page cache (negative = KB)
  conn.execute("PRAGMA temp_store=MEMORY")       # temp tables and indexes in RAM
  conn.execute("PRAGMA busy_timeout=5000")       # wait 5s on lock instead of failing

my replies are being ratelimited, so let me add this

the heavy duty server other databases have is doing that load bearing work that folks tend to complain about sqlite can't do

the real dmbs's are doing mostly the same work that sqlite does, you just don't have to think about it once they're set up. behind that chunky server process the database is still dealing with writing your data to a filesystem, handling transaction locks, etc.

by default sqlite gives you a stable database file, that when you see the transaction complete, it means the changes have been committed to storage, and cannot be lost if the machine were to crash exactly after that.

you can decide to wave some, or all of those guaranties in exchange for performance, and this doesn't even have to be an all or nothing situation.

your password (plain text) is secret because only you are supposed to a have it. in the digital realm, sharing the contents of the password (plain-text) is be akin to making a copy of it — undesirable

now, the algorithm that hashes the plain-text for comparison with the stored hash, that can be know by anyone, and typically is

so password ≠ hashing algorithm

distributed teams do well when proposals, decision, etc, are written down, and can be easily found and referenced

it doesn't mean docs are frozen in time and can't be patched like code