Privacy-by-Design for the Security Practitioner (Video and PDF)


#1

Of course this is from the perspective of Internet 1, but would be something that Builders would need to consider?

If we get our anarchist hat on and have the standpoint that privacy and sovereign law will not impact the SAFEnetwork (and what layers on top i.e blockchain) the content of another article may be pause for consideration: Mitigating the Legal Risks of Issuing Securities on a Cryptoledger

What sort of disclaimer comes with SAFE, I have no idea on this stuff, but worth pondering the whole litigation thing. I dont think the maidsafe ‘defensive’ patents are a shield against this stuff?

Privacy-by-Design for the Security Practitioner PDF

Summary

Privacy-by-Design has become the de facto standard for privacy engineering. Security practitioners are venturing (or are being drafted) into privacy in greater numbers, and the principles and philosophy of Privacy-by-Design will be familiar for the most part.

We have concentrated on two areas that may be less familiar: data minimization and enhancing user transparency or understanding. Both are areas that are rapidly increasing in importance. Data minimization emphasizes machine learning, and its relevance is surging as the size and pervasiveness of user data grows.

Managing user understanding meanwhile emphasizes the human-computer interface. Besides the need for general improvement in this area, the rise of mobile computing and the Internet-of-Things forces different modes of interaction

Privacy-by-Design has 7 Foundational Principles:

  1. Proactive not Reactive; Preventative not Remedial
  2. Privacy as the Default
  3. Privacy Embedded into Design
  4. Full Functionality – Positive-Sum, not Zero-Sum
  5. End-to-End Security – Lifecycle Protection
  6. Visibility and Transparency
  7. Respect for User Privacy

One can easily find information on these principles and studying these principles
would certainly be time well-spent. However, for the purposes of the security practitioner, one can perhaps simplify these principles down to three basic questions to keep in mind:

(1) Is the data “secure”? That is, are the expected data outflows the actual data outflows? This is actually a question about the security architecture, which privacy relies upon. This article is directed towards security practitioners, so I won’t say more about this question.

(2) Have we minimized the data collected? The less data collected, the more the risk is reduced. Generally, one should only collect data that conforms to a particular purpose that we’ve communicated to the user and we should keep the data only as long as we need it for the specified purpose.

(3) Does the user understand? Does the user have a good understanding of the kind of data that he is releasing, who he is releasing it to, and what it will be used for? Does the user have a good understanding of the inferences possible with the data?


#2

If you are thinking that builders issue securities on the SAFE network then they will be required to follow the laws within their jurisdiction, the same as if they were issuing securities on the centralised web. I would agree that the patents have no impact here, they only prevent existing technology companies trying to unfairly limit new products developed by SAFE builders.

End User License Agreements (EULA) typically cover things like disclaimers, however, in my experience these are typically handled within the applications as opposed to the infrastructure. I’m not aware the HTTP has a disclaimer for example.