5 ms·
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 po
by seanpreston 5y ago
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?
- formerly_proven 5y agoThe 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.
- Nextgrid 5y agoConsidering 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.
- c1ll1an 5y agoExactly 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.
- c1ll1an 5y agoRight - 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.
- pintxo 5y agoIt 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.