hexedpackets

The compatibility with the AWS CLI was mostly excellent in my experiences.

Interesting, I've had the opposite experience. Every single AWS service I've ever tried to build tests around with LocalStack has run into compatibility issues. Usually something works in LocalStack but fails when it hits the real endpoint.

I guess the CLI itself has mostly worked, its more the LocalStack service not behaving the way the real service is documented/works.

I think the argument still applies on a shorter timescale. The child mortality rate in the US fell from 26 per thousand in 1970 to 7 in 2020 [1]. It seems reasonable that some portion of kids that now have treatable but persistent illnesses such as allergies/asthma would have died just a few decades ago.

[1] https://www.statista.com/statistics/1041693/united-states-al...

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...

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.

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.

Totally agree. We're likely going to implement a partially homomorphic solution that allows for some specific queries. We aren't trying to build a general purpose computational environment as the use cases we support don't require arbitrary computation. The data people encrypt with JumpWire is pretty much all strings and the queries on them are mainly doing some sort of substring matching (mainly prefix/suffix).

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.

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.

Our engine is self-hosted, so all of the data is kept local to your network and we can't read any of it. Concerns about data access and query latency are the two biggest reasons we decided to take the self-hosted approach.

Whether engineers can access the keys and decrypt data depends on your setup. The engine can use either AWS KMS or Vault for top-level key management, so if an engineer has full permissions over those then they could get the keys out. We can also host the keys in our infrastructure and sync them over to the engine if you're comfortable with that tradeoff.

Thanks! The plugin is pretty nice if you're sticking to just Prisma for your backends. Always happy to chat about your use case or give a demo of how JumpWire compares if you're interested.

Glad to hear you like our approach! We haven't fully solved indexing/complex querying yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. When encrypting directly in the database most queries other than direct comparison won't work. We have some early work started on using both homomorphic encryption [1] and format-preserving masking which opens up the ability to use other query operations.

With JIT response encryption none of that is an issue, the database still has the raw data but applications are protected. The downside is it can be slow for large amounts of data.

[1] https://en.wikipedia.org/wiki/Homomorphic_encryption

Thanks for letting us know, should be fixed in a minute!

The short answer is we haven't fully solved it yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. For the former most queries other than direct comparison won't work - we have some early work started on using both homomorphic encryption [1] and format-preserving masking to help there.

With JIT response encryption none of that is an issue, but it can be slow for large amounts of data. Any kind of big-data analytics will be a poor fit for JumpWire right now.

[1] https://en.wikipedia.org/wiki/Homomorphic_encryption

The value prop is definitely very similar. I'm not as familiar with Voltage as I am with other solutions, but my understanding is that it requires either using the Voltage database driver (JDBC/ODBC in particular) or an HTTP API.

With JumpWire, all of the works happens in an engine proxy that works directly with the database protocols. That makes the integration simpler - any language and connector can be used by just changing the hostname and auth. The downside is it's harder for us to add new databases - Voltage's approach definitely wins out there.

We have thought about that! It's a nice approach for some use cases but having just a read-only copy ends up being pretty limiting. Often people using internal tools (particularly customer success) needs to modify some fields in a record but shouldn't have unrestricted access to everything. We've found that being able to protect specific fields instead of the entire database gives a lot more flexibility.

Sometimes the merchant does pay for a fraudulent transaction, and sometimes the issuing bank does. The credit card networks never pay. It depends on several factors including whether the card was physically present and whether it was swiped or used a chip.

There's a complete lack of enforcement for bike thefts (at least in the US cities I've lived in). Even if you have GPS coordinates that unequivocally lead to the thief, the police won't take any action. Maybe this is different in other countries.

Electric cars still generate a massive amount of pollution. Brake pads and tire wear in particular are large sources for every type of car.

10% annual is not huge at all, it would actually be on the lower end of a year that had positive gains. 10% average is what you should expect for the SP500 - and that tends to be driven by lumps, years with returns >20%.

50% is high from a historical perspective but there are plausible explanations for why it's not absurd.

You might be thinking of the Boox Note line of devices. The Remarkable runs a custom Linux distro, not Android.

In an existing city, the cost to purchase land and buildings that would need to demolished, rezoned, and rebuilt as a higher density area with accompanying infrastructure is astronomical

This happens all the time in NYC, though. Anywhere from a several-story small/medium apartment building to a large skyscraper.

I think the limiting factor is much more likely to be air rights and zoning than safety standards.

Not sure about the UK, but any kind of insecure or temporary housing is counted for the US - including people living on couches.

$500 stationary bikes are crap. Apple Fitness is only slightly cheaper than Peloton standalone - $10 vs $13 - so I don't think that would be a factor for many people.

The main drive of Peloton if you aren't buying their bike is the instructors and high quality classes - I struggle to imagine many people would care more about watch integration than class quality, and I don't think Apple will be able to win out on the latter anytime soon.

We know that removing traffic calming devices causes faster and more reckless driving. Poorly designed streets in high-density areas tend to rely on heavy traffic as their primary means of traffic calming. The pandemic could also separately be playing a role, but its certainly not the only cause if it is a factor.