Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

> Last - and most important for me - in industries like my own (healthcare), you work with highly regulated data that has to be stored securely, where having multiple copies of data on multiple laptops can pose an unacceptably large risk.

um... please tell me devs don't have access to production data in a healthcare environment (of all places!).

I mean, I understand the need for a representative dataset to develop and test against, but this is people's lives they're playing with!

And, you know, if you had a decent set of anonymised or fictitious customer data to work with, you wouldn't need to run your IDE in docker, and there would be less surface area for attackers to get to the data.

View on HN

> um... please tell me devs don't have access to production data

If developers don't have access to production data, then the solution is useless. How do people not understand this in 2019?

Millions of dollars have been dumped into various products centred around the idea of synthesizing 'production-like' data and all have failed. Because synthesizing fake data destroys the signal that makes the original data useful in the first place. If the engineers don't have access to it, then they can't extract the value from it, then what the hell are you doing in the first place?

You think if you give engineers a synthetic dataset and they build a blind solution around it, that the users will be extract value out of that data? That myth was dispelled a decade ago and there doesn't exist a single synthetic data success story since then.

I've had clients coming to us with the notion that they can give us fake imaging data and we can generate diagnostic insights from it. This crap needs to stop. If you can't trust engineers with your data to extract value out of it, then go ahead and munge it in excel.

> If developers don't have access to production data, then the solution is useless. How do people not understand this in 2019?

... what?

Think machine learning.

I am thinking machine learning. I am thinking I don't want a developer to run machine learning algorithms in a (unsanitized) development environment with access to production data.

How do you train validate and market test an ml model without access to production data? Please teach us all, this is literally a billion dollar industry question.

You duplicate the data in dev but remove the names, SSNs, emails, addresses, phone numbers, etc?

That's not enough even, in previous cases we've seen researchers augment datasets with other data to de-anonymize. https://www.wired.com/2007/12/why-anonymous-data-sometimes-i...

But I think in general the idea OP was dismissing was generating synthetic data rather than attempting to anonymize prod data. In that case you have a risk of modeling the generator rather than your users.

PII is only one type of sensitive information, there is a lot more.

The bottom line that if you want to draw insights from data, that particular data must make its way to the engineer unadulterated. If you de-risk some fields in your data via removal/masking/entropy, then you are excluding those fields from ml.

You are not talking about blinded machine learning, you're talking about not doing machine learning on sensitive data in the first place. The whole discussion is moot.

If it's literally a billion dollar industry question, then hire me. I'm not interested in continuing to feed corporations for free.

FWIW, as an example, Google developers don't have direct access to production PII data.

The best they get are aggregations (sufficiently large enough that you can't identity a person). Specific user information is only available if the user explicitly opts in to share it, and is scoped to the specific case for analysis.

It makes training/diagnosing ML models a challenge, to be sure

Let's be really clear here. It doesn't just make ML solutions a challenge. It makes them impossible.

Even with all the compute power and automation of google, you can't blindly create an ML model and say yes it works without a data scientist actually looking at the guts with row-wise access to the training/validation data.

You can't do analytics without giving engineers access to prod data. Not at even at Google.

And yet, they do.

Source: worked there, on a ML focused team.

Go on, tell us how it works so we can all start doing the same and save millions of dollars in risk/compliance crossing enablement.

https://cloud.google.com/solutions/sensitive-data-and-ml-dat... has some high level guidance on different techniques that can be applied, depending on the type of data you're working with.

I actually know this article, so I'll summarise it for the readers.

It covers de-risking data if it isn't required for ML models or is of low impact. Through removal of it, masking of it, or entropy injection to it. Every single one of these approaches is detrimental to an ML model and just make it useless unless the fields being controlled are't correlated to the outcome in the first place.

This article is an acknowledgement of the issue and the fact that solutions don't exist. Only risk management strategies which disable potential solutions.

Their ultimate answer is 'protect the data and give it to only a small restricted set of people'. Right back where we started.

Injecting entropy into your data in order to generate differentially private access actually typically improves model performance, rather than degrades it.

This behaviour is counterintuitive, but effectively you're enforcing a degree of regularization in a way similar to how data augmentation works. You'll get reduced training set performance and improved test set performance, as with other forms of regularization until you make it too strong.

I too share your same view.

When I had this same discussion, the response I got was its not a matter of trust. But apparently in the terms & conditions (that consumers do not read anyways, including myself). There is a part of the data not being viewed by anyone not using it for diagnosis or treatment of the patient. Basically, only anyone with a medical degree and part of the team treating the patient can access the data & does not mention about the engineer using the data to build a better system to improve the system used for healthcare. So, ideally they want a candidate with a double degree in software and medicine. This term is applicable to other domains also.

I do not accept the reason, but that is what it is.

If you only work with fictitious data, the conclusions of your analysis and models... will be fictitious.

Even anonymised date (which most healthcare data is btw.) has strict requirements on access control and copying.

As for “develop and test against”. There’s the entire field of data science and modeling that’s not focused with developing systems to expose the data, but doing analysis on the data.

>If you only work with fictitious data, the conclusions of your analysis and models... will be fictitious.

Not necessarily, there is a lot of work done on synthetic data which closely matches the properties of the real data both in academia and increasingly in industry.

If you only work with fictitious data, the conclusions of your analysis and models... will be fictitious.

That doesn't have to mean it's worse though. Testing with 10,000,000 fictitious accounts generated to cover lots of permutations of user data is a great idea even if the real data won't ever have some of those permutations. It's a testing technique called "fuzzing", and it's quite common.

It entirely depends on what you're trying to deal with. You may solve some problems there but looking at real data is a must for solving others.

How do you ensure your fuzzed data has statistical signal that approximates those present in the true data?

That’s testing not modeling. If someone asks you to do analysis of a drug trial and you come back with a report based on fictitious user data because “devs should not have access to real data” you’ll be laughed out the room.

sure, but are data scientists analysing vast amounts of actual customer data really using VSCode?

They tend to just use a browser IDE like Jupyter... =(

Yes... What do you think they’d use? Those who prefer python are using PyCharm and VSCode, and then some use Jupyther, while others use Rstudio, matlab or Mathematica. Of cause you also have some doing emacs or vim, but that’s a minority.

I see this particular development environment as an advantage for this particular situation. I work in health care, and in R&D we often have to help debug issues with a client implementation, which means having an anonymized snapshot of their data in our reporting system. Typically, we end up passing around DB backups and zip files of the client-specific code. It would be significantly easier to fire up a Docker container that was ready to go.

so then everybody has a copy of the docker container and access to the data too. How does that improve things?

Unless I misunderstood, the idea is to connect to a single place running the docker container, not that you bundle it and share the image.

>um... please tell me devs don't have access to production data in a healthcare environment (of all places!).

Have seen it quite a few times, but there needed to be a good reason and other options had to be exhausted. A few examples were due to zero-width characters which were sanitized by whatever tool that anonymized data, but broke something in the program.

There are brittle systems in healthcare.

sometimes it feels like there are only brittle systems in healthcare.

They do. In my experience, every query containing PII was logged. I trust it since I got a stern talking to when I emailed my private email some code I wrote for an unrelated side-project while at work. Lesson learned.

> I got a stern talking to when I emailed my private email some code I wrote for an unrelated side-project while at work.

I made the same mistake once. We should we glad we weren't fired.

You don't want standing access to this data. That would be a very bad idea.

On the other hand, you do need devs to be able to look at real data when it's absolutely necessary (generally with a code-enforced gatekeeper and an audit trail). And you need to make sure a dev can SSL into a node for repair/maintenance (again with an audit trail).

That's the argument for using one of the many Identity and Access Management tools/providers out there, including the systems that come baked into the cloud providers.

You certainly read a lot into that statement. Who said the data isn't anomymized and deidentifed? It's not a matter of just stripping identifiers off data and sending it off left and right, even then it's better to control access in a central, secure area. Even if you've deidentifed to an individual level there's inherent risk, that's why accessing even "public" datasets like Mimic III is still process heavy.

I work for healthcare and you are right, this article is bullshit. 90% of time we work on data that comes from expensive medical simulators. When we need specific real cases (e.g. for feeding to machine learning algorithms), we use real data from patients but this data goes through process of full anonymisation done by special team. Devs dont have access to production medical data, regulators would kill us otherwise

Not sure about VSCode, but I use CLion's remote-development workflow with a local docker container. Works well enough for my purposes.

Reply on news.ycombinator.com