Make a dead person switch

Feature requests
1

As a user, I can send an automated email or even password access in case of death, so that selected people know what to do next.

As an administrator, I can decide specific actions to undertake if a user is absent for too long, so that master passwords aren’t forgotten or I notice these people aren’t using the service.

Q1. What is the problem that you are trying to solve?
There are a lot of services offering a dead man switch aka dead person switch.
Well, they do nothing else, so these projects die out or bring no real value.

A password manager however is used weekly, if not daily. Within Passbolt as an admin, you can even view when was last time a user used your instance. So if a specific amount of time passed, it would be – I believe – simple for you to automate specific actions.

Q2 - Who is impacted?
All type of users: business, private/family alike ; and instance administrators
Passbolt: make it a stronger competitor

Q3 - Why is it important and/or urgent?

It is important for two reasons:

  • Everybody dies. Anybody can have a serious injury. People change companies. In the digital era, there must be better solutions for dead people switches, but they have to be coupled with excellent open source projects, like a password manager called Passbolt.
  • Passwords are very important for private people and business alike. Some passwords aren’t used often, can be forgotten, but are critical to a business or even a person.

Q4 - What is your proposed solution? (optional)
I see two user cases:

  • For an administrator:
    • Tell a user per email to log in once in a while not to forget the master password
    • Tell the admin per email a user has been not using the service for too long
  • Businesses & family/CE/private users:
    • User can define automated actions if they don’t log in for too long (could be due to death):
      • Send a message to specific email addresses
      • Share passwords with specific user of their Passbolt instance

For payed Passbolt instances, I believe there could be extra features (SMS? Post mails?)

Please note: I am not suggesting that an administrator can decide that unshared passwords will be shared if a user doesn’t log for too long. This is a user decision!

Q5. Community support
Although I believe my idea is good and I have been using passbolt for years, I don’t have the right to post polls because I just created my account.

2

The account recovery feature was released in beta with v3.6 of Passbolt Pro Edition. It allows to recover user accounts when they leave if they have shared their key with the organization recovery key and if you have access to the email address mailbox.

Cheers,

1 Like
3

Remy thanks for your response, but the feature I was suggesting is not an “account recovery feature”. It is a “dead person switch”, meaning that a user (a human) decides what would its account do upon not login for a long time, in particular sending emails (& possibly passwords) to loved ones & colleagues.

The recovery feature you’re mentioning is only a side effect of my suggestion.
I haven’t checked the feature you added, but I wrote in bolt type letters the following:

I am not suggesting that an administrator can decide that unshared passwords will be shared if a user doesn’t log for too long. This is a user decision!

4

Hi @hyamanieu

Granting access to passwords is a super important need for many reasons, and you are really keying in on how a death event causes many families to experience a second round of frustration and loss when handling the affairs of their loved one. I could not agree more that planning ahead makes a huge difference.

I personally have a bit of difficulty agreeing that emailing passwords is the most secure way to handle things after a death… or COVID hospitalization before I recover and return home.

Is your feature idea for those who don’t plan ahead or for those who do? If for those who don’t, then the app is deciding and not a human, but that goes against what you are saying is needed. If for those who do, then a user has to decide a timeframe for after their death that family will have to wait before getting access. This seems problematic in practice. I would think most would prefer to grant access right away and only to the right people.

You should check the new feature. It may not be what you think is best, and maybe it could develop a second flavor or use case for something you are thinking of.

5

I second what @garrett is saying, it’s hard to design a system for a machine to decide when to securely release sensitive information. For example with passbolt that would mean that secrets (or private key) needs to be encrypted for the “dead person” contact and released by the software at that time. It creates several issues, mostly around users that have the ability to temper with the logic of this switch. For example an admin could change the dates on the server / database to release the critical information.

The account recovery as designed in v3.6 is similar to what you are describing with two major variations: the user can’t decide who is the recovery contact, the machine doesn’t trigger the recovery automatically (a human with the account recovery key needs to do that). Not perfect as per your use case, but in most organizations I felt it leeds to equivalent outcome.

Utilmately you’re correct it’s not the same thing though. That’s why we’ll leave this request open, for future discussion and design of a solution that match better the need you describe if needed.

6

Hello Garrett, & Remy,

thanks for your queries to clarify my idea :slight_smile: .

perhaps I should start on why I came up with this idea.
I wanted a way to send an email to loved ones in case I am absent for a long time. I found some dead people switch apps, but I didn’t like the idea to rely on an unknown person for this single feature. I though “where do I login every day because I have to, rather than because I don’t want an event to be triggered?”. I thought about my email box, my bank account, and my password manager :wink: .

What I am suggesting is not focusing on passwords, but focusing on making a dead person switch which executes events depending on what was planned by the user. Primary event being sending an email.

What I mean is that the big advantage of a password manager is that users do have to connect regularly because they need passwords regularly. If you check people or companies who only made a dead person switch, this is the only feature they offer, and they require their customers to log in every X days so that planned events aren’t triggered. And these companies can go bankrupt, or their server dies because it’s unmaintained as it’s an unreliable business. See e.g. https://www.deadmansswitch.net/ (it seems it’s still running)

Such events could be (e.g.):

  • send this email: {message: “Dear son, I have buried my gold coins under the cherry tree. Contact attorney John Snow so that the state doesn’t take it all. Stay safe. I love you, dad.”, address: “son@family.org”}

Here you can see, this is meant for a user who plans, and no password is shared per email. Sharing password is only an additional feature because managing password is what passbolt does. For example:

  • share passwords: {passwords: [taxoffice, fitnessclublogin], withusers: [user1, user2]}

It’s shared with a registered user, not in clear text per email.

As a user, I am more interested in the first case (sending a message) than the second one (when I think about social networks, I know they process data of dead people after receiving official documents from the family). Sharing passwords is optional. Focus is sending emails.

Of course the user who plans would need to set up two time delays. A first delay to remind him or her to login. A second delay where the planned events are executed.
Yes indeed, if something bad happens you want your family to get your text quickly. But you don’t want that to happen just because you stop using the internet for several weeks. I guess it’s up to the user, there is no perfect answer.

I am not saying a machine should decide what to do with passwords, not even an administrator.

1 Like
7

@hyamanieu thanks for clarifying that makes sense.