ArticlesHere is the main-use case for a morbid new security tool for handling deceased estates, straight from my morning shower of ideas that I will never implement.
Use Case Name
Death of Computer User
Trigger
Computer User dies, presumed Executor reads will.
Basic Flow
- Will states: I would like my Facebook status updated to “has shuffled off this mortal coil.” I would like my web-host to be paid up-front for a period of 5 years to continue hosting my photos. I would like a post announcing my death to be posted to my blog. I would like the executor to appoint someone to monitor the spam for 3 months and then close all comments. In order to achieve this, you will need my passwords. Here are the steps and details you need…”
- Executor visits the first URL provided and downloads an recent backup of the password file (e.g. the output of Password Safe). This file is encrypted with a password, and cannot be read.
- Executor notes the first half of the password, which is written in the will. This is useless by itself.
- Executor visits the second URL provided, which points to the Time-Delay Password Safe (TDPS).
- TDPS prompts for a password.
- Executor types second password.
- TDPS prompts for an email address.
- Executor types their own email address.
- TDPS sends out emails, SMS messages and faxes to a large list of trusted people, including to the (presumed deceased) computer user’s email and mobile phone. The message states: I regret to inform you that [Computer User’s Name] may have died recently. Alternatively, someone has misappropriated his will and is trying to conduct identity theft. Please check with his family and other primary sources on the truth of this claim. Please check with his executor, [Real Executor ‘s Name – pre-entered by Computer User], that they have triggered this message by visiting the Time-Delayed Password Safe. If you know that this person has not died, that the Executor has not triggered this, the probate of the will is in doubt, or that the Executor doesn’t have access to the email address [Presumed Executor’s email], please click on this link and type in this (unique) password. On the other hand, if this is legitimate, sorry for your loss.
- The TDPS waits for a pre-determined period – probably approaching a week, listening for responses.
- If no responses are received, the TDPS sends a message to the Executor with the second half of the encrypted password file’s password.
Alternative Flow
- If someone responds to the broadcast message, the second half of the password is not sent. Instead, it informs the executor (or rather, presumed fake) of the contact details of the person who refuted the claim, so they can discuss the issue and perhaps trigger the TDPS a second time.
- If the Computer User opted for the free version of the service, rather than paying for the Pro subscription, then the broadcast email will include adverts for bereavement counselling services and local florists; there’s no reason not to make a profit from the suffering of others.
So, can anyone see any security holes? Is it a tool that people need?
Comment by configurator on April 19, 2009
You’re insane.
That said, if you put in your will a clause that says gmail should reset your password and send it to the executor after seeing a death certificate, wouldn’t they? Then, the executor would be able to reset passwords by receiving email.
Comment by Julian on April 19, 2009
(Good news! Configurator has a blog now! And more good news! It doesn’t take long to read!)
The first problem is the sheer number of providers – Gmail is just one of them.
The second is the level of bureaucracy required for each provider.
The third problem is the timeliness. Gmail shouldn’t listen to your request as executor until you obtain probate of the will, which takes months (at least in Australia). By then, the spammers will have already won.
The fourth problem is where the deceased person is the administrator (e.g. home computers) and there is no-one else who can reset the password.
Comment by Andrew on April 26, 2009
So the entire point of this is to be able to do it quickly? Because we already have frameworks for figuring out whether people are dead or not, and when their assets can be redistributed.
If I’m dead, I don’t really care if my blog gets over-run with spam for a couple of months while the will gets sorted out. If I’m the only author, people are going to stop reading it anyway. If I’m not the only author, the others will sort it out. If it’s a big important blog, I’ll be able to employ staff to do that.
Actually, a far more useful idea is to give someone you trust (and who reads your blog) password access, and tell them to clean up the spam if you appear to have vanished. This covers a great many more contingencies than death, including coma, holiday, kidnapping, sudden business trip, alien abduction etc.
Blog hosting that includes spam killing would be a good alternative as well, and has the added advantage of being worthwhile even if I’m not dead.
Oh, and security holes: monitor email traffic from TDPS. Email is not very secure, and a death will trigger a lot of it, making it likely you’ll catch one. If you see it, you immediately have:
– the name of a blog to victimize
– an email address to reply from with a fake objection.
– and you can sell the blog name to other spammers to pay for your efforts in monitoring email.
You just need to bribe a few ISP staff, and there’s no need for complete coverage, or even especially timely coverage – you’ve got a week.
Comment by Julian on April 27, 2009
Andrew,
We can dismiss any discussion of blog continuity after the death of the author in general by saying “I’ll be dead, and I won’t care.’
However, I think the changes in the ways modern communities form and communicate mean that information about the death (or alien abduction) does not (and even cannot) be passed around in a reliable way.
If we accept that the community wants to know this information promptly, and that we want to support that desire, we get a quandary that I am trying to address.
Having readers leave because of spam attacks, rather than coming together to support each other during such periods, seems a terrible shame.
While I acknowledge your concern about email security, and will ponder that some more (there may be an OpenId-based solution, for example), putting your trust in someone with a password, to only use it after your death/disability seems like a much bigger security risk to me.
That said, I have seen at least one blog where an excited young man was talking about his upcoming trip, and the following post was from his brother explaining he died on the trip. Very poignant.
(Oh dear; I am about to go on a routine plane trip. I really don’t want this to be my last message to the world! Just remember what I would have wanted.)
Comment by Andrew on April 28, 2009
I’m not generally dismissing blog continuity with “I’m dead, I don’t care” – just for blogs that are too small to handle it naturally.
The plan of giving someone else permission is not to just give them the root password, but to allow them posting permission (and to kill off spam). Naturally you will have an audit trail so that you can spot misuse if there is any.
Your executor is likely some legal type with no blogging sk1llz; the person you want to post the “Julian has been abducted” post is someone familiar with your blog.
How’s this – a blog-software plugin that allows a particular subset of login/passwords access permission only if none of the other passwords has been successfully used for a week, and can’t delete posts from another subset of people (perhaps anyone who’s commented more than n times before without being nuked as a spammer, or perhaps a select few).
So Benedict Arnold posts that you’ve been abducted by aliens, and Richard corrects this to say you’re helping him set up a Linux system, and Alastair asks how we can tell the difference, and everyone can see what’s going on.
Yes… your blog *is* your TDPS. Multiple blogs? Independent TDPS systems, that can be compared by the knowledgeable in case of suspicion.
It’s where you’re going, not how you’re getting there.