Hacker News Reader

Comment by pintxo | Hacker News Reader

Quite a complex approach, where most will be able to gain a lot with some very simple actions:

- dont collect data you do not absolutely need to service the user

- do not use third party libs or services, where you do not understand how they handle the data you submit to it

Completely agree pintxo, doing these basic things goes along way to ensuring there's a privacy first mindset when building anything. The question I’m looking to answer as we work on this problem at Ethyca is how do we make it easy for any developer to bake that mindset into what they’re doing when they’ve got a bunch of other objectives and often understand the detail of data minimization as a concept simply isn’t their area of expertise. Rather like the boundaries of security, we all need to do it, only some are subject matter experts but we all have to fold more security thinking into our work. I think we can make that far easier for every developer, whatever part of a system they’re working on.

The data collection part IMHO is a prime responsibility of the product owner. She needs to clarify what should be collected and also what should NOT be collected.

While the latter part is the prime responsibility of the developer team. You need a culture of skepticism towards 3rd party access to you (customers, users, company) data.

That second point is very interesting. Beyond reading code / SLA for the lib, I'm not sure there's an easy (read: time efficient) way to understand what data points are used for what purposes currently. At least it seems that would hold for a lot of services.

Am I missing something here?

The easy way is a Data Processing Agreement, which has to precisely list what data is processed which way.

This is of course a legal document and the implementation may do something else.

Considering blatant GDPR breaches by Google and Facebook such as their non-compliant consent flow have gone unpunished I would not trust a legal document when there’s previous evidence that you can break the law and successfully get away with it.

Exactly Nextgrid - this is on developers to solve. Data flowing through a system isn't policed by the legal agreement, it's developers who understand where/how data is being used - we're the ones who can fix this.

Right - you've nailed it, a legal document like a data processing agreement may be enforceable in court but system implementation can vary widely, often without malice but it still fails.

So the question to answer is how can we ensure an interoperable contract for data between systems/services - that requires an ontology for privacy that makes enforcement easy(er).

It is possible to make privacy definitions a declarative and low effort part of development for engineers - then code becomes the enforcing layer instead of legal agreements.

It basically boils down to: use as little third-party services/code as possible. Because vetting them is expensive and error prone (usually not enough insights to confidently judge). Prefer code over services.

Reply on news.ycombinator.com