Showing posts with label Telecommunications. Show all posts
Showing posts with label Telecommunications. Show all posts

Wednesday, 8 June 2016

2nd IW5GS - Programme

The 2nd International Workshop on 5G Security

IW5GS2016

Xi'an, China

June 19, 2016

http://www.mobimedia.org/2016/show/program-final

IW5GS-01: (June 19, 2016, Sunday, 10: 30 – 12:30, Room B)

Session Chair: Valtteri Niemi (Email: valtteri.niemi@helsinki.fi)
Keynote 1: 5G Security for IoT
Speaker: Dr. Zhiyuan Hu, Nokia Shanghai Bell  (zhiyuan.hu@alcatel-sbell.com.cn)
Keynote 2: 5G Security: Forward Thinking
Speaker: Bo Zhang, Huawei (liufei19@huawei.com)

IW5GS-02: (June 19, 2016, Sunday, 14: 00 – 16:30, Room B)

Session Chair: Siddharth Prakash Rao (Siddharth.rao@aalto.fi); Ian Oliver (ian.oliver@nokia.com)
Paper 1: Protecting IMSI and User Privacy in 5G Networks
Karl Norrman, Elena Dubrova, Mats Näslund
Paper 2: Privacy of the Long-Term Identities in Cellular Networks
Philip Ginzboorg, Valtteri Niemi
Paper 3: Error-Correcting Message Authentication for 5G
Elena Dubrova, Mats Näslund, Göran Selander, Karl Norrman
Paper 4: Privacy in LTE networks
Siddharth Prakash Rao, Bhanu Teja Kotte, Silke Holtmanns
Paper 5: A Survey on Software-Defined Networking Security
Shanshan Bian, Peng Zhang, Zheng Yan
Paper 6: Designing Hybrid Cloud Computing Framework using OpenStack for Supporting Multimedia with Security and Privacy
Isaac Cushman, Lei Chen, Danda B. Rawat, and Nhien-An Le-Khac

Sunday, 10 April 2016

Information wants to be free...?

I both like and dislike the quote "information wants to be free", mainly because it opens up a very nice philosophical discussion on what 'free' means but also because - and this is part I hate - it is some damned meaningless without any grounding in any form of semantics; and we've seen this before!

For the first part, this statement treats information in an anthropomorphic manner. Is it really information itself that has the need to be free? Let's assume that it does, though in a very fairy tale like way, it seems to me.

So let's then look at the word 'free', which I assume does not mean 'free' as in 'without cost' in the sense that someone has to pay for it. Though this is a curious idea in that information is somehow prostituting itself and despite all attempts someone (the information's pimp perhaps?) insists on controlling things. I guess this is the idea that information is going through some pre-1960's sexual revolution...
Rather I think the word 'free' refers to 'freedom' albeit in a Western sense of the word. Think of the use of the concept freedom as used in the US Declaration of Independence.

"We hold these truths to be self-evident, that all information is created equal, that it is endowed by its Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness"
...or should that be Existence, Communication and Semantics perhaps....?

Let's stick with the word 'freedom' and its naive or common-sense meaning. What does it mean to be free? We can turn further to the the UN Declaration of Human Rights and the EU Charter of Fundamental Rights for further clarification, though here I'm sure we go into more of a legal-political debate more than anything. Evidently freedom means either the right to do or be something or the right to be protected from something.

So the question is, if information want to be free:

  • What does information want the freedom to do/be?
  • What does information want the freedom from?

Under the first question, the freedom to be 'free' as in 'without cost' certainly falls. What about the freedom to be private, or the freedom not to be abused - as in excessive privacy violations? Do we further need a notion of agency - does information have an owner or provenance?

Without answering those - I don't think I can give a definitive answer anyway - here's another thought. Given that matter = energy, isn't the use of the term information quite literally another way of saying 'humans' (or 'men' as in the Declaration of Independence). In which case the question 'information wants to be free' is just an expression of man's desire to define what freedom is - ostensibly in terms of freedom to do/be and freedom from.

And here comes the practical part, which freedoms to do/be or from do we allow or deny in order to be "free"?

Monday, 2 November 2015

Second International Workshop on Privacy Engineering (IWPE'16)

Second International Workshop on Privacy Engineering (IWPE'16)
Co-located with 37th IEEE Symposium on Security and Privacy

26 May 2016 - The Fairmont, San Jose, CA

************************************************************

IMPORTANT DATES

Deadline for abstract submission: 18 January 2016
Deadline for paper submission: 8 February 2016
Notification of acceptance: 22 February 2016
Accepted paper camera-ready: 3 March 2016 

************************************************************
 
We are pleased to invite you to participate in the Second International Workshop on Privacy Engineering (IWPE'16).

Privacy engineering research has never been a more timely endeavor. Ongoing news reports regarding global surveillance programs, massive personal data breaches in corporate databases, and notorious examples of personal tragedies due to privacy violations have intensified societal demands for privacy-friendly systems. In response, current legislative and standardization processes worldwide are seeking to strengthen individuals’ privacy by introducing legal and organizational frameworks that personal data collectors and processors must follow. As a result, engineers are increasingly expected to build and maintain systems that preserve privacy and comply with data protection standards in different ICT domains (such as health, energy, transportation, social computing, law enforcement, and public services) and on different infrastructures and architectures (such as cloud, grid, or mobile computing).

Although there is a consensus on the benefits of an engineering approach to privacy, few concrete proposals exist for models, methodologies, techniques and tools to support engineers and organizations in this endeavor. Work that focuses on helping organizations and software developers to identify and adopt appropriate privacy engineering methods, techniques and tools in their daily practices is also missing. Furthermore, it is difficult to systematically evaluate whether the systems developed using privacy engineering methodologies comply with legal frameworks, provide necessary technical assurances, and fulfill users’ privacy requirements.

Clearly, more research is needed in developing methods that can help translate legal and normative concepts, as well as user expectations, into systems requirements. There is also a growing need for techniques and tools to support organizations and engineers in developing and maintaining (socio-)technical systems that meet these requirements. In an effort to close the gaps in research, the topics of IWPE'16 include all aspects of privacy engineering, ranging from its theoretical foundations, engineering approaches and support infrastructures to its practical application in projects of different scales.

Specifically, we are seeking the following kinds of papers:
  1.  technical solution papers that illustrate a novel formalism, method or other research finding with preliminary evaluation;
  2.  experience and practice papers that describe a case study, challenge or lessons learned in a specific domain;
  3.  early evaluations of tools and techniques that support engineering tasks in privacy requirements, design, implementation, testing, etc.;
  4.  interdisciplinary studies or critical reviews of existing privacy engineering concepts, methods and frameworks; 
  5.  vision papers that take a clear position informed by evidence based on a thorough literature review.

IWPE’16 welcomes papers that focus on novel solutions based on recent developments in privacy engineering. Topics of interest include, but are not limited to:
  • Integrating law and policy compliance into the development process
  • Privacy impact assessment during software development
  • Privacy risk management models
  • Privacy breach recovery methods
  • Technical standards, heuristics and best practices for privacy engineering
  • Privacy engineering in technical standards
  • Privacy requirements elicitation and analysis methods
  • User privacy and data protection requirements
  • Management of privacy requirements with other system requirements
  • Privacy requirements implementation
  • Privacy engineering strategies and design patterns
  • Privacy-preserving architectures
  • Privacy engineering and databases
  • Privacy engineering in the context of interaction design and usability
  • Privacy testing and evaluation methods
  • Validation and verification of privacy requirements
  • Engineering of Privacy Enhancing Technologies (PETs)
  • Integration of PETs into systems
  • Models and approaches for the verification of privacy properties
  • Tools and formal languages supporting privacy engineering
  • Teaching and training privacy engineering
  • Adaptations of privacy engineering into specific software development processes
  • Pilots and real-world applications
  • Evaluation of privacy engineering methods, technologies and tools
  • Privacy engineering and accountability
  • Organizational, legal, political and economic aspects of privacy engineering

This topic list is not meant to be exhaustive, as IWPE'16 is interested in all aspects of privacy engineering. However, to screen out off-topic papers early in the review process, we request authors to submit an abstract prior to their paper submission. Abstracts of papers without a clear application to privacy engineering will be considered outside the scope of this workshop and may be rejected.

************************************************************

PAPER FORMAT & SUBMISSION GUIDELINES

We solicit unpublished short position papers (up to 4 pages) and long papers reporting technical, research or industry experience (up to 8 pages) on all dimensions of the privacy engineering domain. Each paper, written in English, must follow IEEE Proceedings format. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will attend the workshop to present the paper.

Abstracts and papers must be submitted via EasyChair

All IWPE'16 Papers will be published in IEEE eXplore, which is indexed by EI Engineering Index, ISI Conference Proceedings Citation Index (CPCI-S), Scopus, etc.


Sunday, 24 November 2013

Privacy, Evidence Trails and a Change in Terminology?

One of the main aspects of personal [information] privacy is that much of the topic is that other parties would not collect nor perform any analysis of your data. The trouble is that this argument is often made in isolation, in that it somewhat assumes that the acts we perform by computer exist in a place where we can hide. For example, what someone does behind closed doors usually remains private. But, if that act is made in a public place, say, in the middle of the street by default whatever is done is not private - even if we hoped no-one saw.

Anything and everything we do on the internet is in public by default. When we perform things in public, then other people may or will see, find out and perform their own analysis to form a profile of you.

Many privacy enhancing technologies are akin to standing in the middle of a busy street and shouting "don't look!". Even if everyone looks away, more often than not there is a whole raft of other evidence to show what you've been doing.

Admittedly most of the time nobody really cares nor are actually looking in the first place. Though as it has been found out recently (and this really isn't a surprise) that some such as the NSA and GCHQ are continually watching. Even the advertisers don't really care that much; their main interest is trying to categorise you to ship a generic advertisement - and advertisers are often really easy to game...

If we really do want privacy on the internet then rather than concentrating on how to be private (or pretending that we are), we need to concentrate on how to reduce the evidence trail that we leave. Such evidence is in the form of web logs, search queries, location traces from your navigator, tweets, Facebook postings etc.

Once we have understood what crumbs of evidence is being left, we can start exploring all the side avenues where data flows (leaks) and the points where data can be extracted surreptitiously. We can also examine what data we do want released, or have no choice about.

At this moment, I don't really see a good debate about this, at least not at a technical level though there are some great tools such as Ghostery that assist in this. Certainly there is little discussion at a fundamental level which would really help us define what privacy really is.

I personally tend to take the view at the moment that privacy might even be the wrong term, or at best, somewhat a misleading term.

On the internet every detail of what we do is potentially public and can be used for good as well as evil (whatever those terms actually mean), our job as privacy professionals is to make that journey as safe as possible, hence the use of the term "information safety" to better describe what we do.

Tuesday, 11 June 2013

Privacy, Data Collection and Surveillance



The privacy debate about the collection of data by the NSA continues with many asking questions about the moral and ethical issues surrounding this. The phrase "the death of privacy" is abound.
This is true I'm afraid, we lost our privacy, but not when the NSA starting collecting data but when we starting communicating using technologies that were readily and easily available - that probably dates back to the birth of written communication.

Data collection concerns me certainly, but here I want to focus on one of the maxims of privacy: "if you don'tuse it, don't collect it" and the fact that privacy is much more about the usage of data, not its collection (viz. the above maxim).

One can argue that merely using Google, Facebook and all the rest of the social media services one has already lost one's privacy, but interaction with these services is voluntary - no-one forced you to post those party pictures to the entire World and dog (complete with EXIF and location information). 

We admittedly do have a problem with other more hidden aspects of data collection and processing, for example with infrastructure and derived data.

In the above respects we have not lost privacy but moved the bounds of what personally and socially we call privacy – obviously people are not placing emphasis on the moral and ethical issues but rather on the economic benefit of using such data consuming services. In writing this blog I am losing my privacy, but with the economic gain of brand building and knowledge sharing.

Using this data consumers and users can be profiled and classified; typically for the serving of the perfect advertisement. However this is not unlike what an "old style shopkeeper" did through personally knowing his customers. The major difference is that today this is done automatically and impersonally by computer. We lost the link with that corner shop keeper who knew us and our families personally. Ever try contacting the customer service departments of practically any company these days?

This also touches on the point that users start or have started to feel that they are not in control of their data.

Most advertising and profiling companies are using classification structures that are fairly coarse grained but then further refined those with additional [coarse] grained data such as location and social network. This for the most part is nothing more than could be understood by reflecting on one's own life, place of abode and neighbourhood. For the most part this is just reasserting what is already derivable from a person’s postcode.

Much of the data collected by the NSA in the current revelations is somewhat innocuous; primarily this seems to be just telephone record meta-data like the kind you see on an itemized bill. But such innocuous data can easily be cross-referenced and fingerprinted.

The trouble here is that government authorities can have a more insidious effect upon a person's life than a supermarket or credit card provider can. Indeed there are safe guards and protections through the rule of law - though as we have seen these can be constructed so that under some circumstances the law can allow whatever is necessary to get a/the job done.

Before however we dismiss the above, consider two points:

  1. automatic guilt, or, guilty until proven innocent
  2. scope creep

The first derives from the fact that all your actions may be used against you in the future. If you think you have nothing to hide then consider all the crimes you committed today? Did you drive over the speed limit, run a red light, have you ever stolen something/anything etc?

The second derives from the first that once you have this information then it could be used for purposes well beyond its original intent. Worse are the twin possibilities of false positives and false negatives. Consider councils in the UK using CCTV cameras originally intended to catch terrorists and prevent crime (in general) for catching dog owners not cleaning up after their dogs.

From the above the moral and ethical arguments are easily fashioned, the economic arguments are much more difficult and vary depending upon the context and our view of what society should be:

  • Is personal freedom, privacy and liberty greater than that of society's?
  • Is mass surveillance better than letting one "terrorist" commit an act of atrocity?

These questions however go right to the heart of the definitions of freedom, liberty, privacy, security, society and our own control over our own data. I don't think any of us even remotely comprehend the repercussions and difficulties of even trying to address, let alone answer such questions. 

But until we start having this debate in an impartial, focused and formal manner with the terms and definitions clearly stated, judging and/or condemning any form of data collection and any form of processing and usage of data is not going to be possible in any meaningful, lasting manner.

In another way we're back to a question posted by a group of mathematicians regarding the esoteric nature of things as we move away from the fundamental building blocks, and losing sight of what those building blocks [of society and humanity] actually mean.

Whether the NSA and everyone else's collection of data is right or wrong I can't answer, but the debate about what privacy actually is and our relationship personally and as a society with the concepts of privacy, security and trust is going to be an extremely interesting debate with wide repercussions.

Wednesday, 29 May 2013

A Paper.li publication

Paper.li offer an interesting service collecting articles based on keywords (and probably some analytics too), here's mine concentrating on privacy:


Quite useful plus it acts as a collection point for Twitter users.

Tuesday, 6 November 2012

Inherent Privacy

I've long had a suspicion that when building information systems and specifically when reviewing and auditing such systems that the techniques that need to be used and developed are effectively the very same tools and techniques that are used in the construction of safety-critical and fault tolerant systems.

As privacy is fast becoming the number one issue (if it isn't already) with regards to consumers' data, the amount of effort in consumer advocacy and legal aspects is outstripping the ability of the technical community to keep up with the required architectures, platforms, design, implementation and techniques for achieving this. Indeed there is some kind of arms race going on here and I'm not sure it really is in the benefit of the consumer.

For example, the Do Not Track technical community has come under criticism for not delivering a complete solution. I don't think this really is 100% the fault of the W3C or the good people developing these standards but rather the lack of
  1. understanding information systems (even in the theoretical sense) and 
  2. a lack of applicable and relevant tools and techniques for the software engineering community who at the end of the day are the ones who will end up writing the code that implements the legal directives in some for or other. But we digress.
Performing a little research we come across the term "Inherent Safety" (see [3]), defined:
Inherent safety is a concept particularly used in the chemical and process industries. An inherently safe process has a low level of danger even if things go wrong. It is used in contrast to safe systems where a high degree of hazard is controlled by protective systems. It should not be confused with intrinsic safety which is a particular technology for electrical systems in potentially flammable atmospheres. As perfect safety cannot be achieved, common practice is to talk about inherently safer design. “An inherently safer design is one that avoids hazards instead of controlling them, particularly by reducing the amount of hazardous material and the number of hazardous operations in the plant [3].

Taking this as a starting place I decided to have a go at rewriting the principles in the privacy contenxt as below - taking the extensions as proposed in [4] into consideration:

  • Minimize: reducing the amount of information/data present at any one time either in local storage, remote storage cache or network transfer
  • Substitute: replace one element of data with another of less privacy risk, eg: abstract GPS coordinates to city areas
  • Moderate: reduce the strength of a process to transform or analyse data, eg: reduce the amount of crossreferencing over a number of sets of data
  • Simplify: reduce the complexity of processes to control data, eg: single opt-out, one-time consent, simple questions (and not asking the user what resources an app should have access too..)
  • Error Tolerance: design the system/software and processes to deal with worst cases, eg: misbehaving applications sending too much data are blocked in some sense
  • Limit Effects: designing the system such that the effects of any leak of data is minimised, eg: properly anonymised or pseduo-anonymised data sets, secure transport layers, encryption etc

While admittedly not fully worked out I feel that this is more communicable and understandable to the software engineers that, say, Privacy by Design, which while lays out a good set of principles, is too high-level and abstract to map to the engineers and their day-to-day work. Actually I feel the problem with the Principles of Privacy by Design is that they can be (and are!) taken like the principles of the Agile Manifesto leading to some bizarre and extreme (and wrong!) ideas of what Agile Processes are - just take a look at some of the later writings of Ward Cunningham or Scott Ambler on the subject.

One aspect of the inherent safety idea that particularly appeals is that it is more grounded in engineering and practical development rather than being a set of principles. Indeed much of the grounding for this work comes from a very practical need and development through sound engineering practice espoused by Trevor Klenz. His quote "what you don't have, can't leak" applies equally to information as it does hazardous substances; Klentz's book [5] maybe should become required reading along with Solove and Nissenbaum.

As a further example, the HAZOP (Hazard and operability study) method(s) are purely formal methods in the true sense of the word in constructing a small, formally defined vocabulary and modelling standards - compare with process flow diagram in the chemical and process engineering with the data-flow diagram in software engineering for example.

I'd like to finish with a reference to HACCP (Hazard analysis and critical control points) which itself has a number of principles (seven seems to be a common number), but here's I'd like to concentrate for the moment on just two:

Principle 2: Identify critical control points. – A critical control point (CCP) is a point, step, or procedure in a food manufacturing process at which control can be applied and, as a result, a food safety hazard can be prevented, eliminated, or reduced to an acceptable level.

Where do we control the flow of information? Is it near the user or far from? Is it honour based and so on? The further from the source of the information, the greater the chance of leakage (both in information and chemical systems).

Principle 4: Establish critical control point monitoring requirements. – Monitoring activities are necessary to ensure that the process is under control at each critical control point. In the United States, the FSIS is requiring that each monitoring procedure and its frequency be listed in the HACCP plan.

This is something that I guess we're very bad with - do we ever monitor what information we keep in databases? Even the best intentions and best designs might still leak something, and this is especially true when working with large sets of information that can be cross referenced and fingerprinted. Maybe we should consider some kinds of information to be analogous to bacteria or viruses in a food handling situation?

So, just an example of from where we should be getting the basis for the tools and techniques and principles of really engineering for privacy. I stand by my assertion that in order to engineer information system correctly for privacy we must consider those systems to be safety-critical and treat them accordingly. I'll discuss counterarguments and how we get such techniques into our "agile" software engineering processes later.

References

[1] Stefan Kremp, European Commissioner concerned about "Do Not Track" standard, The H Open. 12 October 2012

[2] Claire Davenport, Tech standards body diluting Web privacy: EU official, Reuters, 10 October 2012

[3] Heikkilä, Anna-Mari. Inherent safety in process plant design. An index-based approach. Espoo 1999, Technical Research Centre of Finland, VTT Publications 384. ISBN 951-38-5371-3

[4] Khan, F. I. & Amoyette, P. R., (2003) Canadian Journal of Chemical Engineering vol 81 pp 2-16 How to make inherent safety practice a reality

[5] Kletz, T. A., (1991) Plant Design for Safety – A User-Friendly Approach, Hemisphere, New York

Thursday, 27 September 2012

Teaching Privacy

It often surprises me that many of the people advocating privacy don't actually understand the things that they're trying to keep private, specifically information. Indeed the terms data and information are used interchangeably and there is often little understanding of the actual nature and semantics of said, data and information.

I've run courses on data modelling, formal methods, systems design, semantics and now privacy - the latter however always seems to be "a taster or privacy" or "brief introduction to privacy" and there rarely is the chance to get into specifics about what information is.

This of course has some serious implications and one of the best I can find is when we talk about anonymisation. I've seen horrors such as statements "if you hash this identifier, then it is anonymous" or "if we randomise this data then we can't track" or lately, "if we set this flag to '1' then no-one will track you anymore". In the first case I refer people back to the AOL Data Leak and the dangers of fingerprinting, semantic analysis and simple cross-referencing.

I made a study a while back based on the leak of 16,000 names from various Finnish education organisations (plus maybe other places). It was very interesting to see that even with the released list that contained dates of birth and last names how many were already unique, and even in the cases where there existed common Finnish names how easy it was to trace these back to a unique person. Actually going to the next step and verifying this with that person would I guess have been somewhat illegal or if not, unethical to say the least. Social engineering would have been very easy in many of these cases I'm sure.

So given cases like these and the current dearth of educational material I though it would be nice to try to put together a more comprehensive and deeper set of material. Some universities are already doing this and there also exist industrial qualifications such as those by the IAPP, however at this stage all ideas are welcome.

Now I want to specifically address a technical audience: software engineers, computer scientists - the people who end up building these systems because that's where I feel much breaks down - for many reasons but I won't appoint blame here - that's not really constructive in the current context.

First of all I want to break things down into 3 logical segments, actually there are 4 but I'll discuss that one later:
  • Legal
  • Consumer Advocacy
  • Technical
 and address each area individually.

Legal is relatively straightforward in that an understanding of principles of privacy, how various jurisdictions view data, information, anonymisation, cross-referencing, children and minors, cross-border data transfer, retention and data collection and a discussion of certain practices, eg: EU, US, China, India etc. This discussion doesn't have to be heavy but an understanding of what the law states and how it interprets things is critical. Also from here we should get an understanding of how the law affects the engineering side of things: common terminology as a good example.

Consumer advocacy is really the overview material in my opinion - what are the principles of privacy, for example Cavoukian's Privacy by Design as an example (even if I'm not happy with the implementation of these), how to consumers view privacy, what is the reality (say vs do) and also various case studies such as how consumers view Google, Apple, Nokia, Facebook, various Governments, technologies such as NFC, mobile devices, 'Smart Televisions', direct marketing and advertising, store cards etc. Out of this comes an understanding of how privacy is viewed and even an appreciation of why we don't get privacy: anti-privacy if you like.

The technical aspect takes in many technologies, rather than describe, I'll list them (and this will be non-exhaustive and in no particular order)
  • Basic Security - Web, Encryption, Hashing, Hacking (XSS etc), authentication (OpenID, OAuth etc), differences/commonalities between privacy and security, mapping privacy problems into security problems as a solution
  • Databases - technologies, design, schema development (eg: relational theory), "schema-less" databases, cross-referencing, semantic isolation
  • Semantics - ontologies, classifications, aspect, Semantic Web
  • Data-flow
  • Distributed Systems - networking and infrastructure
  • API design - browsers, apps, web-interfaces, REST
  • Data Collection - primary vs secondary vs infrastructure, logging
  • Policy - policy languages, logic, rules, data filtering
  • Anonymisation - data cleansing
  • Identifiers - tracking, "Do Not Track"
  • User-Interface
  • Metrics for privacy - entropy
  • Information Types and Classification - location, personally identifiable information, identifiers, PCI, health/medical data
as you can see the list is extensive and an understanding of each of these areas is critical to building systems that honour and preserve privacy in its various forms (as described in the consumer advocacy and legal sections). The main point here is to provide software engineers and computer scientists with the tools to implement privacy in a meaningful manner.

Now that we have outlined the three areas we can look at the fourth which binds these together and which I tentatively call "Theory of Privacy".

Obviously something binds these areas together and there does exist a huge body of work on the nature of information and its classifications. I particularly like the approach by Barwise and Seligman in the 1997 book Information Flow: The Logic of Distributed Systems*. I believe we can quite easily get into all sorts of interesting ontology, semantics and even semiotic discussions. Shannon's Information Theory and notions of entropy (eg: Volkstein's book: Entropy and Information) are fundamental to many things. I think this really is an area that needs to be opened up and addressed seriously and anything that binds together and provides a common language to unify consumer advocacy, the law and software engineering is critical.

Finally, no outline of a course would be complete with some preliminary requirements and a book list. For the former an understanding of computer systems and basic computer security is a must (there is no privacy without security), a grounding in software engineering techniques and a dose of computer science similarly. For the books, my first draft list would include:
  • Barwise, Seligman. Information Flow
  • O'Hara, Shadbolt. The Spy in the Coffee Machine: The End of Privacy as We Know It
  • Solove. Understanding Privacy
  • Nissenbaum. Privacy in Content: Technology, Policy, and the Integrity of Social Life
  • Solove: The Future of Reputation: Gossip, Rumour, and Privacy on the Internet

*somebody should make a movie of this.

Wednesday, 2 May 2012

International Journal on Advances in Intelligent Systems

I'm on the editorial board of the IARIA International Journal on Advances in Intelligent Systems




The journal is dedicated to specific topics related to automation, static and mobile agents, decision systems, special computational paradigms, advances in computer-human interaction, human-oriented modeling, and human-centric service and applications.

Special issues can focus on particular aspects related to autonomic components and systems, advanced correlation algorithms, applications of artificial intelligence, adaptive and interactive interfaces, ubiquitous services, anticipative systems, unmanned systems, robotics, processing of distributed geospatial data, or context-oriented information retrieval and processing.

Editor-in-Chief: Freimut Bodendorf, University of Erlangen-Nuernberg, Germany
issn: 1942-2679


Tuesday, 17 April 2012

Privacy, Dataflow and Nissenbaum ... formalisation?

I read the article by Alexis Madrigal of The Atlantic about Helen Nissenbaum's approach to privacy. It is good to see someone talking about sharing of information as being good for privacy. Maybe this is one of the rare instances that the notion of privacy has been liberated from being all about hiding your data, protecting the "consumer" to actually, in my opinion, being about how data flows.

To quote from the article and given a good example:
This may sound simple, but it actually leads to different analyses of current privacy dilemmas and may suggest better ways of dealing with data on the Internet. A quick example: remember the hubbub over Google Street View in Europe? Germans, in particular, objected to the photo-taking cars. Many people, using the standard privacy paradigm, were like, "What's the problem? You're standing out in the street? It's public!" But Nissenbaum argues that the reason some people were upset is that reciprocity was a key part of the informational arrangement. If I'm out in the street, I can see who can see me, and know what's happening. If Google's car buzzes by, I haven't agreed to that encounter. Ergo, privacy violation.

First thing here is that Nissenbaum gets us past the privacy as a binary thing: its private or public where private means hidden. Nissenbaum actually promotes the idea of how we perceive the data flow rather than whether something is private or public; again quoting from the article:

Nissenbaum argues that the real problem "is the inapproproriateness of the flow of information due to the mediation of technology." In her scheme, there are senders and receivers of messages, who communicate different types of information with very specific expectations of how it will be used. Privacy violations occur not when too much data accumulates or people can't direct it, but when one of the receivers or transmission principles change. The key academic term is "context-relative informational norms." Bust a norm and people get upset. 

For a while I've been working on formalising architectures, ontologies, taxonomies and so on for privacy (privacy engineering) - the common factor in all of these is the data-flow. Actually I think some of this is quite simple when thought of in this manner, firstly we construct a simple data-flow model:



Aside: this is quite informal and the following just sketches out a line of thinking rather than being a definition.

Some information I flows from A to B. For this information I we can extract a number of aspects: sensitivity, information type, identity (amount of) etc. We can also ask the question of this particular interaction (A,I,B) of whether that information I is relevant to the particular set of transactions or services that B provides. If B requires a set of information H to work for fulfil the contract with A then I<=H in this case, which allows A to supply less but should discourage B asking for more.

We can also look at other factors in this to make that decision: the longevity of information in B, the ownership of the information once passed to B and importantly, whether B passes this information on - we come to this latter point later. Ultimately we can assign a weight to this data-flow, though what form of metric this is I don't have a good idea about at the moment but let's call it 'm', ie: a(I) is some measure of the 'amount of information' weighted by the various aspects and classifications. The above I<=H should then be rewritten as a(I)<=a(H) which better takes into account of the weightings of the information classifications.

This we can continue through a number of other flows and introduce a typing or taxonomic structure for the nodes:



As B is a bank then the amount of information required tends to be high, if C is on-line shop, then this tends to be lower and so on. Such a rule might be:

forall u:User, b:Bank, c:OnlineShop, d:NewsSite |
    a( u-->b ) => a( u-->c ) and
    a( u-->c ) => a( u-->d )
    ...

For each node, we can better describe the expectation in terms of this metric, ie: a(b) where b is the Bank node from above, we get the rule from earlier:

forall u:User, b:Bank |
    a( u-->b ) <= a(b)

Now our weighting function a deals with particular instances, where as we have stated that that there are expectation, so let's introduce a new function that computes a range for a given type, for example r(Bank) returns a range [ r_min, r_max ]. Then for a particular instance of Bank we get

forall b:Bank |
      r_min(Bank) <= a(b) <= r_max(Bank)

If a given instance, for example e in the above data-flow requires something outside the range for its type then we are "busting a norm" for that particular type, and following on from the above rules:


forall u:User, b:Bank |
      r_min(Bank) <= a(b) <= r_max(Bank)
         and
      a( u-->b ) <= a(b)


The next thing is to look at the next level in the data-flow graph, to where do B,C,D and E send their information, how much and how do these data-flows affect the first - I guess there's a very interesting feedback loop there. A few other things spring to mind as well: do we see a power law operating over the weighting of the data-flows? Does it matter to where and how much data flows?

Introduce a temporal dimension and plot the above over time and you get a picture of the change in norms and consumer expectations.

Getting back to Nissenbaum's thesis which is that the expectation of privacy over data-flows is the key and not whether the data-flows at all, I think we could reasonably model this.

Saturday, 31 December 2011

War on General Purpose Computing

Final post of the year probably and one to think about over the final hours of 2011 and wonder what will happen in 2012...

The Coming War on General Purpose Computation

At least in the mobile arena we've already seen a move from the "general purpose" web browser to paid applications which effectively act as front-ends to (often) freely available content.

Now as the presentation above points out this is partly because of a new revenue model not working in the customers' best interests but also because of the controls being placed upon consumers and users of content and devices. An extremely worrying trend where the distributors have final say over what YOU can read and consume - and at the same time monitoring your behaviour as part of the deal for you to consume that media and information.

Information which used to be free in the availability sense (and not necessarily in terms of price).

I used to joke that Apple said "There's an app for that" - one which already did the job of your perfectly good web browser but for a cost, while Nokia should have said, "You don't need an app for that" due to the presence of a web browser.

The advantage for Apple here is that you had to pay for both the application (to read your free content) but also submit yourself to behavioural data collection and provide numerous personal details for the priviage.

Happy 2012....




Wednesday, 23 November 2011

BBC Research and Development Labs

Very interesting article on The Register about the BBC's R&D Labs and a very good point about industrial-academic research and its value, I quote this paragraph:


Some may question why the BBC puts so much effort into R&D. But with around 50 active projects, and an income of around £16m, including money from the licence fee, commercial licensing – the BBC has over 160 patents – and grants, the R&D team punches well above its weight.


A very salient point: it costs £16m but generates not just patents and their associated licensing income but the technology that drives not only your current TV, Radio and digital media experiences (for a start!) but is defining the future of those. Sixteen million pounts is remarkably cheap for what you're getting which over the course of time is worth many, many times this.

Now with the EPSRC Research Impact Assessments comming up in the UK, this point needs to be hammered home regarding impact and value versus cost.