Difference between revisions of "Main Page"

From Networked Mortality
Jump to: navigation, search
 
(seed page)
Line 1: Line 1:
'''MediaWiki has been successfully installed.'''
+
This wiki focuses less on things like wills (what happens to material possessions, who doles it out, and the like) and living wills (if you want to be kept on life support etc) - although versions mindful of the contents of this wiki can be found in the Templates Category - and more on specific aspects for Open Access and encryption enthusiasts. It should be possible to speak about death without fear. If '''you''' ''are'' in danger of harming yourself, please say as such directly, and [http://suicideprevention.wikia.com/wiki/International_Suicide_Prevention_Directory get help], rather than "not waving but drowning" indirectly through things like estate planning.
  
Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.
+
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.
  
== Getting started ==
+
==Digital artifacts==
* [//www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
+
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:
* [//www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
+
: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''.
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
+
: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''.
* [//www.mediawiki.org/wiki/Localisation#Translation_resources Localise MediaWiki for your language]
+
 
 +
===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 [http://www.theguardian.com/technology/2009/jun/30/data-protection-internet this writeup from Cory], and riffed upon here. 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 they honestly 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 [[Tasks to Consider|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 [[Mailing List Invite|request for involvement]], and then (if they agree to be on the list) [[Instructions to People|instructions]] on how to use mailing lists in general and this one specifically. Then set up an [[Mailing List Auto Response|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 [http://opensourcecadavers.com/index.php?title=Category:Templates 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 [https://en.wikipedia.org/wiki/Murphy%27s_law Murphy], less [https://en.wikipedia.org/wiki/Alice_and_Bob#Mallory 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 [[Threat Model Responses|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?
 +
 
 +
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 [https://en.wikipedia.org/wiki/Henrietta_Lacks 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.
 +
 
 +
Using [[Inquiry_to_Programs|this template]] contact places to see how amicable they are to Open Access of medical research, and to edx-style recording of medical practice in regards to the cadaver bequeathed to them. The full list of cadaver-using medical organizations in the US can be found [http://old.med.ufl.edu/anatbd/usprograms.html here], with the overview of willingness to work with the open access obligation [[List_of_Cadaver_Programs|here]]. Please contribute additional country listings. Because it is vital that the accepting organization get the cadaver within a very short timeline, geographic proximity is a priority.
 +
 
 +
==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.
 +
 
 +
===Donate===
 +
Be a part of open source cadavers by [[Pledge_to_donate|pledging to donate your body]].

Revision as of 09:20, 25 September 2014

This wiki focuses less on things like wills (what happens to material possessions, who doles it out, and the like) and living wills (if you want to be kept on life support etc) - although versions mindful of the contents of this wiki can be found in the Templates Category - and more on specific aspects for Open Access and encryption enthusiasts. 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, rather than "not waving but drowning" indirectly through things like estate planning.

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.

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 this writeup from Cory, and riffed upon here. 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 they honestly 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?

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.

Using this template contact places to see how amicable they are to Open Access of medical research, and to edx-style recording of medical practice in regards to the cadaver bequeathed to them. The full list of cadaver-using medical organizations in the US can be found here, with the overview of willingness to work with the open access obligation here. Please contribute additional country listings. Because it is vital that the accepting organization get the cadaver within a very short timeline, geographic proximity is a priority.

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.

Be a part of open source cadavers by pledging to donate your body.