Sony was a major investor in Spotify, reportedly worth $1.5B at IPO[1]. I'm not sure how much stock they've held since then.

[1] https://www.musicbusinessworldwide.com/sonys-stake-in-spotif...

I mostly agree with what you said but

> Power plants are still the leading emitter, full stop.

is not true, at least not regionally. In Massachusetts, for example, power is 20% of emissions while transportation is 37%.

https://www.mass.gov/info-details/massachusetts-clean-energy...

In Canada heating is the leading emitter. And even if power is the leading emitter in the OP's region, power plants are lowering their carbon output far faster than any other source.

I assume you mean the power mix is shifting to solar/wind. Or are coal power plants lowering their carbon emissions somehow?

Coal -> Natural Gas is still the leading source of emissions reduction, but that transition is nearing its completion. The shift to solar/wind is what will continue the transition.

That's a new regulation passed in December that doesn't take effect until April. At the moment, there is no cooling off period.

A cup of cauliflower is about 25 calories. A 2 pound head of cauliflower is 224 calories, only about 10% less than the burger.

We still need to add the format to our docs, but it's essentially:

prefix + base64(len_encode(metadata) + len_encode(key_tag) + aes_encrypt(data))

So definitely possible to decrypt it without JumpWire, if you have the keys. There are some pieces of metadata we add in that we could make optional if you want to reduce the resulting ciphertext size. That metadata adds a few extra bytes, but it doesn't grow with the data size.

Thank you – I would recommend writing up a page with all the details on your docs because that would appease a whole lot of people that would be your target customer (like myself)

Although I might be biased cuz I'm a founder from a tech background so I want those details, but even with those details, I'm one of your target market but my worry with these kinds of products tends to be more about things like:

- am I adding an unreliable piece of infra to my stack? this is going to be a critical gatekeeper, so if this fails, not only is it like my DB being down, as the only method of decrypting my data, does it have the ability to fail in a way that results in permanent data loss (whereby I can't decrypt some subset of the data)

- if I had to yank this out, what's the process? will I be stuck?

- what are the chances of us doing something stupid and lock OURSELVES out of our own data? what guardrails are available there?

- what is the key management story? (which answers a lot of the above questions)

- is this roll-your-own crypto (not just which algorithm, but how the messages are constructed, etc) or something standard and vetted? Because there's no secret sauce to be had there, it's more in making all those OTHER elements easier for me.

Thanks, appreciate it!

It depends on the use case. In our experience, it's been rare that queries on PII need to do anything more complex than substring matching (which we're working on support for). We're definitely not trying to be able to encrypt every column, just to make some common workflows around PII and PHI a lot easier.

Custom views can help, but it does mean you're dealing with access controls directly in the database which can be hard to manage. And the database is fully exposed through backups or engineers with server access.

Tonic is awesome! We think of synthetic data/differential privacy as a different use case - trying to replicate data across scoped environments while preserving certain properties or distributions of the entire data set. There is a security/privacy component from scrubbing the data, but the original data source is unmodified, and that's where we feel risk lies. And the desired outcome isn't to add security but to produce a data set that "looks like" the original well enough for testing/modeling/analytics.

> Are the policies something like "retool" gets tokenized or faked data back, and the main app gets everything?

Yep, that's exactly right. Application credentials are grouped under classifications, and policies can be included/excluded across classifications. We aren't passing authz through JumpWire but for something like Retool you can configure it to connect through different proxies for different users.

> I prefer self-hosted and reasonably auditable code for such sensitive systems. Is that the case here?

Exactly. The engine which interacts with your data is almost always self-hosted, and the web app also can be if needed.

> At my scale (50 person company), it works reasonably well enough with just me maintaining it.

Makes sense! No reason to add more tools to your stack yet if the custom process isn't too burdensome.

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.

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.