Cool product. Just curious, is there no existing encryption at the DB level? I would expect modern DBs to be able to do that.
Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
31–40 of 80 posts
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#32Have you thought about solving the problem from a different direction? Providing a read-only, sanitized clone of the database that can be accessed outside of the core application code? Seems like that could kill more birds with the same stone?
That's exactly what we're doing at https://www.snaplet.dev , I would love to chat with the founders about offering generated production accurate snapshots for developers to code against for users of their proxy!
[deleted]
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#33Congrats on the launch! Interesting product. How are updates handled, if I’m hosting the container in my cloud? How should I plan for troubleshooting if there are incidents involving JumpWire?
We tag releases for the container which gives you flexibility to manage updates on your deployment schedule. In a production setup, our proxy engine automatically clusters across multiple nodes, so that rolling updates minimize downtime.
Policies are cluster aware, so that individual policies can be pinned to a particular cluster.
For troubleshooting, our engine publishes events that you can ship into your observability or monitoring stack (datadog/statsd, prometheus, cloudwatch) so any degradation can be handled by an IR process. And we support our customers with quick responses on shared slack channels directly with their engineering teams.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#34I've worked with systems like this in the past. It becomes a huge burden eventually when you have teams like marketing, analytics, etc that need access to the raw data and you eventually have to store all this stuff somewhere else unencrypted.
Yeah, the mix of permissions can definitely be a big pain. We're building with that in mind - policy exceptions can be set so that specific groups of applications get the raw data when querying. All of the policies stack too; one common setup is to encrypt by default, then allow some specific tool to get raw data but audit the queries it's doing.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#35How easy is it to rotate encryption keys in the event of a compromise? Eg a key was accidentally included in a log file, so the data encrypted by that key now needs to be re-encrypted with a new key.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#36Earlier quoted context omitted.
That's exactly what we're doing at https://www.snaplet.dev , I would love to chat with the founders about offering generated production accurate snapshots for developers to code against for users of their proxy!
Are you looking for investment? Happy to close the deal, love that idea so much and trust the co-founders redwoodjs ;-)
Unfortunately not anymore, we have a great set of people backing us, but thanks for the vote of confidence.
As an aside: Not exactly sure why the parent is getting down voted.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#37Cool product. Just curious, is there no existing encryption at the DB level? I would expect modern DBs to be able to do that.
Thanks! Some databases have encryption support but it is either coarse (row-level encryption is offered in a few databases for example) or it's a low level construct that becomes really complex to integrate - especially if you want to seamlessly decrypt some data. They're often only available in enterprise versions (MongoDB and MySQL do this).
pgcrypto mentioned below is a good example. It's a great extension that works really well, and if you're only using PostgrSQL you could build a lot of the functionality of JumpWire using it. But it requires a lot of engineering work to fit into your application. Having the basic encryption functions only gets you part of the way to a full solution - the rest is aligning those with high level policies and keeping up to date as data schemas change.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#38This sounds great, but I’d really prefer a fully-hosted solution. Do you offer one?
We can launch the engine into VPC we manage that is co-located in your region/AZ, and peer the networks, instead of offering a traditional multi-tenant hosted solution.
But we try _really_ hard to ensure your data is never exposed to the Internet. And we do everything we can to limit our ability to read your data, either through self-hosting or ensuring you own the keys.
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#39Have you thought about solving the problem from a different direction? Providing a read-only, sanitized clone of the database that can be accessed outside of the core application code? Seems like that could kill more birds with the same stone?
That's exactly what we're doing at https://www.snaplet.dev , I would love to chat with the founders about offering generated production accurate snapshots for developers to code against for users of their proxy!
Happy to chat anytime! You can reach me by email (ryan at [ourdomain]) or book directly on my cal - https://calendly.com/ryan-jump/yc-founder-meeting
We've peeked at Snaplet in the past, and :heart: your design aesthetic
Re: Launch HN: JumpWire (YC W22) – Easily encrypt customer data in your databases
#40How easy is it to rotate encryption keys in the event of a compromise? Eg a key was accidentally included in a log file, so the data encrypted by that key now needs to be re-encrypted with a new key.
A manual rotation is one click on the web page, and we can automatically rotate on a schedule to limit the scope of a compromise if a key gets leaked. Full rekeying is Coming Soon™ - fields encrypted with JumpWire have some metadata about which key is used which makes it easier to find rows that need to be re-encrypted, but the end to end process isn't launched yet.