No reviews yetBe the first to leave a review for Skeleton Key
Great to see something like this, @sarahcassady. A few comments/questions: Having read the article on Michael Hamelin's death (http://b.zmbi.co/1PpS98V), I sought to do something like this. The main issue I have with this type of service is that I'm trusting Skeleton Key to be around in 1, 5, 10, 20, 50 years. I've thought you could offer a service to pre-pay the server usage for that time period, but then I'm just trusting that whoever YOU use for your storage will be around in that same time period. Google, Amazon, etc are more likely than say DigitalOcean or Backblaze to be around, but what happens when, 46-years from now, I die and this service is gone? This is especially poignant given that for this type of service I want to set-it-and-forget-it. I'm not saying your solution isn't THE one, but I'm curious how Skeleton Key tackles the above issues. The ultimate goal being that solution is secure, reliable, and most importantly, self-sustaining. I almost think P2P or the blockchain would make a good candidate, but would love to hear your thoughts.
@jadojodo Great question, and great reference to Michael Hamelin's death. Thank you!
Your suggestion for a prepaid service is definitely one I’ve had on the table from the beginning. But I think I see SK working as a subscription model for a few reasons:
1) Longevity, exactly the concern you suggest. If SK collects recurring revenue, then it is actively maintaining its service level. SK is presently deployed to AWS, which I agree is not going down anytime soon, but I also share your skepticism for third party expectations. With recurring revenues (however small), SK would be able to respond to changes in the hosting environment and should reasonably be able to hop to various providers as needed, without interruption to the service. Don’t get me wrong, SK should and will receive its own share of third party skepticism - one of the major feedback topics I’ll be relying on as SK evolves.
2) Familiarity. I love set-it-and-forget-it as much as the next guy, and this approach is by no means off the table at this point. It does look good on paper and it would probably be way easier to sell! I am cautious about this though, because of all the moving parts that need to coordinate in order for SK to work for a vault owner. Is the vault owner’s information still correct? Do they have unconfirmed key holders and gatekeepers, and are their infos still up to date - are THEY still alive? How often will a vault owner update their secret information? Does a set-it-and-forget-it service still provide full-feature support for those vault owners who are constantly micro-managing their information? I do have initial expectations that users will set-and-forget information in SK more frequently than not, but maybe not on a 20-year scale (this is just my gut feeling). So until I can gather more data on user behaviour and feedback on the topic, I’ve tried to create an experience for each user role that guides them through interacting with SK and refreshing their understanding of how/why it works and their obligations in their specific role every time they log in…. because who should have to remember all that every 20 years? ;)
3) The “whoops we didn’t realize he was dead” factor. Obviously I don’t have a lot of data on this one yet, but the concept is described under the Built-in Subscription Extension feature on the homepage. The idea is that if subscription payment fails, and the user has not / does not purposefully close their SK account, it could very well be a sign that they’ve quietly met their demise. At that point, SK can alert the gatekeepers of the problem and suggest they might want to check on their buddy.
P2P is actually on the SK roadmap to explore. I’ve launched the beta via web app to try the concept out on a broader test pool, but I’m watching for feedback which might support a shift to native personal apps. P2P means never having to trust a third party in the cloud (regardless of legitimate security claims), the ‘service’ lives for as long as its being used, and some fancier ways of enforcing accountability can be played with (ie. encryption key splitting, user authentication methods, reliably destroyable event and messaging history, etc). I’ve toyed with the idea of not storing anything in SK, and instead letting users connect their own cloud storage to keep their SK data in, but that would hot death on the whole third party longevity side of things. You’ve hit on a point that I think may be an important one.
The issue with third party shenanigans still exists with personal device apps though: the app would be a third party product on a third party device. For the ultimate sense of security where information of this secret nature is concerned, it might make more sense to cut to the chase and open-source a solution. This topic alone could attract some delicious debate, and I look forward to it should we get there!
Did I miss anything from your question?
Report
@sarahcassady That is essentially what I wanted to hear. Your thoughts on ongoing subscription make a lot of sense, and also give a sort of heartbeat to the user's... *ahem* heartbeat. The ultimate concern then is that my subscription alone is able to pay for my portion of the service's usage. That is to say, given that I only receive value (well, technically I never do... hehe) when I die, I want to avoid the situation where I've paid into the service for X years and SK goes away and I've received no value (thankfully). I don't know that I'm saying anything in particular here, so I'll instead make a suggestion:
There may be room for this as a benefit paid for by life insurance carriers. This would alleviate any hesitation from user's who may not want to pay a monthly fee for something they never benefit from, directly. :-)
@jadojodo Interesting! Yes I can see the benefit of potentially partnering. But what about people like me who don't buy life insurance? Would you trust life insurance companies with your secret information more than SK? I'm going to keep this churning in the back of my brain. Perhaps there are other types of partners that would lend credibility to the longevity issue. But now I'm really curious. Do you think there are any steps a startup or small business could take which might instil confidence in the company's foreseeable lifespan? Or what if the cost of subscription was so cheap, that you were comfortable simply paying for piece of mind while the service is running normally?
I'll take this opportunity to plant a little seed with respect to the expectation of benefit gained by an SK subscriber. Selling the idea of information disclosure based on a finite event, like death, makes the beta faster to understand and provides a pretty straight forward framework for a new user to test drive the concept in. Death is already an understood boundary, so the new user can instead focus on the application's mechanisms which aren't so familiar yet. But SK isn't actually concerned if a vault owner is dead or alive (sorry vault owners!), only that a key holder and gatekeeper agree on a condition for which the vault owner's information may be disclosed. The condition could be death, or something less sinister altogether: a vault owner stores critical corporate data which should disclosed only if they leave the company, or a vault owner stores household access information before they go travelling abroad in case circumstances keep them away longer than expected but returning is still anticipated. Perhaps SK could evolve a kind of information escrow branch. But even in its current form, I’m not sure that benefit is strictly tied to the user’s demise ;)
Report
@sarahcassady To clarify the life insurance bit, I'm not suggesting the life insurance carrier store the data; I'm saying life insurance carriers could offer to pay for SK as a benefit to their clients. Having worked previously for a start-up that did something similar, I can tell you that end-users love the idea of not paying for something (directly) from which they will still benefit.
As for your second point, I would consider paying for the service. My point is simply that I, as an end-user, wouldn't want to end up in the place where 10, 20, 30 years from now I've paid in $5 x 10 (yearly discount) x 10, 20, 30 ($5k, $10k, $15k) for a service that goes away before I have a chance to use it. Granted, this is the risk of insurance, but it's slightly different given the human mortality rate hovers somewhere around 100% ;-P. Contrarily, (in theory) I could never need to use my auto insurance. That is to say, with auto insurance I'm paying in the hopes that I don't need it. But SK I'm paying because I WILL need it. THAT is the hard sell, in my opinion.
Report
Hunter
I tried the very first version of it and I must say that it's really cleverly executed.
Sarah decided to allow you, fellow hunters, to skip the queue and have access to the private beta right away.
@sarahcassady good job shipping! Can you tell us why you decided to tackle this problem?
@gregoiregilbert Thanks Gregoire! I wanted to solve this problem because I couldn't find a product that would already let me share my important information after I died. It sounds morbid, but nowadays, we sit on a lot of data that only we ever access! I want a colleague to be able to access my git repos and other data accounts I keep in my password manager. I want my sister to be able to disarm my house alarm and rescue my cats. I want my best friend to commandeer my social accounts and shut them down before they become twisted memorial sites. But then there were the problems of making sure I could trust all this secret info in the cloud and having humans verify my demise. I've used some conventions here which I am truly excited to get feedback on.
Report
You are doing great job to make the keys program. I have done the similar job with my keygen wiki blog.
Skeleton Key
Skeleton Key
Skeleton Key