Hacker News Reader

Comment by yafbum | Hacker News Reader

The application domain for this stuff is so negligible... Who's going to pay for this huge added cost?

Either the customer whose data is being handled trusts the service provider enough to let it handle unencrypted data, in which case all the data is vulnerable to interception (and the vast majority of data processing falls into this category)

Or the customer doesn't trust the data processor to see the unencrypted data, their data but still wants to delegate processing to it. This is a very thin space to operate in. It sounds much easier to simply trust a physically separate and controlled computing plant instead of FHE.

View on HN

That's not the only trust model at play. Here is a different example of where FHE becomes very useful.

Cancer researchers will benefit greatly from patient data sets that might include very privacy centric elements such as genome sets, past medical history (of both them and relatives to help understand heredity aspects of the disease). Most people making an informed decision may be uncomfortable with this information being made widely available, at best perhaps OK with a select few groups, but not available to anyone researching this domain.

FHE would solve this, the data can be made available to anyone with compute power that wants to help, while still respecting the privacy of the patients.

How exactly would FHE work here?

One example would be a project like Folding@Home but with much more sensitive/personal information.

Organizations/universities could compute on data provided by a custodian organization without having to care about data handling.

No, I mean please explain the way you would use FHE to do that.

Are "privacy" issues are more important for people than "dying from cancer" issues though?

It would be useful to have control data sets as well, from those without cancer/illness. This is a problem in a lot of medical research where those affected with an ailment are much more likely to share data, participate in trials, and donate their bodies to science than healthy individuals are.

Who is 'people'? They're not the same set, not all of cancer research is looking at people currently 'dying from cancer', nor are there going to be enough from different demographies declaring 'I am concerned about dying from cancer more than my privacy' and volunteering their data. And even if there were, that trait itself is probably skewing your data and not necessarily generalisable to people not (so particularly) concerned about 'dying from cancer'.

Ugh.

All things equal, privacy is usually preferred. This technology would allow both. Why is it either or?

Or you can just have a supercomputer and run the code on the database, just don't distribute the whole database to the people writing the code. Seems far easier and cheaper

I've been working in the privacy space for a few years and always had the same opinion. If a customer doesn't trust the data processor, the logical conclusion is to not send any sensitive data at all, which is technically possible. But it means more edge processing, more client side processing, most likely not what Google wants. But they have to do _something_, even if nobody uses it in the end.

The practical way that people deal with this is putting a swarm of auditors all up in the processors' business. It used to be this way for telecom as well: to know whether comms were secure, you needed to walk the length of the cable and look for taps. Comms encryption has radically changed this. The question is, is there a similar revolution in the making for processing as opposed to comms. I strongly doubt the benefits will outweigh the drawbacks.

> The application domain for this stuff is so negligible...

They said the same about Rust ("it's a systems language, needlessly complicated for large user applications").

It also doesn't work for GDPR as legally encrypted personal information is still personal information. Just because you can't decode it today doesn't mean that you won't be able to decode it tomorrow (via key leak, quantum etc etc).

Reply on news.ycombinator.com