From their ToS:<p>"You provide User Data and Personal Data to Evervault with the understanding that any security measures we provide may not be appropriate or adequate for your business, and you agree to implement Security Controls (as defined below) and any additional controls that meet your specific requirements. In our sole discretion, we may take any action, including suspension of your Evervault Account, to maintain the integrity and security of the Services or Data, or to prevent harm to you, us, customers, or others. You waive any right to make a claim against us for losses you incur that may result from such actions. You are solely responsible for the security of any Data on your website, your servers, in your possession, or that you are otherwise authorised to access or handle."<p>Yeah, no. You either practice what you preach in your advertising or don't advertise what you won't commit to.
I wonder how large is the submarket of developers aware of the need to encrypt data ... And also OK to bring a third party like evervault into the deal.
> we can't decrypt your data.<p>But I thought the point of the cages, is that _do_ decrypt the data. And any government mandated backdoors would then go into that process. You're not doing any homomorphic encryption here.<p>I guess my issue, is that you see both the keys <i>and</i> data, not just one.
> Encrypting cardholder data with Relay means that your system does not handle cardholder data, making Evervault your Cardholder Data Environment.<p>Does this mean Evervault is a PCI DSS service provider? Do you have an AOC yourselves and are you audited annually by a QSA? I had a quick look but couldn’t find PCI specifics on the site.
I had a bit of struggle to understand precisely how this works. I haven't had a need to use similar technology...But at least one mechanism seems to be:<p>1. Data submitted by end user<p>2. Intercepted by an Evervault Server and encrypted<p>3. Hits my Application where I utilize the encrypted data without being able to see it<p>4. Submit it to some other service (Twilio say)<p>5. Relay intercepts request and decrypts required fields before data is sent on to Twilio.<p>6. Presumably response from Twilio is also encrypted? Or it's optional?<p>I'd be interested to hear from anybody who has implemented these kinds of flows to better understand uses cases and the complications etc...
This looks pretty cool (particularly that it's easy to use). If you're already using AWS you could just use nitro enclaves to do this directly, but this makes it easier to use, and easier to use if you're not using AWS but trust AWS (+ evervault, particularly for availability). It's cool to see this for something other than just payment card info vaulting.<p>Biggest problem I could see with applications is that if you were using this inside a larger application, someone with control of the application could just change the less-secure application to bypass Evervault entirely. Wouldn't compromise historical/data-at-rest data already inside evervault, but would bypass it for new submissions. That doesn't mean this isn't useful, but it would be a concern in some use cases.
Previous discussion on the implementation of their technology: <a href="https://news.ycombinator.com/item?id=28127961" rel="nofollow">https://news.ycombinator.com/item?id=28127961</a>
Jumping in here to plug a company that I co-founded called Redact. We are developing a trustless way to store and process PII - our tech is end-to-end open source (unlike competitors), we don't use any proprietary encryption algorithms or techniques (unlike competitors), and we give users a way to control and monitor access to their own data. We think this is the future of Web3. Check out our website and I'd be more than happy to answer questions or provide some links to our source code if there's any interest.
<a href="https://redact.ws" rel="nofollow">https://redact.ws</a><p>Some more details here:
<a href="https://old.reddit.com/r/rust/comments/q79grm/redact_tool_for_building_decentralized_endtoend/" rel="nofollow">https://old.reddit.com/r/rust/comments/q79grm/redact_tool_fo...</a>
Why does this website feel really familiar to me?
The styling makes me feel like it's a product of a company i've used before with exactly the same website, i thought maybe it was hashicorp but a quick look and thier styling isn't quite the same.<p>It is a common template ? Where else might i have seen it ?
A thought occurs to me: how would you envision this working for healthcare data governed under HIPAA? As you're probably aware, the requirement is to have PHI "encrypted at rest" and that I'm not supposed to share or transmit the data outside of my infrastructure or to that of partner companies who've signed a BAA.<p>My understanding of the regulatory parts of the law here is probably flawed in some way, so I apologize for that in advance, but could you go into a little detail about how that might work from a business-to-business/contracts standpoint? Like, do you guys sign BAAs at all, or are you outright going to be refusing healthcare related business/processing of PHI for some reason?<p>(Either answer is fine, I just want to know if this is a decent fit for HIPAA-governed data, that's all.)
Chiming in real quick to say: NICE! I really like how the home page gets right to the point of what it is and shows you a code sample, not a bunch of loosey-goosey executive-targeted buzzword copy written by an English major without a clue of what they're talking about or some GPT-generated garbage. It's fantastic that you guys get to the point of WHAT THE DAMN THING IS - and that makes me want to use it in the next project where this might be a good fit.<p>Bookmarked in Raindrop for future reference. Next time I need to encrypt data in an app, I'll see if this is a good fit. Thanks for sharing!
This is a really nice implementation! Looks really simple to use. I think a lot of devs these days would <i>love</i> to not have to be responsible for sensitive data these days, especially with GDPR.