Category: Design Patterns

Privacy in a time of Big Data

Privacy in a Time of Big Data

Ann Racuya-Robbins

The emergence and existence of Big Data technologies and techniques have scoped the challenge of insuring privacy in contemporary life. It is fair to say that there is an inverse relationship, roughly speaking, between big data and privacy. That is as data scales up privacy challenges become more grave. The factors pressuring big data to scale, to get bigger, faster… are powerful including a hoped for competitive edge and speed and cost reduction of analytics to acquire these competitive edges under the name patterns. While the term patterns has gained currency in the field the term’s meaning is not so well understood. It is important to state clearly that the patterns that are sought are themselves data that contain or create an advantage. Understanding is itself an advantage.  By advantage is meant largely a competitive commercial monetary advantage by a third party other than the data subject.

Privacy is a subject of individual life and living.

Privacy is an expression of biologic specificity. Privacy properly ensured and governed preserves innovation, creativity and living development. In this way privacy is a key ingredient of survival and successful maturation.  The pervasion of data that has thrown open the loss of privacy carried in computer and ICT infrastructures is a relatively new phenomenon. The concern for privacy is a recognition of the broadening value of all individual life.  A recognition of the dignity and richness of every life. A recognition that individual life is not rightly an object or property of another.

Privacy cannot be reduced to personal information i.e. name, address and/or other factuals. PII is an obsolete moniker for our subject.

Let us stipulate that we will in this first instance be referring to living individual adults. Living has many stages and forms that must to be addressed later.

Privacy is—living individual’s control over and freedom and refuge from data collection, capture, extraction, surveillance, analytics, predictions, excessive persuasive practices and communication of the living individual’s life, including external or internal bodily functions, creations, conditions, behavior, social, political, familial and intimate interaction including mental, neural and microbial functioning—unless sanctioned by civil and criminal law and when sanctioned only under protocols where the ways and means of collection, capture, extraction, surveillance, analytics and communication including new methods to emerge are governed by appropriate social cooperation principles and safeguards embedded in ICT infrastructures and architectures overseen by democratic courts and civil and community organizations and individuals peers charged with insuring proper conduct.

Living individuals own the data generated by or from their lives. Should revenues be generated from the collection, capture, extraction, surveillance, analytics and communication of the living individual’s data the majority of revenue generated from the living individual’s life belong to the living individual. Data ownership, provenance, curation, governance as well as the consequences of violations of privacy practices must be encapsulated in or within the data, be auditable and travel in encrypted form with the data. Where possible block chain techniques shall be employed as well as counterfactual strategies (processes) in engineering privacy.

Provenance is an accounting of the history of data in an ICT setting.

 

Next Steps

Define further Data Governance, Data Provenance, Data Curation, Data Valuation. Integrate the principles and practices outlined above into an archetypal Privacy Use Case(s) and articulate the Privacy Use Case as it proceeds through the reference architecture.

 

 

 

 

Design Patterns and Human Trust Experience

Responses to questions from Mary Hodder about Design Patterns, the Human Trust Experience and Privacy

Thank you Mary for this thoughtful response. I will be replying over the next several days in a number of ways.

ARR: In Bold

To begin—

Why is Identity_Design_Patterns and related material on its own section on the wiki and not under “User Experience Approaches” or something like that? It makes it seem that there is agreement that this is the right approach and language. I don’t think that has been ventilated. I don’t think there is anything intrinsically more valuable from the individual human user’s perspective about a design pattern approach. It could be but it could not be as well. There are however many privacy and other human rights and human dignity issues involved in extracting human behavioral characteristic from data sets including analyzing those behaviors and making design decisions based on this approach. The larger the dataset(s), while not linear necessarily, the more specificity is achieved in identifying individual human user’s living behavior. Unfortunately we will have to do the hard work of sorting this out probably by context. The context of a natural disaster emergency have very difference requirements than commercial settings where organizations want an individual to buy something.  For this reason the ethical considerations need to lead the discussion. I might add that from my experience with Christopher Alexander much of his inspiration for his Pattern Language was to empower individual humans and communities to build their own housing solutions and not have to depend on architects. In our current Identity setting we are not teaching/empowering individuals to express their own requirement but extracting and perhaps modifying behavior.

More comments interleaved below.

From: Userexp_wg [mailto:userexp_wg-bounces@idecosystem.org] On Behalf Of M a r y H o d d e r

Sent: Tuesday, September 23, 2014 6:41 PM
To: userexp_wg@idecosystem.org
Subject: [Userexp_wg] Design Patterns question

Hi All,

In our meeting today, we discussed Design Patterns, generally and specifically (a bit) that Tom has worked on for our group.

They are located on the UXC wiki and here is a specific Design Pattern on Identity:

https://www.idecosystem.org/wiki/Identity_Design_Patterns

I will be adding comments on the Discussion pages on the Wiki as well.

You can find more (there are several) by searching for “pattern” in the wiki search box.

The purpose of Design Patterns or Anti-Patterns is to show a positive or negative pattern of activity that is useful or not useful.

What is a positive or negative pattern of activity? Who decides this? What is useful or not useful? From whose perspective and to what ends? Without answering these questions there is no ethical frame of reference or context.

We sent some time today addressing Ann’s questions and issues around Design Patterns as a category of work

for IDESG, as well as her specific concern about data collection and privacy issues to do with Design Patterns.

My concern is not merely data collection as I have tried to begin to amplify here. But I do think it is an important question to ask who does a pattern of activity belong to? The individual human that generated/created the pattern of activity? A “pattern of activity” tends to make invisible how that pattern of activity was obtained. Obtaining a pattern of activity could also be described surveillance.  

Ann, I would invite you to discuss this in email with the group as I have not likely fleshed out your concerns completely.

But I will also say that during the meeting, I couldn’t see how a Design Pattern would involve specific data collection

that would cause a specific privacy violation. I can see that if a vendor or provider used a design pattern, that in their specific

implementation, they would likely collect identifying data about individuals. But the Design Patterns aren’t really designed to manage that.

Doesn’t that depend on the implementation? There is no out of the box guarantee.

Instead, there are places to mitigate this potential problem:  1. for our purposes, a UXC-made Design Pattern will go through a Privacy Committee review.

The role of the Privacy Committee and the Privacy Committee Liaison is to note privacy challenges as the work product is being developed and work to modify the work product to eliminate the privacy challenge before it goes through a Privacy Review.

 2. Vendors or providers that want to do something that IDESG would certify, or allow as

a standard, or allow to use a Trustmark, would, if they didn’t protect individual privacy, not pass the Privacy Committee’s

reviews because they wouldn’t comply with the NSTIC requirements.

This is part of the problem I brought up about the complexity of the requirements and interactions including within the Functional Model and “Trustmarks”. There are so many steps and so many processes so many levels of expertise needed to track and evaluate all the moving parts that clarity as to trustworthiness is extremely difficult and more importantly impractical. If someone wanted to create a system where the parts most especially individual human users were to make judgments about trustworthiness someone would not go about it this way! It is dangerous in my view to conclude that IDESG certifications, privacy reviews and standards will solve this problem. It may and it may not. It may for a time and then fail. The important consideration is how much people care about the system they are creating and how much agreement there is about the purposes it should serve.

Our job here is to focus on usability, and usability of privacy issues if necessary. But the Privacy Committee is first responsible for that.

Does that make sense?

They are interdependent and more so in ways that some other working areas may not be.

In my view, Design Patterns are a very useful way to communicate a pattern of activity we would like to see vendors or providers follow,

outside of other concerns like Privacy, Security or Standards, for example.

You may be right about that. However I don’t know that the design patterns so far listed do that. Still I have been trying to get a recording of your session at the Plenary so I can review it. It may be possible to co-create such a pattern.

Lastly, you were concerned about whether Design Patterns were a good fit for UXC to focus on for fulfilling the NSTIC requirements

and since I use them a lot in my other work, I do find them very useful. Others here do as well.

As I mentioned I need to understand what is meant by useful. And how that is measured. I think that discussion could bring a lot of clarity.

Can you elaborate on what the issue is, so that we can understand your concerns?

Or, if you’d like, we can translate the UXC Guidelines doc we have just had the Chairs group looking at onto our wiki,

and try to suss through the options and hierarchy of work possibilities there?

Not sure I understand the choices here. I am planning to comment and provide input on the UXC Guideline doc.

I do want to address your concerns, but also want to keep the group moving, so if we could work through this in the next couple

of days here in email, and then resume our agenda right where we left off, on Tuesday, that would be very helpful.

I don’t think a couple of days is adequate although I do agree that we need to continue to make progress. It has already been a couple of days and I am just now getting to this…to be sure it is not for lack of effort.

 Regards,

 Ann Racuya-Robbins

Thank you,

Mary