Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Yikes, given the sorts of uses this would be put to, it seems like the definition of a "high-value target".

I would be terrified of running a site like this unless I had a lot of experience with resisting DoS and state-sponsored attackers.



Yes, this seems like the definition of a service you don't want centralized. Each of us should just find someone (or a few people) we trust, and each do it our own way. Much safer and more robust.


The good news is that it's trivial to implement a dead man's switch on Ethereum, or even Bitcoin. Unfortunately smart contracts can't keep secrets, so you'll still need to trust a third party with a private key if you want to reveal a secret in the event of your disappearance.


It's been okay so far, but yes, I definitely urge everyone to PGP-encrypt their messages before adding them to the service. No matter how much encryption you put in the model layer, the service still needs to be able to read the plaintext to send it at some point...


So, how do you suggest encrypting the data to be sent, while still allowing for the purpose of the service, which is to distribute the data to people later on? The best I can think of off the top of my head is a dedicated PGP key, and two DMS services, one with the data, one with the key. Otherwise you're always at least exposing the data to the DMS service.


I was actually thinking more the standard model, where you encrypt the email to a person's PGP key. This only works if the other person has a PGP key, though. It's the usual security <-> convenience tradeoff, unfortunately.


The issue is that if the service gets hacked, even sending the encrypted emails to their original targets could do lots of damage to someone...


Considering the rate people are losing their private PGP keys, I wouldn't trust a message that was encrypted today to be decryptable a year from now.

Everyone I know that uses PGP has lost their key at least once (including myself - I forgot to write down the passphrase for a key once it expired and I no longer used it daily to refresh my memory).


The failure mode is not DoS, it's accurately determining "death". Certain users will always respond to their emails, and the site operator will never realize they've been compromised.


DoS is still a failure mode. If the site is down and the user can't click the link to confirm their 'liveness', then the deadman switch will be triggered.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: