maximeago

I remember that it was a lot easier if I had 10 instances of Winamp running at the same time, it was not just that time slowed, the physics was different. Was this ported?

Nice way to make differential privacy approachable to everyone with open source. Was it peer-reviewed?

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.

That's a great suggestion actually! We'll definitely work on it and thanks for your help.

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.

This person just joined last month! ;)

Thanks for catching it! will fix it.

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.

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.

Hope that helps clarify.

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.