How would you build a dead man’s switch for pass?
I’d like my family to be able to access my store if I disappear, but not before. The obvious problem: to re-encrypt for their keys I’d need my private GPG key running somewhere, which defeats the point. Has anyone solved this cleanly without leaving a hot key around?
The beauty of pass is that there's a distinction between giving access to the encrypted vault vs giving access to decryption, and you can leverage this.
How I've been doing this is that I have 2 (sets of) backup people. The first set has access to the repo, but can't decrypt. The second set can decrypt (i.e. I have their pubkeys imported), but don't have access to the repo. I've chosen the people such that it's unlikely they collude against me, but in case something happens it's likely they'll be able to get in touch with each other.
There's also other possible approaches: e.g. instead of building a dead man's switch based on the encryption, you can build a dead man's switch based on the data. I.e. you'll use their pubkeys for encryption, but the repo itself is behind a dead man's switch.
key sharding with a trusted third party? computer systems can't know of your death, or even true time, so you have to trust something like a company holding the secrets for you, or your lawyer...
Best practice question for syncing pass across devices:
Since exporting and re-importing the private key to a phone seems risky, is the recommended approach to generate a separate GPG key pair on the mobile device and re-encrypt secrets to it?
I have a different pubkey per device. I store all the pubkeys in the pass repo, and have a shell script to re-encrypt everything with those keys. So when I add a new device, I just need to add its pubkey, and then re-encrypt on an existing device.
Hmm, I’ve always seen robots.txt more as a polite request than an actual rule.
Sure, Google has to follow it because they’re a big company and need to respect certain laws or internal policies. But for everyone else, it’s basically just a “please don’t” sign, not a legal requirement or?
Good point. You do need to create an environment where people feel safe to talk about anything, But it shouldn’t just become an endless complaint loop about the company.
I’ve seen this dynamic too: once people start venting, the channel can spiral. I sometimes wonder how to steer that energy into something constructive. Maybe it helps to let people express uncertainty or frustration before decisions are final, and to respond with context before things snowball.
It’s tricky, because most coworkers only overlap on the job itself, they might not share much else in common. so their “bonding” can easily turn into shared complaining.
Curious if anyone has found ways to keep that from going south without shutting people down completely.
We used to have something very similar with our office coffee machine – spontaneous 1‑2 minute chats while grabbing a coffee. Sometimes it was just, “Sorry, can’t talk, swamped right now,” and the other person would rush off – but even that told you something.
These micro‑interactions gave valuable context: which teams were under pressure, where things might be stuck, and sometimes where a quick helping hand was needed.
When we went remote, we tried to recreate this with a single global “coffee chat” channel. It worked for a while, but quickly became noisy.
I really like your idea of having one ramblings channel per person instead. It feels like a cleaner way to keep that background awareness and human connection alive without overwhelming everyone. We’re going to try this next.
Honestly, this isn’t new at all. Most apps are pretty frustrating to use compared to just visiting the website. Even basic stuff like checking train or bus schedules or planning a route on Google Maps. It’s often worse in the app. With a browser, you can just open multiple tabs, switch between them freely, compare things side-by-side. Most apps don’t support this kind of multitasking at all.
What’s even more annoying lately is the whole “scan this QR code” or “click this button to open in-app browser” flow. You try to log in, get sent an email, and when you click the link, the session’s already gone in the in-app browser. It’s a mess.
So yeah… just use the web version. It’s simpler, more flexible, and honestly more reliable in most cases.
