https://octodon.social/@jalefkowit/111229675854870496

^ temporary-containers owner died: https://github.com/stoically/temporary-containers/issues/618

links to "successor" https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-personal-accounts-repositories

deceased user policy: https://docs.github.com/en/site-policy/other-site-policies/github-deceased-user-policy

https://kevquirk.com/what-happens-when-were-gone/ https://news.ycombinator.com/item?id=33863940 https://jmtd.net/log/blog_after_death/ https://www.deadmansswitch.net/

https://news.ycombinator.com/item?id=16531492

https://joeyh.name/hacker_tombstone/

http://hintjens.com/blog:115 https://news.ycombinator.com/item?id=11547212 mention of paperwork here: http://hintjens.com/blog:123 http://www.metzdowd.com/pipermail/cryptography/2019-February/034924.html https://www.nytimes.com/2019/06/10/opinion/hacking-phone-privacy.html

https://docs.github.com/en/github/site-policy/github-deceased-user-policy https://news.ycombinator.com/item?id=26831932

http://varnish-cache.org/docs/6.6/phk/lucky.html

https://g3rv4.com/2022/04/a-plan-for-my-secrets is basically SSSS but he wrote his own thing.

https://longnow.org/ideas/digital-avatars-and-our-refusal-to-die/

maintainer deaths

https://www.schafe-sind-bessere-rasenmaeher.de/tech/how-i-inherited-an-open-source-project/

alternative to SSSS

The bitcoin people wrote, a while ago, a way to generate a secret key from a mnemonic (or is it the reverse?):

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

This was later deprecated into something that explicitly supports the Shamir scheme in the sense that the secret is distributed:

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

there's a python implementation that generates physical paper cards with the secrets:

https://github.com/pjkundert/python-slip39 https://slip39.com/

that is all very cryptocurrency-wallet-oriented, but maybe there's something good that could come out of it?

also:

https://darkcrystal.pw/use-cases/ https://github.com/LeastAuthority/magic-crystal/blob/main/protocol.md https://darkcrystal.pw/threat-model/

a procedure ...

... from a friend, cf id:87wnl2lv99.fsf@angela.anarc.at, name redacted at their request:

I recently decided to setup a backup situation in case I have significant memory loss. My memory isn't best at times.

The classic use case for Samir Secret Sharing. I'd like to share with you how I implemented it:

Generating the key parts:

I added a key a backup disk, from which one could get the rest.
I split the key into M keys for which N are needed to recreate the key to the backup disk. Using the 'ssss' debian package.
Each key-part was turned into a QR code using qrencode

Instructions

Each instruction per key contains K contact points and methods (email for instance) (where K is smaller than N here K<N )
It will say what to do with the data in what situation

Packaging

Created a single page, one side with gpg signed instructions and the QR-code with the key, other side black.
Placed in an envelope with opening instructions on the outside (incase of death/memory loss/etc)
The envelope is sealed and plastified with some tricks to prevent reconstructing in an un-noticable way.

Distribution

Find M parties that you trust to: (a) keep the document safe (b) tell you if it goes missing or gets damaged (c) stay in touch with (d) have some sense of security
Try to include a few that are technical enough to reconstruct the key.
Not everyone needs to know everyone, but a fully disconnected venn-diagram might not be best either for trust during the operation and communications

Up keep

Check in on the envelope with your friendly parties on a regular basis, but not too much. Like when you're meeting up for a visit or a chat anyway.
Keep their effort low, but keep in touch.

Number examples

N vs M is a bit like raid, don't need to have them too high as it gets costly in effort, but you want some redundancy. Say M=6 and N=4
K 2 or 3 is probably nice, just not one as it could escalate in the key becoming unrecoverable

Additional ideas

If you have no trusted parties with technical knowledge, you can add a contact point with technical knowledge, but who gets no key-part. You'll need some trust in them, but not enough to safe-guard a key-part.

This system has the added benefits that (a) instructions until needed are very minimal, keeping the effort for others low (b) includes instructions for operations and who to trust (c) before needed, nobody knows who else is in the network and if you pick your numbers well, even leaking one or two envelopes will not provide enough information about the trust network.

One project, where I truly hope I'll never need it

goerzen

https://floss.social/@jgoerzen/109344974683720182

Nov 14, 2022, 19:25

So in one of @textfiles@digipres.club 's (also @textfiles@mastodon.archive.org) podcast ("Jason Scott Talks His Way Out of It") episodes, Jason reflected briefly on what it means to have a server he's maintained for years go down.

I have been reflecting on that too. I've been running my own web server for some number of decades. It isn't nearly as well-known as Jason's. I reflect on occasion about what would happen to it should I become incapacitated or die. 1/

@textfiles@digipres.club @textfiles@mastodon.archive.org It is an odd feeling, that this sort of thing which I put so much time into over many years, is unlikely to outlast me by more than a few months max (when the hosting bill would come due). Yes, copies exist at archive.org, but they aren't really discoverable unless a person knows where to look.

Unlike old-fashioned journals and diaries, this thing needs active attention to keep it alive. And active money, and electricity. 2/

@textfiles@digipres.club @textfiles@mastodon.archive.org Every archive, from Internet Archive to Google Groups, does, too. The energy and money are coming from somewhere. As we have seen all too often, with everything from Geocities to Flickr, the moment the money goes out, the archive is gone. 3/

@textfiles@digipres.club @textfiles@mastodon.archive.org On the one hand, backing up to something like Google Photos or even Facebook gives a "this is likely to outlast me" factor, simply because you rely on those corporations to fund it. Facebook even has a culture of "memorial pages" for people that have passed away.

In some ways, it beats the photos my grandma had in a cardboard box, but threw away when she could no longer remember who was in them. Those are forever lost. 4/

@textfiles@digipres.club @textfiles@mastodon.archive.org But it would be foolish to believe that Google Photos or Facebook are "forever". I do back up my photos to USB hard drives, and am hoping to soon use #gitannex to back them up to BD-Rs as well.

For photos, that is fine. But websites are another beast. Although mine is entirely static because I enjoy the #SmallWeb, many are more dynamic. The server-side bits won't last forever.

@textfiles@digipres.club @textfiles@mastodon.archive.org Jason commented coming to the realization that it was fine if his sites were down for a few weeks. They'd be back eventually, and mirrors existed.

Indeed, true. It is a very positive attitude.

And yet, it strikes me, if Jason hadn't been able to help in its resurrection, the world would undeniably feel its loss.

@textfiles@digipres.club @textfiles@mastodon.archive.org Us authors, programmers, artists, tinkerers -- what we create is ephemeral. Either we self-host it and it relies on our continuing money and attention, or a corporation hosts it, and it relies on their continuing money and attention.

Both can be fickle.

But then, how many paper libraries have been destroyed by flood, fire, neglect, or war? Buildings, too, need maintenance. 7/

@textfiles@digipres.club @textfiles@mastodon.archive.org I am reminded of Willa #Cather's observation nearly a century ago: Some cultures value being remembered and leaving their mark, and leave their names on buildings.

Others value leaving no mark, carefully smoothing out even the sand on which their tent was pitched, taking as little as possible from the #earth.

@textfiles@digipres.club @textfiles@mastodon.archive.org The archivist in me tends to the former. I wonder if my descendents will ever want to know about my life a century hence, as I want to know about my ancestors'. Will they know to look up https://www.complete.org/ in the Internet Archive (and will IA even exist)? Who knows.

And yet, my life has been shaped by innumerable people whose names are not on buildings, whose earthly material effects by this date are few to none. 9/

@textfiles@digipres.club @textfiles@mastodon.archive.org My old boss at university was a mentor and a friend. He died suddenly. archive.org knew about some webpages on an abandoned domain. Webpages his family wouldn't have known about had I not happened to receive a contact from them and remembered those old URLs from years ago to share.

But more than webpages, what I treasure the most from Tom is his uproarious laugh - most especially when describing a #DEC TK50 tape drive being smashed to bits on-stage. 10/

@textfiles@digipres.club @textfiles@mastodon.archive.org So ultimately, I believe, the best memory I can have is:

human.

As #RobertJordan writes: "Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again."

/end

my response

In some ways, it beats the photos my grandma had in a cardboard box, but threw away when she could no longer remember who was in them. Those are forever lost. 4/

@jgoerzen this is something i've been thinking about quite a bit. there's an interesting property to that photo shoe box: it exists in the material world. it's not as abstract as an (encrypted!) hard drive in some weird linux server, it's made of paper and ink and acid and you can just look at it.

@jgoerzen typically, when someone dies, their relatives go through the painful but necessary process of going through their stuff and throwing away a large chunks of it, quite deliberately

@jgoerzen the same thing happens in public libraries all over the world. part of a librarian work is not only taking care of books but also destroying some of them to make room for new ones

@jgoerzen we have this obsession with keeping everything, but i think it's at least partly misplaced in some sense, as it dodges the hard work of figuring out what's actually worth keeping

@jgoerzen our seemingly infinite capacity at storage is, in other words, at odds with our capacity at telling what really matters, and what should really be kept around forever

curl plans

https://daniel.haxx.se/blog/2024/02/07/contingency-planning-for-me-and-curl/

archiveteam

a million ways to die on the web https://wiki.archiveteam.org/index.php/A_Million_Ways_to_Die_on_the_Web

vim death

https://groups.google.com/g/vim_dev/c/dq9Wu5jqVTw

https://getyourshittogether.org/

"death book": https://www.bogleheads.org/forum/viewtopic.php?t=119346

"sealed notary": https://news.ycombinator.com/item?id=37076703

https://longnow.org/ideas/digital-avatars-and-our-refusal-to-die/

Comments on this page are closed.

Created 2024-02-13 11:44. Edited 2024-03-26 23:59.