Launch HN: Sarus (YC W22) – Work on sensitive data with differential privacy
When data is sensitive, getting access can be a huge pain. It means going through a long manual validation process that includes designing, and implementing an appropriate data anonymization. It takes weeks to months and some data utility may be lost to the masking requirements.
Sarus makes all of it irrelevant by letting analysts work on data that is never accessed. Analysts only access outputs of their data jobs, and those can be protected with appropriate privacy measures.
With past lives in healthtech, finance, and marketing, we’ve experienced first-hand that data governance has taken a huge part in data operations. It’s a rightful objective to protect data but it should not have to hamstring all innovation. For most data science or analytics objectives, the analyst has no interest in the information of a given individual. They look for patterns that are valid across the dataset. Access to user-level information is just an unfortunate way to get there.
We decided to build Sarus so that data access is no longer a requirement.
The Sarus API proxies all queries, compiles them into a privacy-safe version, runs them on the original data (which never moves outside of our clients’ infrastructure) and outputs the protected results to the practitioner. The protection relies on differential privacy, a mathematical definition of privacy already used by leading tech companies. Differential privacy works by adding calibrated randomness to outputs so that the information of any given individual cannot be inferred. One of its main benefits is that it does not make any assumption on what is sensitive in the data or what the recipient of the output may already know or do. This is the ideal candidate for replacing all manual data governance processes by something fully automated. Each query gets rewritten by Sarus in a way that implements its core principles.
For the core primitives of differential privacy, we leverage the latest research (Dwork & Roth 2014, Abadi 2016, Dong 2019, Koskela 2020 or Wilson 2019) and open source implementations (tensorflow-privacy, Google Differential Privacy, OpenDP, Smartnoise). Our key contribution is to bundle everything into an API that can be queried without seeing the data in the first place. It requires proper privacy accounting (we use PLD accounting as in Koskela 2020) but also setting all the technical parameters that are required by the framework (estimating range of input data, allocating privacy budget across computation steps…). We also optimize the privacy utility trade-off by memoizing previous queries as much as possible.
Wait, but the first thing data scientists do is to check out the data, how do I do that now? Not a problem, the API provides synthetic data samples with the same schema and statistical distribution by default. It effectively replaces the need to see any record, and data scientists can still do feature engineering, test and debug code with it. Of course, synthetic data is not something you would want to build insights or ML models on, you’d use the API to do that on the original data.
How it works: the app is deployed in the cloud infrastructure (any cloud vendor is compatible). The data admin lists relevant data sources from the UI or the API, and grants learning access to practitioners by applying a privacy policy among predefined templates. The synthetic data sample is automatically generated. From there, data scientists can run their analyses with their usual tools (pandas, numpy, TF, scikit-learn, Metabase, Redash, Tableau…), whether from a python SDK or a hiveSQL connector.
Curious? ...
49 comments
[ 5.8 ms ] story [ 123 ms ] thread(As far as I'm concerned, if the answer is yes to both, this has much potential. I'm just trying to figure out what I'm looking at)
Thank you!
[1]: https://blog.openmined.org/duet-demo-how-to-do-data-science-...
There are some differences though: - we designed for the trusted curator model where Duet is mostly for federated learning tasks in mind - the privacy policies are based on principles (such as: "DP-outputs with epsilon < 2 can be shared", "DP-synthetic data can be shared", or "weights of ML models can be shared"), then the gateway applies the principles to any query, whether it is a SQL query, an ML model or else. In Duet, it's all about manual validation of given queries.
this page specifically https://www.sarus.tech/solutions just screams "UX is an afterthought"
That being said, Sarus can be used to protect one node of a federated learning network. For instance each hospital could have a Sarus instance. The data scientist would need to take care of the orchestration of the nodes themselves but the Sarus API would make their life easy to interact with each data source, especially if all the sources are not identical.
This being said, the goal of Sarus is to enable analysis on the original data with privacy guarantee on the result (synthetic data is merely used as a tool and a fallback when there is no better solution) so you can write a statistical test to detect multicollinearity and run it on the original data within Sarus.
> Our key contribution is to bundle everything into an API that can be queried without seeing the data in the first place.
Without being seen by who?
A big innovation is that, with Sarus, the data practitioner does not need to see the data and can still manipulate it. Most DP libraries are designed for researchers that have access to the data. They can prepare the data however they like, tune the libraries all they want, and eventually use the library to produce protected outputs from the data. With Sarus, someone who never saw the data, can achieve the same.
1. How well does Sarus work with data that is not in a database, like unstructured data such as documents/text?
2. How does Sarus handle 'legacy' DB's, where the schema for a table might not be quite right, but due to operational constraints these schemas can't be easily corrected? The canonical example I'm thinking of is date times that have been specified as strings and no one bothered to change them.
3. What kind of language support exists for interacting with the Sarus proxy? Obviously, you have Python support but for large enterprises that might need Sarus oftentimes there are a few languages that are popular internally and all need equal support. I think the comprehensive list of analytics languages in use in large orgs would look something like, [python, R, Julia, Matlab, SAS]. Rust/C++ support would be ideal as well as they're commonly used in Python/R to accelerate hot code. Do you have plans to develop SDK's? Would they be hand crafted or do you plan to develop generated SDK's similar to how GCP does it?
4. Are you moving to get any security certs? Of course you're a startup right now, but I know from experience enterprise orgs will still blindly ask questions like, "Are you FedRamp Moderate/High certified?" (This doesn't even make sense for your sales model and I'm certain you'll still have to answer this question and explain why over and over.) or "Do you have a Soc 2 Type 2 report we can look at?". The orgs that actually need something like this are going to be asking these questions pretty quickly.
5. When I use Sarus, do I have to use your IDE/interface? One of the things I noticed when looking at your demo gifs is there is a lot of use of notebooks, which of course are popular, but you'll be met with a lot of resistance if your users can't use the tooling they prefer (PyCharm Pro / DataGrip plugin to interact with DB's in my teams case).
6. How exactly is Sarus deployed? Terraform? Is it a containerized application? Does it scale vertically or horizontally? Can its logging mechanism integrate with StackDriver, Splunk, or Cloudtrail?
7. Have you proved out the technology with more complex time series data? I'm thinking of sensitive trading data.
8. Do you provide benchmarks for showing that a model trained on a real dataset is equivalent in performance a model trained on the synthetic dataset?
Super cool product and you're in a great position to make a ton of money if you nail the execution and get some large customers!
2. Sarus has connectors to the main DB and we add more when we meet them. The basic assumption is that the experience should be the same as working on the data in its original form. For instance if your data is in a CSV with a weird date format, you will be able to (i) get synthetic data with this same weird date format, (ii) apply python code that transforms this weird date format into something more conventional and use that reformatted version. When running your data job, Sarus will apply your preprocessing code and take it from there.
3. Today we have a python SDK and a SQL connector. Both leverage the same low-level API. We may build other SDKs for other languages but haven't started doing so.
4. Indeed, we don't have any cert yet but we are looking into getting some soon. We are about to start Soc2 for instance. This is somewhat less of a requirement as we never host any of our clients' data. Of course, everything that helps get the green light of the ITSec team is useful.
5. The python SDK is standard python code so you can use in any python env. The notebook is just here to make it more user-friendly in demos. Same for SQL, you can use any SQL querying tool, we did the demo with Metabase.
6. The easiest way is to deploy a docker image with Docker compose. It does not scale on multiple machine yet (stay tuned). In that sense, big data sources are only partially supported: if the source is RedShift and you submit a SQL query to the API, we'll rewrite it and send it to Redshift (which scales), but if you want to do ML on the same data, we won't be able to scale the same.
7. Complex time series is not a problem for the remote execution part provided it is stored in a traditional format. That being said, we don't have a specific synthetic data model for time series yet, so that part of the experience will be a bit different.
8. This is a debate we leave to researchers because there is not a single answer. It depends directly on the number of records in your dataset and the dimensionality of your data. However, you can set up privacy policies so that the weights of ML model without DP are allowed to be shared. This is considered acceptable by 99% of compliance teams in the world today so it's not a huge compromise. If you use Sarus this way, you are guaranteed to have exactly the same performance.
Would love to continue the conversation offline of course!
Differential privacy provides much better protection than data masking, but most importantly, it does not require any manual decision (which column to mask, how, etc.). This is what makes it easy to apply at scale to all datasets in the data warehouse or data lake instead of having dataset per dataset decision making involved.
Differential privacy is used by Apple, Google, Microsoft, or the US Census. When used properly, the data protection it provides does not need to be proven to regulators or security teams anymore. That being said, regulators do not require DP protection per se. They require organizations to put in place the best practices in terms of data governance, data minimization, or data security as a whole. This is part of the answer.
The system will generate a fake dataset with the exact same structure and schema (the information on patients is realistic, the images look reasonable and importantly has the right encoding, size, etc.). The purpose of this fake data is for the vendor to adjust their algorithm to be able to consume your data as it is. The vendor builds up the preprocessing on the fake data and then submit their data job to the API (say a preprocessing function to be applied on each record and a Tensorflow model to be fitted on the data, or just to measure the performance on the data). The preprocessing code runs on the original records, the model would be trained or validated against the real data. In the end they can prove the value of their model without having to get their hands on the real data.
I've not encountered differential privacy in my work before now, but at least for dealing with metadata in the DICOM it could probably be helpful for some datasets. But it could still be challenging to ensure the IODs are correct (or that known quirks are preserved). Anyway this is very interesting. I have a colleague who is working on some utilization/value research using billing records and I'll show him this.
"PRIVACY-BY-DESIGN
Time-to-data: from months to minutes
Organizations that use Sarus outperform their peers at execution speed for machine learning and analytics while being more secure "
When internal access to personal data is not a concern within an organization, data sharing with external partners certainly is. This process can be avoided just the same.
Hence the promise of taking time-to-data form months to minutes.
Hope that helps clarify.
Maybe the hero text could be more clear, explaining in summary what it does (similar to this comment). "Get instant access to sensitive data for analytics and machine learning."
If so, how is it privacy compliant, i.e. suffice the intent of the law in say, EU countries, or will not be identified as "privacy theater" in the US? If not, what do you do in these cases?
Cool to get your take on this.
The way differential privacy works with machine learning is that it guarantees that one given record cannot have a significant impact on the weights of the models and therefore on its performance. In the particular case of SGD-based models, the guarantee holds for every step of the descent. A good place to start on the topic is Abadi 2016 (https://arxiv.org/pdf/1607.00133.pdf).
What is important in the approach is that we don't need to detect that there is something funny in the loss function of the model. Sarus uses the exact same approach whether the model or the loss function is malevolent or not. The guarantees still hold. This is important because a lot of models can extract personal information even with no intention of doing so and no real way to detect it.
A good way to think about model performance is that we are looking for models that perform well irrespective of one record. If there are many users that have the same pattern of the user you are trying to spy on, the model may still be good but you won't know whether it's because of that user or not.
> ...the API provides synthetic data samples with the same schema and statistical distribution by default
Neat. Repurposing test data generators. I like it.
> Our model is a software license to run on our clients’ cloud.
Just to confirm my understanding: Sarus never sees the client's data? Cool.
--
I'm fine with differential privacy. I haven't read those most recent papers, so I'm a little out of date.
That said...
Encrypting data at rest at the field level is an important missing piece from the future perfect privacy stack.
Just like how proper password vaults work. Salt, hash, encrypt. Never store the actual password.
The book Translucent Databases details clever examples of this strategy for misc use cases. Never store PII as plaintext.
Translucent databases and differential privacy are orthogonal. I have no ideas on how to productize (or SaaS-atize) translucent strategies.
And here, of course, differential privacy only guarantees the data protection in the flow of data between the data source and the data practitioner. It should not be a replacement for other best practices like the ones you mention.
And indeed, data encryption and privacy-preserving analysis (what Sarus does) is quite orthogonal. You may combine them for some use cases (so that data are protected on the machine, but also cannot be re-identified from queries) For example, on our infra (used only for demo, not for clients), by default all data are encrypted at rest by the cloud provider. You could even try to add FHE (Fully homomorphic encryption), but that's quite complex (and probably wouldn't support many type of data analysis).
- https://github.com/google/differential-privacy (for basic mechanisms and PLD accounting)
- https://github.com/tensorflow/privacy (for DP-SGD and RDP accounting)
- https://github.com/opendp (for our SQL module)
We actively contribute to some of them.
We also open-sourced some tech bricks we are using:
- https://github.com/sarus-tech/dp-xgboost (see also https://arxiv.org/pdf/2110.12770.pdf)
We plan to continue building trust in the tools we are using by publishing some of them.
- Sarus: replaces the manual governance of data access by "no-access". Analysts or data scientists can manipulate data without accessing it. The absence of access means that the process is considerably simplified and no longer relies on many manual decisions and controls. Differential privacy is here as a way to automate protection.
- Privitar: it is a more traditional data governance solution. It is all about controls and manual decisions. In their own works, they feature an "unbeatable breadth of privacy techniques". Differential privacy is one of them. They leave it to the privacy professional to make their own implementation decisions, which is exactly what Sarus offers to disrupt.
- Leapyear: it is a data analysis solution powered by differential privacy. It does not seek to replace existing data governance processes. This is why they don't focus on blending into existing data workflows and only offers differential privacy as an way to access where Sarus can disappear into existing operations without requiring a learning curve on the part of analysts and data scientists.