Helsinki Times interview on Privacy

I was interviewed by Helsinki Times for a short article on privacy, here's the first paragraph and link:

OnLine Privacy
3 May 2012, David Cord

Helsinki Times talks to Ian Oliver at Nokia Location & Commerce about staying safe online.

FOR over two years, Ian Oliver has been the principal architect of Privacy and Policy at Nokia Location & Commerce. His main job is on the technical side of privacy, as well as working with the company’s legal and consumer advocacy teams. He took the time to share some of his personal views about online privacy.

 

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

A month in space

The Guardian runs a series (actually various series) on science topics, the series "A Month in Space" this month has a set of simply stunning pictures. Alas I can't link to the pictures, but I can link to the article:

A month in space: A Martian dust devil, Milky Way bubbles and a star trek navigational aid – in pictures

This month's roundup of some of the best space-related images includes a dust devil and its shadow on the surface of Mars, some of the cosmic bubbles spotted by 35,000 citizen scientists, and a new navigational technique for starships exploring the final frontier

Eric Hilaire and James Kingsland  Friday 20 April 2012 19.04 BST

As for other series, there's an excellent one working through the Periodic Table of the Elements...this month, that most well known of elements: Praseodymium.

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.

LoD 2012: Layout of Diagrams 2012

LOD 2012

3rd International Workshop on Layout of Diagrams 

Diagrams are an effective means of conveying a wide variety of different sources of information. They play a vital role in communication at many levels, and the quality of diagram layout effects the ease of communication. Creating task-adequate layouts is surprisingly difficult, and the cognitive factors involved are often not very well understood. The automatic generation of diagrams is essential for many tasks such as the presentation of multiple views of large scale data sets. In many domains, tool support is not satisfactory. The workshop aims to bring together different communities that can learn from each other, both within different academic disciplines and between academia and industry.
We solicit original submissions related to diagram layout, in areas including, but not limited to, the following areas:

• Layout algorithms ;
• Layout design styles, guidelines and patterns;
• Automatic diagram generation and transformation techniques;
• Visual language theory (e.g. quality metric development) ;
• Visualisation of constraints, algorithms, and tools;
• Cognitive or empirical research on diagram layout;
• Diagram layout for diagrammatic reasoning, knowledge representation, etc;
• Application areas (e.g. system modelling, ontology visualisation, etc, with an emphasis on layout requirements and benefits).

All diagram types fall within the scope of the workshop series (e.g. graphs, hypergraphs, Euler diagrams, maps, knot diagrams, etc). Of particular interest is research and techniques that may encourage interaction and knowledge transfer between fields. However, for this instalment of the workshop series, we particularly encourage submissions that have a software engineering orientation (e.g. those within UML, IDEF or ARIS), building on the success of two previous workshops at VL/HCC on the Layout of Software Engineering Diagrams (LED).

The proceedings of this workshop will be published in the journal of Electronic Communications of the EASST (TBC). All papers must conform to the ECEASST format. All papers must be submitted electronically in the PDF format via the EasyChair submission system. Each submission will be reviewed by 3 reviewers, as usual.

The intention is that after the workshop the authors of the best papers will be invited to submit a revised and significantly extended version of their article to a special issue of a sutiable journal (e.g. Journal of Visual Languages and Computing or the journal of Software and Systems Modeling).

Important Dates

• Abstract Submission: June 11th, 2012
• Paper Submission: June 18th, 2012
• Notification to Authors: August 8th, 2012
• Camera Ready Submission: August 30th, 2012
• Workshop Dates: Oct 4th, 2012

 

 

Software Documentation and Formality

An article linked via Slashdot about using documentation as a bug finding tool [1] gets me wondering about why documentation is so neglected. There are of course many, well researched and known reasons but a common theme I keep seeing is that documentation implies a degree of formality, ie: the necessity to describe something accurately.

This in addition with the fact that documentation tends to be very static and the antithesis of agile methods which concentrate on the code rather than the documents.

But maybe here is one issue that does need to be actively tackled and that is firstly, code is part of the documentation and secondly the documentation necessarily contains more than the code. Keeping these various aspects consistent is, of course hard - exceedingly so given that the underlying model that does link the various levels of description and abstraction together is never visible. The underlying model implies a formal definition of how documentation relates to code.

So far I've just managed to describe some of the ideas of the Model driven Architecture which apart from some academic work never really succeeded in solving the documentation-code issue. Probably the best example I've seen is the B-Method which does make the link between various descriptions of a system clear through formal refinement, albeit in the same language and with a very well-defined underlying model.

But what is it that we're really trying to convey using "documentation" - is it really an abstract description of the code, or better still an abstract description of what the system does, which then the code is a refinement of?

And at what level of abstraction?

[1] Documentation as a Bug-Finding Tool April 11, 2012 | Eric

Visual Modelling Group @ Brighton

Just a quick plug for the Visual Modelling Group at the University of Brighton:

The group’s work focuses on visual languages, often developing tool support alongside defining their theoretical underpinnings.

One of the group's main strands of research is designing new diagrammatic logics that are appropriate for practical application. These logics have included spider diagrams, constraint diagrams and, most recently, concept diagrams. In all cases, these logics have formally defined syntax and semantics and we have developed inference rules that allow sound reasoning to be performed. The group has also established expressiveness, decidability and completeness results for some of these logics and their fragments.

In terms of tool support, the group has devised novel automatic drawing and layout techniques for Euler diagrams. These diagrams are commonly used for visualizing information concerning grouped data. Automated theorem provers have been implemented for Euler diagrams and spider diagrams.

And a link to an impressive set of papers on the subject:

Chemicals

Digging through my photograph collection I came across these that I took last year in a science exhibition - I guess primarily aimed at children. Crap (I wanted to use a stronger word) like this has no place in either a science exhibition nor, for that matter, in any place being aimed at anything remotely human.

The photos are of a computer screen which was part of a quiz for children on food. They're in Finnish but I'll provide the translation. Here's the question:

Knowledge Quiz:


Compared to "normal food", "natural food" ...

1. Contains less fat and sweeteners
2. Contains no chemicals and genetic manipulations
3. Is produced in the countryside

And the answer is....

Natural food contains...no chemicals.

The next question should be then what is it made of?  Pure energy? Some exotic matter? Maybe that's where all the dark matter in the Universe is....natural food.

The UK's Royal Society of Chemistry is offering a £1000000 (UK pounds) prize for anyone who creates a "chemical free" material. I guess no-one at that particular science museum has claimed the prize, which basically means they're either lying or stupid.

Here's a quote from the RSC:

Dr Neville Reed, a director of the RSC, said today: "I'd be happy to give a million pounds to the first member of the public who could place in my hands any material I consider 100% chemical free. 

"Should anyone do this, we will see thousands of years' worth of knowledge evaporate before our eyes. We would have to tear up the textbooks, burn the degree certificates and retrain the teachers."

One of the major constituents of any food-stuff is water...you know that chemical H2O, sometimes known as dihydrogen monoxide...not to mention those other nasty chemicals such as sodium chloride, or L-ascorbic acid, or any of the myriad of carbon based chemicals...

Some might say that this only applies to "man-made" or "bad chemicals"...so what constitutes a "bad chemical" or even a "natural chemical"...well, plenty of interesting poisons exist in nature including cyanides and many, many radioactive materials too, so that can't be the definition.

Dihydrogen monoxide incidentally was the subject of many hoaxes based on a complete misunderstanding of what chemistry, chemicals and a basic knowledge of science.

I remember an advert on TV for some cosmetic product which contained only natural chemicals which must be "good"...natural chemicals such as I've already stated...such as cyanides naturally found in almonds and apple seeds.

So, anyone who states that something is "chemical free" is stupid, deranged and plain wrong. In fact, anyone who states such a thing in a science context should be...I'll let you decide on a suitable punishment...maybe something nasty such as not allowing them access to that most evil of bad chemicals: dihydrogen monoxide. This kind of crap has no place in a science exhibit, in childrens' education or in society in general  - only bad things will come of this if this kind of nonsense is let to continue.

ps: I did ask a member of staff at the science museum about this - she had no answer other than it must be true otherwise they wouldn't have had such an exhibit...oh dear...

More ballet and software engineering

Sometimes a quick search using some popular search engines reveals people with similar ideas, in this case about ballet and software engineering: on the IBM Developer Works site is an article dated from 2005 by someone called "gbooch"*:

Software architecture, software engineering, and Renaissance Jazz

which mentions the link between software architecture and dance:

"It seems to me that there's a curious relationship between dance and software architecture: in both disciplines, there are only a limited number of patterns available, each genre assembles those patterns in specific ways that define a particular genre, and furthermore, most knowledge is passed on through tribal memory, from one dancer or architect to another. In dance, by the way, some attempts have been made to define a graphical notation for describing dance movements, just as we have the UML for visualizing, specifying, constructing, and documenting software-intensive systems."

Exactly...!

*I guess if the mysterious "gbooch" thinks this then I'm in good company.

Then there's another post on Techtalk: If Software Were Like Ballet which lists a number of points, the first of which is:

• Little kids are encouraged to get used to the equipment and basic practices.  Even if they don't actually do these things they are told about build and release cycles, software qa, and algorithms.

Now I don't agree with some things said in that posting, but certainly the above at least in terms of encouraged to use the correct equipment, techniques and basic practices is apt.

The Ballet-Software Engineering "Isomorphism"

A grand title for some thoughts. After watching a dance show involving various styles of dance etc a thought struck me on some interesting parallels I see between dance and the practice of software engineering. I guess this comes from reading things such as Baez and Stay's "Physics, Topology, Logic and Computation: A Rosetta Stone" - a paper describing the links between various scientific disciplines, ostensibly through category theory.

As I and many others have stated before the key to good software engineering (and thus great software) is an understanding and use of the core, formal theories of computer science - I consider software engineering to be a sub-discipline of computer science (and in turn mathematics). Why should this be so? Simply because of understanding how each of the parts of a piece of software interact and an appreciation of the complexity and need for elegance and simplicity in this.

So what has this got to do with ballet? Comparing modern dance with ballet and the dancers performing their routines I noticed the approach to the task was in most cases different - there is an interesting exception which I'll get to later. The difference was in the execution, fluidity and attitude to the performance: how accurate the moves were being performed individually and collectively as a group. An interesting point I thought was that you could recognise the really talented dancers by how they looked at each other and the audience.

Modern dance seems to be (or is) very free in terms of movement, style and composition - akin to agile methods in software engineering. In some ways, modern dance is easy ... anyone can just move, similarly to agile methods, anyone can hack a project together. But to get a consistent, fluid, elegant whole is extremely difficult in that the choreography of the individual dancers becomes very difficult to make consistent, unless the dancers are very experienced and instinctively understand how each is moving relative to oneself. I suspect the very good dancers here have or understand the fundamentals of movement to a very precise degree.

Ballet on the other hand is very strict with a limited set of movements which themselves are precisely defined. Wikipedia's (sorry, I know you shouldn't cite wikipedia!) article on ballet contains the statement:

"It is a poised style of dance that incorporates the foundational techniques for many other dance forms."

I need say no more regarding the basis of ballet for other forms of dance.

An in that respect we have our link with mathematics, computer science and software engineering. Formal methods are computer science's version of ballet: strict rules and technique and hard to master but forming the basis for the rest of the subject, especially software engineering.

When auditing, watching or even performing the "art" of software engineering - or at least - developing software (and systems); those who have an understanding (either explicitly or implicitly) a deep understanding of how the science works build the best software. The "moves" of the software engineer are deliberate, planned and executed with precision. This remains the same whether this is agile or formal development, though most agile development tends to be very ad hoc, messy, immature and poorly executed - like the modern dancer without discipline.

And indeed this is the core of what makes a good engineer - not whether they have the formal grounding, but they have an understanding of what makes the engineering work and the discipline to actually use those techniques properly.

Relative complexity

I'm told that software engineers don't understand taxonomies and ontologies, which confuses me a little - or actually a hell of a lot because I'm not sure what this statement actually means?

Are we saying that our software engineers are on one hand stupid but on the other hand build complex class hierarchies and relationships then navigate through the various mechanisms for building instances of those?

I currently have to construct an ontology/taxonomy for data/information with some real bizarre simplicity requirements which will ultimately reduce something inherently simple down to something unusable and without any real worth. Primarily because I am told that software engineers won't understand anything complex.

This troubles me.

Must go, off to another debate about syntax, or specifically the naming of things; or probably the colour of the picture in Powerpoint - wrong shade of pastel blue again....Wadler strikes again...

A (Lego) Shuttle to Space

This must have been fun...



Thanks to El Reg for reporting on this.

CFP: IEEE International Conference on Semantic Computing 2012

Industry Session Call for Papers

IEEE ICSC 2012: The Sixth IEEE International Conference on Semantic Computing 

September 19th- 21st, 2012 

Palermo, Italy

Website: http://icsc2012.pa.icar.cnr.it/industry-session.html

Program Goals and Format: 

The goals of the ICSC 2012 Industry Session are to foster exchanges between practitioners and the academics, to promote novel solutions to today's challenges in the area of Semantic Computing and applications, to provide practitioners in the field an early opportunity to evaluate leading-edge research, and to identify new issues and directions for future research and development efforts. Similar to regular papers, the papers in the industry session will undergo a review process and will appear in the conference proceedings. However, the selection criteria for industry papers are slightly different. In particular, papers should describe technologies, methodologies, applications, prototypes or experiences of clear industry relevance. A main goal of this session is to present research work that exposes the academic and research communities to challenges and issues important for the industry. Therefore, the papers in this session will be evaluated primarily by the novelty and applicability of the insights from its industrial solutions, instead of the originality of its algorithmic content. 

Topics of Interest: 

Topics of particular interest include but are not limited to those identified in the main conference call for papers, as well as those listed below:

1. Development of new semantic systems, architecture, and standards 

2. Employment of semantic computing tools and interfaces 

3. Employment of large scale semantic systems 

4. Benchmarking and performance evaluation of semantic systems 

5. Innovative solutions for performance optimization

6. Mobile semantic systems and services 

7. Multimedia semantic content analysis and retrieval systems

8. Modeling issues and case studies of semantic computing 

9. Game and entertainment applications 

10. e-Business and other applications 

11. Analysis of industry-specific trends and challenges 

Important Dates

Demo Submission: May 04th, 2012

Notification: June 28th, 2012

Conference: September 19th-21st, 2012

Industrial Paper Submission: 

Industrial papers should be submitted via the ICSC 2012 online paper submission system. Industry Session papers should be no longer than 8 pages with the same submission guidelines available on the ICSC 2012 web page. Only electronic submission will be accepted. All industrial papers will be peer-reviewed and published in the conference proceedings, which will be published by the IEEE Computer Society Press. Submissions must not be published or submitted for another conference. 

Industry Session Co-Chairs: 

Alexander Loui, Kodak Research Labs, USA

Vito Morreale, Engineering SpA, Italy

Ian Oliver, Nokia, Finland

Evelyne Viegas, Microsoft Research, USA

Note:

1. Every  paper accepted for publication in the Proceedings of ICSC 2012 MUST be presented during the conference.

2. Every  paper accepted for ICSC 2012 MUST have attached to it at least one registration at the full member/nonmember rate. Thus, for a paper for which all authors are students, one student author will be required to register at the full registration rate.

Progams are models

Funny how some themes tend to recur through computer science and a post on "Enso Blog" turned up this gem: Why I don’t consider Programs to be Models:

My main point here, however, is that I prefer to not think of programming languages as modeling languages. The reason is that, for me, a modeling language must be about what behavior is desired, not how to implement that behavior.

I spent a huge amount of time working on this, especially in the context of the MDA and actually trying to convince people that a description in some language such as UML was just as valid and concrete as a description in some executable programming language - though it was ironic often that something in SDL was considered a program but something in UML was considered a model.

At the time there was parallel work on something called 'executable modelling' - though interestingly that particular group never wanted to discuss what they meant by either term 'executable' or 'model'...in the end turned out because of this failing to even attempt to address these terms that particular approach (if it was even a valid approach given its lack of semantics) failed.

The posting mentioned earlier refers to another blog entry on the subject by Zef Hemel in his post Models are Programs. I tend to agree wholly with the point made there and thus indirectly with his PhD thesis: Methods and Techniques for the Design and Implementation of Domain-Specific Languages though a little surprised that mention wasn't made to some of the work in this area on specifications, especially the classic Fuchs' Specifications Are (Preferably) Executable.

However I can see the discussion on specifications versus programs lurking there but whichever way you look at things, a little abstraction reveals these things are all the same anyway.

So, after setting this up, while I don't agree with the first point and agree with the second, I do think there is an interesting taxonomic or ontological question on what makes a model different from a specification from a program - not to mention what makes something "executable" or not.

But to specifically address the point that modelling languages are about desired behaviour and not implementation is flawed in the sense that all programming languages are an abstraction - just depends on how deep you want to go.

Anyway, its late and I'll need to dig out from the recesses of my brain some of the work I made in this area but always nice to see these things haven't been resolved and still stir controversy :-)

References.
 
Johan Lilius , Ian Oliver (2007). Towards a Formal Definition of Model Driven Development (2007). Technical Report. Åbo Akademi.

Are you logged in?

Tom Anthony's blog has an article on how to detect whether someone is logged in to a given social network, eg: Facebook, Google etc..

You can run it here:  Social Network Login Status Detector Demo

 

A few things stuck me:

• I logged into Facebook earlier today and then closed the browser window - I was still logged in to Facebook
• Similarly for Twitter
• Going to www.google.com or www.google.co.uk showed the Sign In button, however it did appear according to the status detector demo above that I was still logged in. In order to log out I needed to login and then logout.

Given that some sites, particularly Facebook, have been caught tracking user behaviour when that user is not logged in (google search results here), this is quite worrying from the stand point that such tracking could occur even when you think you are not using a service or not logged in.

Before panic sets in, I'm not at this moment overly concerned about privacy (I am but...) but rather basic security and the fact that user could be accidentally revealing their behaviour.

 

I actually think that most of these kinds of accidental incidents and problems are more attributable to stupidity or less controversially, lack of knowledge, ie: Hanlon's Razor:

Never attribute to malice that which is adequately explained by stupidity.

 

or better still a quote by the journalist and UK civil servant Sir Bernard Inggam:

Many journalists have fallen for the conspiracy theory of government. I do assure you that they would produce more accurate work if they adhered to the cock-up theory.

 

I think this better explains what is going on with the current trend for secondary data collection from Apps such as those found on most mobile devices, ie: from the CNet article "Report says be aware of what your Android app does". Part of the problem is the education and knowledge of the programmers and developers in developing security and privacy aware systems and secondly the available features for security and privacy protection both on the devices and as presented to the users of those devices.

 

Now I lay part of the blame on the developers of the user experience and part on the users - mainly due to the fact that people seem not to care about setting their security and privacy settings, though it must be admitted that the user interfaces aren't really intuitive and many of these concepts rely upon the users being rather  knowledgeable about these features. I certainly don't think Privacy by Design principles help either - they are targeted at the wrong people. I'm not saying these principles are wrong or bad or unwanted but rather their targeting is off. On the other hand, this is certainly is not a trivial problem for the user experience developers, so maybe I'm being too harsh here.

One problem regarding privacy is that there still is no good formal underlying theory and practice for the developers, unlike security which is relatively mature and well defined. In fact I perceive the state we're in now is very, very similar to the level of immaturity the we saw when the masses of developers first started to develop networked systems and used network programming techniques (cf: leaky abstractions); and even the very first web based applications in the early '90s.

 

Maybe part of the problem is that in many cases privacy is still being framed in terms of security, that is confidentiality - which is partially correct but to my opinion, security is about protection of the information exchange and privacy is about protection of the content and meaning of that exchange.

It takes, I believe, about 10 years to understand these problems in the wider development community and probably another 10 to develop the theory and techniques such that they become common knowledge to the developers. Sadly at this time, I see too many incidents where despite the emphasis on guidelines, processes etc, the technical guys: the architects, the developers etc are all too forgotten.

Ultimately privacy and security are in the hands of the developers and if we don't address the problems they face through better tools, programming languages, development techniques, analysis techniques etc, then we're going to see issues such as those presented in the beginning occur in the future, malicious or more commonly not.