Privitar and Leapyear are indeed part of competition on the more mature side of the spectrum. Even if all three of us use differential privacy, I would say that each company's core value prop is a bit different:
- 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.
You're correct, Sarus never sees the data. The software runs directly on the data infrastructure of the client. It's typically deployed on the public cloud for instance.
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.
No, we don't do federated learning at Sarus today. We operate in the trusted curator model: a party has a centralized database and lets external practitioner leverage it. This is the most common setup in the industry (think hospitals, health insurance companies, banks, streaming services...).
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.
If the model training is designed to profile just one user, no, the model won't work by design. What you describe is an attack on the privacy of that user and we do want to make sure they fail.
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.
Yes, there are many parallels with Duets we can look at Sarus as a productized version of it.
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.
Thanks! Our goal is that no matter what preprocessing function they pass, the only end up accessing outputs that comply with the privacy policies. The code gets access to the real data but it is shielded from the vendor who can only see protected outputs. It should address the risk of private information being exposed to them, but for sure, the more sophisticated the preprocessing code will be, the more challenging it will become. Deep learning on Dicom data is pushing the system to the edge a bit.
We developed our own generative model for synthetic data generation. It is an autoregressive model where each variable/attribute is derived from previously generated ones using Transformers networks (more details there: https://arxiv.org/pdf/2202.02145.pdf). So yes, correlations are modelled, although exact multicollinearity (when there is a linear relationship between bunch of attributes) would be a bit blurry in the synthetic data.
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.
The product solves the problem of the time it takes to access sensitive data for analytics and machine learning. When you work in a large healthcare or financial organization, each dataset is highly protected. Each time a data practitioner needs to work on it, they may have to wait for months for compliance processes to opine on a data masking strategy and engineering teams to prepare a data lab and implement this strategy. With Sarus, data practitioner no longer need to access data to do analytics or machine learning on sensitive data assets.
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.
Here is how it would work in theory (not including the scalability question of working with heavy DICOM files and huge DNN). I'm assuming your data is made of records composed by an image and some information about the image or the patient.
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.
We developed our own generative model for synthetic data generation. It is an autoregressive model where each variable is derived from previously generated ones using Transformers networks. If you are interested, you have more details in: https://arxiv.org/pdf/2202.02145.pdf
When we say it works on any types of data, we mean: numerical, categorical, text, images and compositions of those types (see the paper).
1. Sarus works on data that is organized in records. The intuition is that one record should not transpire in the results (hence protecting their privacy) but studying all records conjointly should be possible. It may be flat files, parquet filets, etc. but we do need this record-level organization. In a given record, there may be columns that are text or images, Sarus will work fine. We never worked on pdf documents. Conceptually it could work but this is quite far down the road.
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!
No, we do not. Pysyft was mostly first designed to do federated learning. Sarus targets organizations that have their data in one central repository in a trusted curator model. It lets external data practitioners query that data with all sorts of data jobs (not just ML, but also SQL analysis, and spark soon).
Sarus is designed for all data use cases, provided that access to a given user's information is not the objective. This is the case for all of BI, analytics, or machine learning. It also works for testing or debugging, building APIs, etc. It resonates with organizations' aspiration for the democratization of data.
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 API is designed to be hosted by our clients so that the software runs directly on their data infrastructure and no sensitive data leaves their systems. In this demo, it is obviously hosted by us.
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.