Slashdot Mirror
The Challenge of Web Hosting Once You're Dead
reifman writes: Hosting a website (even WordPress) after your death has a variety of unexpected complexities, from renewing your domain name, to hosting, security, monitoring, troubleshooting and more. It's a gaping hole that we as technologists should start thinking more about — especially because all of us are going to die, some of us unexpectedly sooner than we'd like or planned for. The only real solution I found was to share credentials and designate funds to descendants — you've done this, right?
It used to be you look for dead people to steal identities from by pretending they're still alive.
After the 'dead hosting' problem is taken care of, it will be 'pretend the owner is dead and take control'
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
Easy: a Buffer.com account using a prepaid credit card.
Don't let death stop the conversation! Prepare right now years of meaningless babbling that people will Like, Share and Retweet.
lucm, indeed.
That, and many more problems. A good friend and our main developer committed suicide 5 years ago.
With the ceremony, the emotional shock and many organizational problems, 1 month got by, the bank account got closed, the provider didn't get paid and deleted the whole VM on which our website was running.
During this period, 2 disks died at his place on the Raid 5 NAS backup, and nobody noticed.
When people tell me I'm being overzealous with backups now, I tell them that worst-worst-case scenarios do happen sometimes.
Two types of websites would be good after you die:
The first is obvious-Your website makes a profit, and you want your family members to continue to profit in your absence. This is kinda like how life insurance works.
The second type is for spiritual types like me- I believe in an after life, and I want people to have faith in Jesus. I might not meet you personally in this life, but if I helped your faith, it'd be cool to know you later. I'm not one who gets in arguments about what is the minimum for salvation, or what the minimum you need to do to get to Heaven. But I know it stokes God when we follow him, do good, be loving, and help people in their faith. So helping people to find Jesus even when I'm not around will be beneficial.
In either regard, if it matters to you for your website to be up after you die, you should probably be sharing the credentials with at least one other trustable person now.
God spoke to me
The legal entity side where you the person who paid for the service is now deceased is a small part of the problem. Once the credit card company knows you're dead, so are your cards. Then you need to figure out how to get the service provider to change payment method without them realizing that the person who's name is on the account is deceased. If you care so much about this scenario, your best bet is to form some form of LLC that itself owns the domain, service contracts, etc. Make your executor/spouse/meaningful person a signing officer. This has the added benefit of skipping over probate issues as well.
The bigger issue is the content/tech side. All sites need maintenance. All service providers eventually go out of business or get acquired. Bit rot is a thing. Your best bet for future-proofing is to either publish static HTML, or have a backup that can be published as static html after the fact. Either way, you really need to have a designated geek to help finish your affairs.
And, after all that, you still need to figure out how to pay for the hosting perpetually. Maybe directing an annuity to be established is the right thing? No idea.
With all that said, sometimes its nice to leave a legacy. E.g. http://www.penmachine.com/
The first thing to consider is the web itself is less than 100 years old, and unlikely to still be there in 100 years. If you are willing to postulate the web, there are a number of strategies to be considered, and a good approach would be to use as many of them as possible.
1. Host on a free service, like blogger. You don't have DNS, you are costing them almost nothing, your blog will remain as long as their company/business model survives. Find as many of these services as you can, and replicate content. This is probably the best case scenario.
2. Host a website on Amazon's S3, and prepay. Cost of s3 is very low, one hundred dollars would keep a low traffic site running for a long time. And you should use their default URL. Again, no DNS issues.
3. Write malware that distributes your content to existing websites. You'd need some automated method of acquiring exploits though. That would be difficult.
4. Make sure you have a payment system that will keep running. This has been shown to work before: http://www.cnn.com/2014/03/07/us/michigan-mummified-body-found/ Use this as a backup to keep any paid websites, DNS, etc. Still running.
5. Create a trust. Hire a law firm to administer the trust. Put enough money in it, and it can hire people that will keep the site running.
A client of ours had a website that gave comfort and advice to people who were considering suicide, or had lost a loved one to suicide. When he died of old age, his family wanted to ensure his site continued on for a pretedetermined time. They paid us up front for several years of hosting, and since we had a static HTML version of the site, and controlled the server and domain name registration, we were able to honour his legacy and follow their wishes. I have no idea if he helped comfort or save anyone after his death, but I like to think he did.
.... RAID is not a backup.
What a clueless thing to say. His setup was fine. You've misused the meme.
At a minimum, a proper backup strategy provides some level of protection against hardware failure and error propagation. RAID—by itself—provides no protection against error propagation, which is why we all chant that "RAID is not a backup", but it absolutely can be used as a part of a comprehensive backup strategy. Super trivial example: if you're even doing something simple like bringing a copy of the production data home periodically and loading it into a RAID you keep there (i.e. kinda like what it sounds like was going on here), that's sufficient to provide you with a degree of protection from error propagation (albeit, a thin one). A better solution might involve regular (e.g. every hour for the last day, every day for the last week, etc.) backups to an off-site RAID, since it would provide you with better protection against error propagation, as well as all of the protection against typical hardware failure that RAID provides, not to mention protection against at least some forms of disasters.
All of which is to say, "RAID is not a backup" is a shorthand way of telling people to not put their production data in a RAID and assume it's "backed up" when it's not. RAID may not not a backup, but it's an essential part of many organizational backup strategies, and if you're a small company, putting your production data in one place and using RAID for storing a backup at the home of your lead developer is a perfectly valid strategy.
Save Wordpress site as static HTML:
wget -k -K -E -r -l 10 -p -N -F -nH http://www.oldwebsite.tld/
Remove Wordpress site and upload static HTML in its place.