Difference between revisions of "Main Page"

Revision as of 13:34, 5 October 2014

Today the spontaneity of planning, which makes it possible to search for a place to eat while already out the door, forms habits making the avoidance of planning for death even easier. The compartmentalization of online selves makes discrete and care-full notifications difficult, and sadly the current viable option is mass broadcast. Direct and peripheral experience of the fallout of death in this new environment inspired the creation of this shared place for methods of using networks to exhibit care rather than exacerbate confusion. The wiki contains things like wills (what to do with corpus, corpse, etc), notifications for far-flung communities, dealing with passwords, and donating one’s body to science in ways that support open research. All things here assume a commitment to open access, creative commons, and inclusion. Just as the internet is about creating, storing, and transmitting knowledge, this guide is about contributing to something larger than the individual. It’s about continuing to build the commons, establishing protocols for death in the digital. You are encouraged to edit, contribute, and refine this living document. Remnant questions are kept here until more eloquently embedded elsewhere.

Components are divided up into documents, accounts, notifications, and people. Documents are centralized with accounts, which are propagated via notifications to people, as triggered by a notification from a person. This means only having to worry about keeping something up to date in one place -- a change to a will or to a website password simply happens in the place of storage, without needing to notify everyone involved. As people enter or leave the circle of trust, they can be added or removed from the notification pool. The notification mechanism is the one thing that has to remain consistent in this set up.

It should be possible to speak about death without fear. If you are in danger of harming yourself, please say as such directly, and get help.

Digital artifacts

Executing wills can be a complicated thing, and there are additional snafus and hoops to jump through in granting digital rights postmortem, especially as most courts lack basic understanding of our home The Internet. These structures set up both mechanisms to get access to passwords outside a court of law, as well as making that access legitimate through bequeathing to individuals in via will. For example:

I devise, bequeath, and give my technology to my relationship, name. If name is unable or unwilling to accept, I bequeath the technology to my relationship, second name.

I devise, bequeath, and give my online profiles and digital assets, as primarily found in my password vault, to my relationship, name. If name is unable or unwilling to accept, I bequeath my online profiles and digital assets, as found in my password vault to my relationship, second name.

Passwords and online accounts

Security tends to prevent others from accessing accounts without your presence. In death, that absence is guaranteed. Thus, a quandary well covered in secret sharing and this writeup from Cory Doctrow. Split the password for decrypting a password vault in two, and give each half to two people. These four folk don't know who the others are, and should have no reason to talk to each other, except in case of death.

The encrypted aggregated passwords file is stored in a place accessible remotely. It should auto-update with changes, rather than requiring upkeep. 1Password can also store encrypted notes, in which should be included instructions (also found in templates) and reminders of each of the tasks requested of people.

But how will people know the time to act in that capacity has come, and how will they find each other? A mailing list, of course!

A mailing list

The mailing list might include both people who simply need to know as well as those who have agreed to take on certain responsibilities at the time of death or incapacitation. These responsibilities include things like letting social or work contacts know, or getting into stuff and taking care of sensitive material before deploying open access mode. There's a set of people tasked with tending to the online accounts. The ideal is a closed notice of death to people, before it hits the rest of the internet. This eases the burden on any one person, while also providing a support network.

Send each of these people a request for involvement, and then (if they agree to be on the list) instructions on how to use mailing lists in general and this one specifically. Then set up an auto-responder to a mail posted to the list with instructions on what first steps are, and reminders of how to access information. In a continuing trend, templates for each of these things can be found in the template section of the wiki.

Failure Modes

Control Systems are Delicate

This is essentially setting up a control system for information dispensation and action upon demise. Control systems are delicate - single points of failure (like the mailing list not working) or weakest links (unclear directions for action) have to be considered and accounted for. As the point of this exercise is to 1) ease burdens on loved ones and 2) ensure open access intentions carry through past death, an example issue to consider in this set up is people getting falsely spooked and subsequently either a) leaking passwords / freaking out the internet or b) becoming jaded and inactive. One version of this might be a family member who had not been fully informed as to how the system set-up works posting to the list with a "hey how does this work?", triggering the auto-responder, causing some tasks to be executed. The cost of this would be the cognitive load of damage control and head-petting. To mitigate this and things like it, a part of the Mailing List Auto Response template is a "can you trust the message that triggered this?" prompt.

Threat Model

In infosec, considering what could go wrong in life and the structures built to respond to those incidents would be called a "threat model." What are anticipated complications, where do those come from, and what can be done to mitigate? This system is set up thus far as "more Murphy, less Mallory." Meaning it's anticipating death and issues with the deployment (accidental or otherwise) of the postmortem setup as occurring by accident, not malice. IE, not worrying about someone intentionally cracking the password vault (or setting up a spoof one for loading passwords into). Some people do need to worry about these things, and it should be a part of their consideration when setting up a system which takes care of their digital assets postmortem. Please make space on this wiki to document those cases and resulting structures as well.

Using your threat model, compare unintended consequences (mid to low probability false alarm and associated cognitive load in damage control; a vanishingly small likelihood of a scenario in which people loved and trusted are secretly horrible people who seek out the other password holders who 'also' end up being horrible and sneaky, and together they unlock all the passwords, and the falsehoods they post on social media are actually believed by people (thanks, anxiety-brain, for that worst-case-scenario!)) with non-action (the amazing set of people in life have emotional and chaotic things to deal with which could have been avoided; worthwhile but unpolished work is not released into the world for others to make use of) and decide the how to act (or not). Then build in mitigation and fall-backs into the structure of this control system. Here's one example:

Yearly Test

Send a yearly test email to The List once a year. Do all the mechanisms still work? Do people know where to find files, and can they gain access? If the password on the vault has changed, this is a good time to be sure the halves-holders have the newest version. It's also a good time to get assurance that people 'want' to be on the list, and are willing to perform their tasks - do they respond to a yearly message? If not, you might not want to include them on the actuality dire eventually.

A body

Is it possible to donate a cadaver with Open Access stipulations? In this section of the wiki, the logistics, law, and advocacy are explored.

Why is this so important? While any one contributor is unlikely to be a special snowflake for medical research, it's possible that, if enough people sign up for this, someone involved will be a Henrietta Lacks. As it's almost statistically impossible that any single person would be that profitable to an organization, it's likely to be a risk worth taking on the receiving organization's end. But it's a downstream obligation that, especially if it becomes common practice, opens up the benefits of medical research to a much wider part of the population than currently benefits.

This downstream obligation could get tricky because the individual defining it won't have authority to uphold the obligations. They'll be dead. Granting authority in the living will and will via power of attorney is therefore essential. Ideally, the organization receiving the cadaver will voluntarily comply -- especially likely if the org is federally funded, because they'll be under the federal open access mandate. Combining these two things manifests as WILLING a body, as the body becomes an object after death, and attaching obligations accordingly.

Pledge to donate

Be a part of open source cadavers by pledging to donate your body. As the list grows, more attention will be paid to this as a viable model.

Completion

Please remember, dear geeks - understanding the theory of this is NOT the same as ACTUALLY doing it. OSC sets up mechanisms for granting digital rights, for passing on passwords, for slow-release information, and for Open Access to information possible from death. Seeing the importance and care of fulfilling these steps means doing it. Every possible barrier to showing care for loved ones, and commitments to causes even postmortem has been removed. All it takes is a little premortem planning.