The big problem is that the database uses a shared hosting plan and a shared database server run by my ISP. I have no control over whether the database is encrypted on disk or in transit between the shared hosting server and the database server.
You're freaking out over nothing. Hosting providers are not going to leave people high and dry. Actually, it would be nice if they started encrypting their databases. Shared hosting will live on and solutions will be generated.
In order to add that protection, I would have to crank my hosting plan up to a dedicated server at a monthly cost that is equivalent to several years on my current hosting plan and buy a multi-subdomain SSL cert that also costs (annually) as much as several years worth of service.
You're being extremely, extremely silly. SSL certs can be had for next to nothing. Do they provide as much assurance as better certs? No, but they encrypt the traffic and the root cert is trusted by common platforms. Depending on the law you could use self signed certs as well.
Everything you're saying here is hyperbole.
And then, because I cannot possibly dedicate the time to manage my own server on an ongoing basis (hence the shared hosting plan as opposed to a VPS for the web server side), I would have to hire someone to manage that on an ongoing basis.
So if this law is not very narrowly tailored to sites that contain SSNs, financial information, and medical information, I'll have no choice but to shut my site down. I can't afford to personally spend potentially many thousands of dollars each year to run a website out of the goodness of my heart.
Even if everything you're saying here about the requirements of certs and VPSes is true (which its not), you're still wildly inflating the costs. I run a site with a cert and a fully managed VPS that I can take as much interest in or leave up to support as I want. The cost is under $400/year for the hosting and like...I think like 6 bucks a year for the cert? That's super high, because I am a bit picky and because I run a site that needs a bit of performance overhead, but the service is actually amazing.
In my experience, any security practice that is not onerous also has little effect on security.
Then your experience is extremely limited.
Physical theft of spinning storage is an exceptionally rare cause of data breaches.
Which is why I didn't cite that among my reasons for supporting this.
However, data theft caused by attackers remotely cracking into servers overshadows both of those loss mechanisms by orders of magnitude.
Right, and to restate, depending on how the encryption is implemented (database/table/row level) this may help with that...especially with breaches resulting from the installation of malware.
Because remote data compromises are completely unaffected by encrypting the database on disk,
You're looking at one particular type of very common breach. There are others.
There are already laws that require encryption for anything that could be considered high-risk. HIPAA has strict requirements for how health-related data can be stored.
Actually, no it doesn't. There is no requirement to encrypt data at rest within HIPAA. Have you even read the reg, or are you just making assumptions based on what seems like it must be true? (Hint: you're making the assumptions)
PCI DSS compliance requires encryption of credit card data.
Sigh. I feel like I'm writing an email at my job.
PCI is an industry regulation, not a government one. Compliance with it can be very subjective, and auditing of compliance can also be very subjective. Actually, no external audit is even required if you're under a certain number of transactions per year, and auditors vary greatly in quality. There can be some overlap with local regs, which is absolutely a good thing...so lets have more local regs. The fear of legal consequences is usually more motivating than the fear of failing an audit conducted internally.
And so on. Any company that sanely should be required to use database encryption is already compelled by law to do these things.
You're just not correct at all, sorry.