Privacy is framed in terms of ethical, moral and economic arguments. Certainly most research supports that nearly everyone is worried about their on-line privacy, yet rarely if at all we've seen a company actually fail because of their attitude to privacy. Some companies have changed their ways admittedly, but the change has been minimal and after the initial fuss it is very much business as usual. Privacy seems not to be much of an ethical or moral issue to most people but rather an emotional one.
Given the above we don't see much of an economic argument either, at least not from the end-user side of things. The economic argument for using certain social networking services, sharing personal photographs, details etc seems to outweigh the potential disadvantages - which tend to be worries about to where data is being shared or sold, or who might be viewing that material.
Privacy is rarely framed in terms of an economic argument beyond the "data mart" idea but rather in emotional terms: nothing to hide, nothing to fear perhaps? Privacy is lost in the security and liberty arguments too being equated with concealment and freedom. Consider the argument put forward by US congressman Paul Rand [1] on privacy.
Laws are changing to emphasise the economic argument to the companies that provide internet services and there we do see a strong argument for a more robust privacy function. Whether we on the business side of things are addressing privacy in the right manner and in the same economic terms as our end-users is another matter altogether. For companies the economic argument for developing and adhering to an information safety (privacy) is very clear. We have a good economic argument for treating end-users' information with respect...whatever that is.
For the end-user the economic argument is unclear. Why should an end-user choose one service provider over another? What are the terms of this economic argument and have they even been defined at all?
References
[1] Senator Rand Paul Talks Tech, Civil Liberties, and Keeping the Government Out of Your Email. By Spencer Ackerman 05.30.13 Wired
A collection of discussions, links, stories, news and whatever else I find interesting in the fields of computing, information, science, privacy, semantics, mathematics and so on...
Friday, 31 May 2013
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.
Quite useful plus it acts as a collection point for Twitter users.
Sunday, 12 May 2013
A basic information privacy programme
Using the material discussed earlier as our starting point we can construct the outline of an information privacy programme (IPP). First however we must place any IPP into juxtaposition with the units it will affect:
Note that any "IPP" can not rule nor dictate over any of the affected parties, it does however provide a point of contact and expertise for those parties when working with information. The enforcement aspects come from a number of other places which we'll discuss in another article.
We structure the IPP into two parts: the programme elements and the knowledge base, both of which we will introduce here.
The Programme Elements are:
The Information Distribution System is a mechanism by which privacy related topics can be communicated to interested parties outside of the IPP. Typically such information might be of the "interest" variety, eg: notification of new laws or relevant news articles, to the critical such as a notification of an information breach or threat which must be acted upon by any receiving parties.
The Privacy Committee is the one fraught with political difficulties, but a small (5-7 people) group from a cross-section of roles within the company. This is where many programmes fail because of placing management or non-technical staff here. The role of this group is not to manage the programme but to reivew incident/accident reports, review adequacy of corrective actions, hazard reviews, inspection reports, provide recommendations (based on information received via the reportins and information distribution systems) and to self-assess and improve the ways of working of the IPP as a whole. The committee is also the chance to bring onboard the expertise in the external parties from R&D, legal etc.
The Inspection Programme can cover many aspects, but is primarily concerned with auditing and providing mentoring/consultancy to external parties. Auditing usually takes place as part of the deployment cycle of a product for example. This area constitutes most likely the bulk of the work of the IPP.
Education and Training is always critical but often badly done (if at all). Developing relevant training for the external parties is critical to long-term success and accident avoidance.
Finally we get to Accident Preparation and Investigation. Hopefully data breach or similar incidents never happen, however having procedures to deal with these are critical to a good solution to any problem. Likewise, a good investigation procedure which not only traces down the causes but provides solutions is also critical.
This concludes the programme elements and now we move to the Knowledge Base which is where the tools, techniques, metrics and database for storing all of the required knowledge and wisdom for running the above element succesfully. We use the word "tool" in a loose sense - automation in any form might not be available, but things such as checklists or ontological structures/classifications are tools.
As a recommended minimum for databases: a database of relevant laws and implications (at an R&D level of detail), a database of reported risks and a database of investigation findings and so on.
All this is just an overview - specific companies, specific situations require customisation and we still have not discussed in any detail the content of the knowledge base nor programme elements let alone presented particular roles such as that of the privacy officer etc. What however should be clear is that a structuring is necessary and what have presented here summaries some of the best practices from an area that is already well versed with similar issues, that of aviation safety. [1]
References
[1] Wood R. (1997) Aviation Safety Programs. 2nd edn. Jeppesen.
Note that any "IPP" can not rule nor dictate over any of the affected parties, it does however provide a point of contact and expertise for those parties when working with information. The enforcement aspects come from a number of other places which we'll discuss in another article.
We structure the IPP into two parts: the programme elements and the knowledge base, both of which we will introduce here.
The Programme Elements are:
- A Reporting System
- An Information Distribution System
- A Privacy Committee
- An Inspection Programme
- Education and Training
- Accident Preparation and Investigation
The Information Distribution System is a mechanism by which privacy related topics can be communicated to interested parties outside of the IPP. Typically such information might be of the "interest" variety, eg: notification of new laws or relevant news articles, to the critical such as a notification of an information breach or threat which must be acted upon by any receiving parties.
The Privacy Committee is the one fraught with political difficulties, but a small (5-7 people) group from a cross-section of roles within the company. This is where many programmes fail because of placing management or non-technical staff here. The role of this group is not to manage the programme but to reivew incident/accident reports, review adequacy of corrective actions, hazard reviews, inspection reports, provide recommendations (based on information received via the reportins and information distribution systems) and to self-assess and improve the ways of working of the IPP as a whole. The committee is also the chance to bring onboard the expertise in the external parties from R&D, legal etc.
The Inspection Programme can cover many aspects, but is primarily concerned with auditing and providing mentoring/consultancy to external parties. Auditing usually takes place as part of the deployment cycle of a product for example. This area constitutes most likely the bulk of the work of the IPP.
Education and Training is always critical but often badly done (if at all). Developing relevant training for the external parties is critical to long-term success and accident avoidance.
Finally we get to Accident Preparation and Investigation. Hopefully data breach or similar incidents never happen, however having procedures to deal with these are critical to a good solution to any problem. Likewise, a good investigation procedure which not only traces down the causes but provides solutions is also critical.
This concludes the programme elements and now we move to the Knowledge Base which is where the tools, techniques, metrics and database for storing all of the required knowledge and wisdom for running the above element succesfully. We use the word "tool" in a loose sense - automation in any form might not be available, but things such as checklists or ontological structures/classifications are tools.
As a recommended minimum for databases: a database of relevant laws and implications (at an R&D level of detail), a database of reported risks and a database of investigation findings and so on.
All this is just an overview - specific companies, specific situations require customisation and we still have not discussed in any detail the content of the knowledge base nor programme elements let alone presented particular roles such as that of the privacy officer etc. What however should be clear is that a structuring is necessary and what have presented here summaries some of the best practices from an area that is already well versed with similar issues, that of aviation safety. [1]
References
[1] Wood R. (1997) Aviation Safety Programs. 2nd edn. Jeppesen.
Saturday, 11 May 2013
Topology, the periodic table and parasites
hree very interesting websites to amuse you. The first a homage to topology or as the author puts it:
and applying various rules we can get beauties such as this below using the rule "n18n18n9n9n9soxO" in the notation used on the site:
The second is the every popular Element of the Week via the The Guardian newspaper. A fun introduction of the basic building blocks of chemistry and each week a new element. This week, the famous and well known element: astatine .
I recommend you check out caesium, rubidium, potassium and sodium for the sheer fun of watching those being dropped into water and reacting violently. Such experiments are now banned from schools for safety reasons, along with many other aspects of science unfortunately...
Failing that there's the Royal Society of Chemistry's Visual Elements Period Table which is great fun.
And finally, for the squeamish of you stop reading now, for the less squeamish its probably best to avoid mealtimes, but this is great:
Introducing a new beast more or less regularly (if not every day). To understand this site you can read their introduction which helpfully has no pictures to put you off your food.
"This is a toy for building complex 3D polyhedral shapes from simple ones by "recipes"polyHédronisme allows you to construct various polyhedral shapes (only 3 dimensions though!) by composing rules over various bases, for example starting with a plain octahedron
The second is the every popular Element of the Week via the The Guardian newspaper. A fun introduction of the basic building blocks of chemistry and each week a new element. This week, the famous and well known element: astatine .
I recommend you check out caesium, rubidium, potassium and sodium for the sheer fun of watching those being dropped into water and reacting violently. Such experiments are now banned from schools for safety reasons, along with many other aspects of science unfortunately...
Failing that there's the Royal Society of Chemistry's Visual Elements Period Table which is great fun.
And finally, for the squeamish of you stop reading now, for the less squeamish its probably best to avoid mealtimes, but this is great:
Parasite of the Day!
Introducing a new beast more or less regularly (if not every day). To understand this site you can read their introduction which helpfully has no pictures to put you off your food.
Friday, 10 May 2013
Privacy learning from aviation safety...
I've written before on my thoughts, or belief, that information should be treated as a dangerous chemical, or a patient undergoing surgery:
Developing ideas such as checklists from aviation, surgery etc, do improve the quality of work and actually implementing those has been a very interesting experience - if anyone wants to learn about this let me know, I'm very happy to talk about it.
Now while we have some parts of the "coalface work" working, ie: the real privacy engineering work with real software engineers, software architects, programmers and code, we can now turn to reassess how we're managing privacy and in turn managing risk and improving the safety of our code, products, business and ultimately our customers from a privacy perspective.
One area that has succeeded very well is aviation - our original starting point for much of this safety discussion. Indeed aviation safety precedes most other safety programmes by decades. I'd like then to quote from the book Aviation Safety Programs (Richard Wood, 2nd edn 1997, Jeppesen):
Now simply replace "safety" by "privacy":
Interesting don't you think? Ah, yes, we know it is an economic problem and it certainly is being mandated by government. Adopting something like Privacy by Design today will not change the quality of your product or relationship with your customers. You'll get some sympathy but ultimately does anything change? There's an outcry every time Facebook changes it privacy policies but people still post private information there; similarly with Google and the rest. Privacy is talked about in moral and ethical terms: building trust with the customer.
Despite of everything, Facebook hasn't lost 50%, 90% or even 1% of its customer base because of its perceived "anti-privacy" stance, and neither has Google, nor any other company I can think of. Privacy must be framed as an economic argument: if company X abuses their consumer data privacy, then they lose all their customers and business.
We've a lot to learn from a successful safety program and that's something I'm going to write about more in the coming days and weeks. How do we put a privacy programme together such that it really does economically benefit a company and addresses all the cross-cutting issues from the top management through to the programmer actually writing the code that runs the business?
First things first though, when constructing such a programme, we need a group of people to lead the privacy culture within a company and that team needs day-to-day experience close to coalface, they need knowledge of not just the moral and ethical aspects but of real scientific and engineering experience. Starting with that we might just really see where the economics benefits are won and lost.
privacy is a safety critical concern
Developing ideas such as checklists from aviation, surgery etc, do improve the quality of work and actually implementing those has been a very interesting experience - if anyone wants to learn about this let me know, I'm very happy to talk about it.
Now while we have some parts of the "coalface work" working, ie: the real privacy engineering work with real software engineers, software architects, programmers and code, we can now turn to reassess how we're managing privacy and in turn managing risk and improving the safety of our code, products, business and ultimately our customers from a privacy perspective.
One area that has succeeded very well is aviation - our original starting point for much of this safety discussion. Indeed aviation safety precedes most other safety programmes by decades. I'd like then to quote from the book Aviation Safety Programs (Richard Wood, 2nd edn 1997, Jeppesen):
Safety is not a moral problem or an ethical problem or a pain and suffering problem. It is an economic problem. Safety, by itself, generates a lot of sympathy, but very little action. Only the economics of safety generate action. In the entire history of safety, nothing good happened unless it was either economically beneficial or mandated by government.
Now simply replace "safety" by "privacy":
Privacy is not a moral problem or an ethical problem or a pain and suffering problem. It is an economic problem. Privacy, by itself, generates a lot of sympathy, but very little action. Only the economics of privacy generate action. In the entire history of privacy, nothing good happened unless it was either economically beneficial or mandated by government.
Interesting don't you think? Ah, yes, we know it is an economic problem and it certainly is being mandated by government. Adopting something like Privacy by Design today will not change the quality of your product or relationship with your customers. You'll get some sympathy but ultimately does anything change? There's an outcry every time Facebook changes it privacy policies but people still post private information there; similarly with Google and the rest. Privacy is talked about in moral and ethical terms: building trust with the customer.
Despite of everything, Facebook hasn't lost 50%, 90% or even 1% of its customer base because of its perceived "anti-privacy" stance, and neither has Google, nor any other company I can think of. Privacy must be framed as an economic argument: if company X abuses their consumer data privacy, then they lose all their customers and business.
We've a lot to learn from a successful safety program and that's something I'm going to write about more in the coming days and weeks. How do we put a privacy programme together such that it really does economically benefit a company and addresses all the cross-cutting issues from the top management through to the programmer actually writing the code that runs the business?
First things first though, when constructing such a programme, we need a group of people to lead the privacy culture within a company and that team needs day-to-day experience close to coalface, they need knowledge of not just the moral and ethical aspects but of real scientific and engineering experience. Starting with that we might just really see where the economics benefits are won and lost.
Thursday, 9 May 2013
Foundations of Applied Mathematics
Via the n-Category Cafe blog I noticed a real gem in the workshop on The Foundations of Applied Mathematics. Simplifying systems and trying to understand the foundations of things (information systems, software engineering, privacy) is of great interest to me.
For example, in my current area of information system privacy we have a huge problem in even contemplating what the foundation of the discipline looks like, let alone trying to formalise it (and it probably has a lot to do with entropy, semantics, measurement theory and information flow if you ask me - but before we get there we've a lot of other work to do).
The particular piece of work that interested me was by John Baez who has a history of work trying to unify various areas of mathematics ostensibly through category theory and his presentation entitled The Foundations of Applied Mathematics (slides) presents his work on applying these ideas to applied mathematics. This was also followed up by an interesting discussion on Google+.
The whole presentation and body of work starts to remind me of a few things
I'd have to answer 'yes' to this if only to assert the position that if the lower layers have not been correctly formulated or established and can not support the upper layers in their needs then the above is inevitable.
The reasoning for this comes from, at least in my chosen area of software engineering, is that layers [of software] are often constructed without any reference to any other layers, the operations and structures in those layers are not "atomic" or fundamental in nature with respect to that layer and the separation of concerns and layering of architecture is often a matter personal choice. Layers are often polluted with convenience functions and particular architectural choices, see Anti Patterns.
Another way of looking at this is via a famous xkcd cartoon on the relationship between Lisp, Diety and how it was really built:
Maybe it just is that the foundations aren't bad at all, just that we got the layering wrong. Maybe mathematics isn't layered at all...object oriented anyone?
Further in the Google+ discussion started by Baez, a posting by Carsten Führmann quoted Von Neumann:
The quotation continues but the gist is that the further a discipline goes away from its foundations the more esoteric it becomes. I think in software engineering we see this quite clearly with things like use case modelling and agile methods. Not that there's much wrong with either but their current application is often far from the ideals proposed by their creators.These then get use to develop the architectural layers seen earlier.
In information system privacy we do not have a clear, coherent understanding of the foundations of the discipline and yet we are developing at very high levels of abstraction concepts, laws, ideas without understanding how these are to be architected into the technologies we are building. Contemplate the semantic gap between the European Privacy Directive and the actual C++ (or whatever) code that implements those. I'm not saying that laws, directives etc are wrong, just that even simple ideas such a Do Not Track will expose huge holes in our understanding of the discipline of privacy (and a lot of related subjects too). Actually I think that DNT won't work in its current form because too fee people do not want to address the formalisation of privacy but remain at some esoteric level far removed from what DNT is trying to address and that might have other implications and Von Neumannesque danger signals.
I won't discuss visualisation here, that's for another time, but just to reference the work at the University of Brighton on diagrammatic notation and also to refer to another point in Baez's presentation on the use of diagrams across disciplines (and layers of science) to express concepts to different audiences...presenting Euler diagrams to lawyers, marking people etc is an extremely interesting experience, especially when - as "non-mathematicians" - they start interacting using those notations and at some level we've "accidentally" unified the languages mathematicians and lawyers....
For example, in my current area of information system privacy we have a huge problem in even contemplating what the foundation of the discipline looks like, let alone trying to formalise it (and it probably has a lot to do with entropy, semantics, measurement theory and information flow if you ask me - but before we get there we've a lot of other work to do).
The particular piece of work that interested me was by John Baez who has a history of work trying to unify various areas of mathematics ostensibly through category theory and his presentation entitled The Foundations of Applied Mathematics (slides) presents his work on applying these ideas to applied mathematics. This was also followed up by an interesting discussion on Google+.
The whole presentation and body of work starts to remind me of a few things
- layered architecture
- esoteric models of understanding (- need a better way of explaining this!)
- visualisation (= diagrams)
"Can developments in applied mathematics force changes in the foundations of mathematics?"
I'd have to answer 'yes' to this if only to assert the position that if the lower layers have not been correctly formulated or established and can not support the upper layers in their needs then the above is inevitable.
The reasoning for this comes from, at least in my chosen area of software engineering, is that layers [of software] are often constructed without any reference to any other layers, the operations and structures in those layers are not "atomic" or fundamental in nature with respect to that layer and the separation of concerns and layering of architecture is often a matter personal choice. Layers are often polluted with convenience functions and particular architectural choices, see Anti Patterns.
Another way of looking at this is via a famous xkcd cartoon on the relationship between Lisp, Diety and how it was really built:
Maybe it just is that the foundations aren't bad at all, just that we got the layering wrong. Maybe mathematics isn't layered at all...object oriented anyone?
Further in the Google+ discussion started by Baez, a posting by Carsten Führmann quoted Von Neumann:
"As a mathematical discipline travels far from its empirical source, or still more, if it is a second and third generation only indirectly inspired from ideas coming from 'reality', it is beset with very grave dangers...."
The quotation continues but the gist is that the further a discipline goes away from its foundations the more esoteric it becomes. I think in software engineering we see this quite clearly with things like use case modelling and agile methods. Not that there's much wrong with either but their current application is often far from the ideals proposed by their creators.These then get use to develop the architectural layers seen earlier.
In information system privacy we do not have a clear, coherent understanding of the foundations of the discipline and yet we are developing at very high levels of abstraction concepts, laws, ideas without understanding how these are to be architected into the technologies we are building. Contemplate the semantic gap between the European Privacy Directive and the actual C++ (or whatever) code that implements those. I'm not saying that laws, directives etc are wrong, just that even simple ideas such a Do Not Track will expose huge holes in our understanding of the discipline of privacy (and a lot of related subjects too). Actually I think that DNT won't work in its current form because too fee people do not want to address the formalisation of privacy but remain at some esoteric level far removed from what DNT is trying to address and that might have other implications and Von Neumannesque danger signals.
I won't discuss visualisation here, that's for another time, but just to reference the work at the University of Brighton on diagrammatic notation and also to refer to another point in Baez's presentation on the use of diagrams across disciplines (and layers of science) to express concepts to different audiences...presenting Euler diagrams to lawyers, marking people etc is an extremely interesting experience, especially when - as "non-mathematicians" - they start interacting using those notations and at some level we've "accidentally" unified the languages mathematicians and lawyers....
Subscribe to:
Posts (Atom)