Comments (6)

By Mark Curphey, January 24, 2012

If you are a regular reader of this blog you should know I am working on a book for O’Reilly called Practical Software Security. It’s in the early stages and evolving as we start to get into the details. You can sign up to get notifications of progress here.

There are five main sections:

• Introduction
• Security Concepts
• Languages & Frameworks (was called Tools & Technologies)
• Building a Software Security Program
• Engineering Scenarios

In the Security Concepts section we will introduce developers to things like cryptography, authentication, authorization and then in the Languages & Frameworks sections we will cover the security features available and how to use them properly for the popular development technologies. In the engineering scenarios well get to code level guidance of how to pull it all together to solve real world problems that all developers face like securing a REST API or creating a federated authentication system.

I am delighted that we have been able to recruit a fantastic list of subject matter experts to write and review the Languages & Frameworks section of the book. I will be writing the Security Concepts section (and the Ruby on Rails section) and the following folks will be writing or reviewing:

• HTML5 (and friends) – Mark Curphey
• Java – Pravir Chandra
• .NET – David Rook (Security Ninja + Microsoft MVP for Developer Security)
• JavaScript (Client + Node) – Gareth Heyes (The Spanner) with Rey Bango as a core reviewer (JQuery Core Team Member)
• Ruby on Rails – Mark Curphey with Heiko Webers (wrote the official Rails security guide) as a core reviewer
• PHP – Mike DeLibero with Chris Shiflett (wrote the O’Reilly PHP Security book) as a core reviewer
• iOS & Android – Dan Cornell
• Identity – Gunnar Peterson

Note: we will be doing C / C++ as there is still so much being produced but haven’t yet locked on that author and we will be figuring out how to deal with things like Spring or Cake (and where to draw the line).

In the Building a Software Security Program section we organize the section into People, Process & Tools. Justin Collins (author of Brakeman Scanner) is going to write the static code analysis section in Tools and Tasos Laskos (author of Arachni) will write about how dynamic web application scanners work. Many other tools will of course be covered! I will be writing extensively about integrating Agile practices and using TDD / BDD techniques and tools. I probably won’t start on this section until March / April. I am hoping we will have the Security Concepts section and the Languages & Frameworks section complete by the end of February so we can open up a site for a much broader set of reviewers (invite only but register to get on the invite request list here) around March.

OK, now to set up the git repo for the contributing authors, create a README.md for them and kick off the discussion about we want to structure things. Gentlemen start your engines!

Edits : 1/25 – Added HTML5 (and friends), 1/25 – Added Gunnar Peterson to Identity

Comments (0)

By Mark Curphey, October 13, 2011

An interesting quote from a Google (ex Amazon) engineer on the relative importance of accessibility over security

https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

“But I’ll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.”

Comments (28)

By Mark Curphey, July 16, 2011

@curphey on Twitter and on Google Plus

I took a week off of work this week to learn Python. Truth is I have been trying to learn Ruby (and) or Python on and off for the last 18 months or so but work and kids (and the “dog ate my homework” syndrome) have always found priority and I made little meaningful progress. After a big release at work I checked my vacation balance, bit the bullet and booked this week off work. I told everyone I was going dark. It’s Friday and so far I am feeling like I have really got to grips with the basics of the core of the language. I am now in a place where I can be productive writing code and solving my own problems. I think I now have the basic level of knowledge to continue learning and overtime actually become a half-decent decent Python developer. In this post I share how I approached getting my results so far.

If you want to know why I wanted to learn a language and why I want to learn Python in particular there is of course a short story. I got involved in computer security via formal education (cryptography and mathematics). As my career progressed through start-ups and financial services companies I became good at managing technical projects and managing technical teams. Through personal interest I steered towards running software security programs and running teams of developers building software security tools. For the last five years I have been more interested in “software” than “software security” and while I am no pointy-haired boss (I have picked up a lot along the way) I have never been formally trained as a computer scientist or worked as a commercial software developer (code contributing developer). When I turned forty, two years ago I had the classic mid-life crisis. I took up distance running and evaluated my long term career plans. Many people start off their careers as highly technical individual contributors and slowly morph into spreadsheet crunching people managers. Power, money and (pseudo) respect in most corporate structures is understandably aspirational for some people but having been there and done it, I made a conscious decision to morph my career back the other way. I won’t ever stop wanting to lead teams of smart motivated and passionate people but I want to be a grass roots technical contributor creating meaningful software. I could write a very long post indeed on how I think the very nature of software teams is changing way beyond Agile and how I think the future is very small self-contained teams operating in an eco-system but perhaps for another day. The short summary is that I decided I wanted to be the member of a rock band and not a member of an orchestra and want to lead software teams from within.

Why Python? With the huge choice of languages and having explored a number over the years (Java, Ruby, Perl, C#) I decided to pick one with a view to becoming proficient in it rather than try and become a “jack of all trades” in a few. I view JavaScript and CSS as base knowledge for any modern developer so didn’t include those in the scope of my decision. You have to know them regardless if you want to build web applications. I have always been passionate about open source software and so one pre-requisite that there was a strong open source community (online, local meetings etc.) and eco-system (tools, components etc.) behind my language choice. At college in ’97 I first played with Java back when it was all about applets, then later when I ran the software security program at Charles Schwab between 2001 and 2003 we were all about EJB so Java might have been a natural choice and the eco-system is clearly very strong, but for some reason the community around Java doesn’t excite me. For me it essentially boiled down to Ruby vs. Python and to cut a long story short Python won. While Ruby has stronger test support with Cucumber (and friends) and of course a first class web framework in Rails, the developer community felt arrogant. Hang out on a ruby language mailing list for a week and you will know what I mean! Python on the other hand has a very strong scientific community behind it with a wider range of libraries for a broad spectrum of science things like bio-informatics. There is a great MVC framework called Django and in recent years Google has adopted it as one of its formal language for both use internally and on the Google App Engine. There is no real science behind my choice and it is very much personal preference but simply put it feels like a decent choice at this time.

Of course there will be a lot of code, a lot of learning and a lot of time before I will be a competent developer, if you are like me and want to learn Python (and have a day job that seems to get in the way) here is what has worked for me that you may want to consider.

1. Book a dedicated week – This is by far and away my number one tip. I took last Friday off to deal with the inevitable bow-wave of mail from work so I could enter this week 100% clear of any work issues. I structured my day with a 5 – 6 mile run every morning (obviously optional) followed by 4 hours of dedicated coding time. I take a break for the afternoon and then follow-up in the evening for a few hours (no fixed length) to cover any loose ends, extra reading and preparing for tomorrow. I created a bow-wave of learning so I wasn’t going into this week cold by starting tutorials a few weeks ago. This allowed me to focus this week on exploring important concepts and not understanding basic theory. I knew what I needed to learn going into this week and what success looked like for me so created my plan for the week (see below) ahead of time.

2. Agile Planning – I scoped out my work using Agile planning techniques. This maybe overkill but got me into the right mind-set. I used the community edition of Rally and set up a backlog and daily iterations. I even entered exercises as tests to prove my knowledge to myself. I have been able to look at my backlog, add stories and tasks and get better at estimating my velocity as the week wen’t along. Other decent free options for this include Pivotal Tracker or Agile Zen.

3. There is no substitute for writing code – You can read as many book as you want and write code in your mind but there is no substitute for writing code on your computer. It really is the only way you will learn syntax, semantics and how things really work. Don’t fool yourself into reading a chapter of a book or watching a video, writing code is what teaches you to write code. There is nothing more to say on that topic. Zed Shaw’s “Learn Python the Hard Way” echoes this. Use the Python shell as much as you can to experiment. iPython gives you a great extended shell to play with.

4. Hire (pay) a good instructor – Having a good mentor / instructor is essential. I was lucky enough to have a very smart friend (who is very, very good developer) last year agree to meet me for coffee every other week and teach me some Ruby. I never really made progress. Reason? I wasn’t committed. I never had to pay him, I would meet and catch up on a social level and our relationship was based on friendship and not on learning. This time I did some Googling, found out that the local University (University of Washington) ran an extension class and emailed the lecturer asking for private lessons. I met him for coffee first to make sure there would be a social fit and that his style would match what I was looking for. It’s not cheap (although all up will probably be 50% of the cost of doing a formal class like this) and has allowed me to operate at my own pace and on topics I want to cover. We can get side-tracked when we want. The lecturer (Brian Dorsey) is great and I look forward to meeting. During this seven day sprint we planned to meet three times and every Friday for a few weeks before and afterwards.

5. Use the Right Learning Material – Over the years I have bought a lot of language books. They range from step-by-step instructional books like the APress or Head First series to less structured books like the O’Reilly language series. While I have gotten a lot from them I have either found them to be “draw by numbers” or not organized in the way I wanted to learn. Bryan suggested “Python for Software Design – How to Think Like a Computer Scientist” which is what the UW course is based on. You can get a free PDF version here. The book has been a perfect fit for me as it talks about computer science in terms of recursion and stack diagrams and has exercises to build fractals and solve math problems. It is an an academic level that I can relate. The right material has really had a significant impact on my learning this week.

6. Use an IDE – Many purists will expose that using a text editor like TextMate (which I own) or TextWrangler is the best way to learn but for me using a fully fledged IDE has been a serious benefit. I use PyCharm and for the most part love it. When you are exploring an API you can see the functions it supports and syntax errors are highlighted as you type. While this could indeed make you lazy I think it helps you get up to speed faster so that the syntax becomes second nature. For me it’s like the difference between using a text editor or word processor to write a story.

7. Use good development practices as you learn – All week I have put my code into revision control. I generally use Git so also took the opportunity to learn Subversion this week (my only real violation of my next tip but it was so simple that …). I comment all my code no matter how trivial the example and even took to running it through the Python style guide PEP-8. Towards the end of the week I have even taken to writing unit tests for all code. Python Koans are great for learning testing in Python.

8. Just Learn the Language, Nothing Else – It’s very tempting to also learn Django at the same time as learning Python. If you want to build web apps you will need a framework to build on but I think it has been very valuable to separate the two. Apart from separating the complexity and scope it forces you to focus on the language only and not how to use the language to drive a framework.

That’s it for now. If I can think of more I will add it and I would love to hear others tips and tricks.

Useful References

A Jump Start for Learning Python

33 projects that make developing django apps awesome

http://learnpythonthehardway.org/

ipython

Python Koans

Comments (1)

By Mark Curphey, January 24, 2011

Before you read this post you should know that at some point someone will say “All well and good but you don’t practice what you  preach!”. I know. This blog is currently hosted on WordPress and I am using an SEO plugin which covers the basics but is far from ideal. I plan to move this blog to a custom written blog engine at some point and so investing time in tweaking this blog is not a priority. What I have learn’t about SEO is driving features of the custom written blog (discussions) engine in development right now. Now with that out of the way…….

If you are like me you will have heard the term Search Engine Optimization or SEO and associated it with the sleazy side of internet spam and messages like “Be Number 1 on Google Guaranteed, Click Here Now”. I knew that a large portion of any blog traffic is driven from search but I had decided in my mind that it was something I didn’t need to deal with. I know realize that was a big mistake! The epiphany came when I first started looking into SEO casually and had a discussion with my friend JD Meir over lunch. JD runs a very popular blog called Sources of Insight (hosted on WordPress) yet had some basics missing. When he fixed the issues he saw a significant jump in his traffic. Just last week I was exchanging email with a friend who is the CSO of a top company and told he he only gets just 50 page views a day on his blog. I have spoken to many people about SEO and it is suprising how little people know so here are the 5 top things that I think all bloggers should know about search engine optimization and therefore optimize users finding your content and driving up your traffic. It is certainly not exhaustive and certainly not an original list. If you want to “Pass Straight to Go” I suggest buying the Art of SEO by O’Reilly. Awesome series of books

My top 5 are:

1. Register with Google and Bing Webmaster tools

2. Generate a sitemap.xml

3. Understand Keywords

4. Install Analytics

5. Run Free SEO Analysis Tools

Register with Google and Bing Webmaster Tools

Google and Bing (which now including the Yahoo search traffic) account for the vast majority of internet search traffic (somewhere in the ballpark of 85%) and so making sure that those search engines can find your content is absolutely critical. Both sites have tools for webmasters that allow you to register your site and ensure that the search bots can crawl it. They then provide suggestions for basic optimization and allow you to monitor any issues the search engines maybe having. They also allow you to view the keywords they see on your site and queries that users searched for which they then referred to your site. I’ll focus on the Google webmaster tools here but the Bing experience is pretty similar.

You will first need to go to Google and sign in at http://www.google.com/webmasters/tools/ with your Google ID. Once you are in you will need to add your site and do some basic configuration. When you add your site you will first need to prove that you own the site. There are several options such as adding a verification code into some HTML but the easiest way in my opinion is to add a DNS TXT record to your domain. You copy the verification code from the webmaster tool and create a DNS TXT record at your DNS provider. You then go back to the webmaster tools and verify the domain. Google queries the DNS, checks the verification code and voila ! After a few more clicks you are now registered and can poke around on the site and see how Google see’s your site . It is all very self-explanatory. Don’t worry if at first Google doesn’t appear to know much about you. Registering is the first step in letting then know you exist. You need to systematically go through each suggestion, fix issues and then let the crawlers update their indexes and reflect the updates in the results. It can take several weeks even after making changes to see results.

Generate a sitemap.xml

One of the items the site master tools will check is for the presence of a sitemap.xml file. This is a file that is added to your site and acts as the primary front-door for the search engine crawler. You can find out more in this Wikipedia article. Having a sitemap.xml is essential. Given that your site content will change you really need your site to be abel to update the sitemap.xml file as new content is published. If you are using wordpress there are several tools that will do this for you. Some simply allow you to generate a file and manually re-submit it to the search engines. I use the Yoast WordPress plugin today.

Understand Keywords

Search engine keywords are essential to understand two fundamental things. The first is the keywords that the search engine sees on your site. Think of it as the content that the search engine sees as available to match to potential users. The second (and often over looked) is the keywords that users are searching for. Google allows you to look at keywords and view the amount of times users were looking for content that matched with those words. As an added bonus they conveniently provide a nice interface to compare the supply of keywords and the demand to advertise against them and the amount of people searching against them. This allows you to look for areas with your target topics where users are crying out for content and where little is available today. You can also predict the amount of traffic this would generate if you were able to fill that gap in the market. A useful tool is the Google Adwords tool. Sophisticated SEO software often uses the Google Data API’s to get similar data programmatically.

Install Analytics

Whats that phrase “if you can’t measure it you can’t manage it?”. While webmaster tools will provide basic data about queries and keywords the more sophisticated analytics tools will allow you to capture rich data. You can even instrument scenarios such as a user moving through a registration wizard to find out where they drop off or so A/B variant testing to compare experiences or articles. I am using the Google analytics. Similar to the webmaster tools you will need to register your site and prove ownership, after which you will be given a piece of JavaScript that you call from every page on your site. I use a nice free iPhone app called Analytics Agent Lite to track my stats on my phone.

Run Free SEO Analysis Tools

Finally there are a number of things you will want to configure ranging from ensuring you have meta-content tags, individual page titles, encoding to ensuring you use H1, H2 etc HTML elements. A really simple free tool that I have found is WooRank. Just type in your domain and let it generate a report. Simple, quick and free.

So there it is, 5 Basic Things Any Blogger Should Know About SEO and that could have dramatic effects on your  traffic. If this has been useful and you get results please let me know in the comments!

Comments (3)

By Mark Curphey, January 17, 2011

“Game theory” is one of those phrases that I have heard many times in my life but never understood what it was. Most British computer science courses have an elective and I am sure most mathematics undergraduate degrees include it in the curriculum but I did my Masters degree in a mathematics department and my undergrad degree in an engineering department so missed out. It’s never too late to learn so a few weeks ago I got a book called Rock Paper Scissors with the intent of trying to understand if there was a correlation between game theory and how humans behave in social networks and online communities. I think I am onto something and while it’s early stages of really understanding the topic I suspect game theory could be used to explain and understand many patterns of why people do what they do and how to effectively structure incentive and plan for conflict. More importantly it may offer a very real blue-print for effectively motivating and rewarding online communities to work better together.

The first chapter of the book discusses the “Tragedy of the Commons” and what is often known as “The Prisoners Dilemma”. This simple theory is having such a profound effect on my thinking that I wanted to share it incase anyone else was in my shoes and interested in game theory and online community.  John Nash was portrayed in the Hollywood film A Beautiful Mind as a paranoid schizophrenic and shared the Nobel prize in 1994. One of his greatest achievements was the Nash Equilibrium.

Assuming we don’t want to go into the math above (I don’t and probably can’t) the theory has been turned into numerous scenario based examples to help mere mortals understand it. One such example is called the Prisoners Dilemma and of course there are many variations on the story but imagine this.

Two thieves are arrested. They are both carrying concealed weapons, a crime which caries a sentence of at least 2 years. There is no solid evidence but they also just committed a burglary where the mandatory sentence for an armed burglary is 10 years. There are several options how the scenario might play out;

• If they both keep their mouths shut they will both get 2 years each or a total of 4 years of punishment.
• If they both confess they will both reduced sentences of 4 years or a total of 8 years.
• If one is convinced to ‘grass’ on the other and in doing so plead guilty to the armed robbery he might a reduced sentence of 4 years and the other the maximum sentence of 10 years (14 years total).
• If they are both found guilty without confessing they will get 10 years each or a total of 20 years of punishment.

As you can see it is in both of their interests to keep their mouths firmly shut (morals aside). You can read more about how these scenarios can be depicted in matrix tables and the variations in the book and on Wikipedia.

The interesting thing here from a social science perspective is that the optimum solution for both prisoners relies on two fundamental things. Both parties must agree the strategy (keep their mouths shut in this case) and both parties must execute that strategy. As soon as either party deviates form the strategy both parties will suffer. How bad either party suffers depends on the deviation.

This not only sets a great framework to explain why people should co-operate but sets the basis for how to create online schemes where working together is rewarding and working against each other punishes the community. As I mention this is early days for me but I plan to capture my learnings in the community wiki I am building and look at how game theory may explain why some communities thrive and others die. I suspect there are core patterns in the way community members are recognized and rewarded that are key to the success or failure of groups.

Comments (1)

By Mark Curphey, October 20, 2010

In the coming year I plan to post about a new side project I am working on with some friends. It’s a long term fun thing and very much a side-project to our day jobs. We have decided we think there should be better software for online communities and have decided to have a go at putting our code where our thoughts are. We will be developing our site using Ruby on Rails (using behavior driven development (BDD) and continuous integration (CI)). I recently bought a MacBook Pro to do my development on and love it. While tools exist on Windows, my observation has been that any serious Rails developer looks for TextMate, Git, MySQL and other tools that are somewhat native to *nix based OS’s. In short Cygwin drove me up the frigging wall!

During the day I work at Microsoft and so the obvious question has come up in conversation. ”You work at Microsoft yet have an iPhone, MacBook and build software in your spare time using Ruby on Rails. What gives?”.

Here is my opinion:

1. “Different Horse for Different Courses” – There is a great English phrase meaning that some race horses are better in the flat and some better over hurdles. If you look at the eco-system for social software a significant portion has grown up from open source roots. The Ruby eco-system with GEM’s like OminAuth for instance is rich with lots of Lego blocks for us to use for the type of site we want to build. It’s a good horse for our course.  Conversely if I was building a corporate app with integration into corporate infrastructure I would be looking to a different horse, .NET. It’s true you could build either type of software with either type of solution (let’s face it StackOverFlow is built in .NET) but for what we want to build, Ruby and Rails makes sense.

2. You Can Learn a LOT with an open Mind – If it wasn’t for exploring Cucumber and Behavior Driven Development I would not be driving these techniques back into my work at Microsoft. I have always believed that you can learn a great deal but looking at what others are doing in life. Using Git (and GitHub), Cucumber, RSpec, Heroku, OSX, TextMate etc. is a great learning experience.

3. “I bet all the workers at Rolls Royce don’t drive Rollers to the shops!” – I once did some security work at Coca-Cola. Employees were really sensitive (actually they were damn right rude) to anyone seen eating or drinking competitors food. It seemed like such a short sighted view of the world I used to joke “do you think Rolls Royce assembly workers drive a Roller to the shops?”. At work we make sure our sites run just as well on Chrome and FireFox as they do on IE. To do that you drive Chrome and drive FireFox.

4. Getting Away From Work – When you work long hours, sometimes the last thing you want is to get home to your hobby and for it to feel like work. “All work and no play makes Jack a dull boy”.

I don’t feel I need to justify why I am using OSX, a Mac and building Ruby on Rails apps for a hobby but figured I would at least explain for anyone who is interested.

Comments (0)

By Mark Curphey, October 19, 2010

[Originally posted on my securitybuddha blog on 9/10/2008]

I am reading Brain Rules; great book! In the opening chapter there is a wonderful quotation from an interview with Frank Lloyd-Wright that resonates with how I feel about the application security industry.

“When I walk into St. Patrick’s cathedral here in New York City, I am enveloped with a feeling of reverence”, said Mike Wallace.

“Sure it isn’t an inferiority complex?”.

“Just because the building is big and you are small, you mean?”

“Yes.”

“I think not.”

“I hope not.”

“You feel nothing when you go into St. Patrick’s?”

“Regret”, Wright said without a pause, “because it isn’t the thing that represents the spirit of independence and the sovereignty of the individual which I feel should be represented in our edifices devoted to culture.”

It’s certainly no secret among my friends that for past several years I have grown increasingly disillusioned with the information security industry and especially disillusioned with the application security industry (whatever that really is).  Why? I will get onto the information security part where fluffy compliance and best practice culture  seems to be gaining acceptance in future posts (probably after a few glasses of wine) but if we take the application security industry specifically then I personally find it is disappointing that after a decade of it being considered a discipline in it’s own right, it is still predominantly made up of breakers and not builders. It’s still predominantly made up of an army of skilled hackers focused on better ways to break systems apart and find new ways to exploit vulnerabilities than “security architects” who are designing secure components, protocols and ultimately secure systems. If you don’t believe me go have a conversation with a  so called application security  consultant about SAML or security issues in Enterprise Message Buses and you’ll almost definitely draw blank stares. Ask application security consultants if they know about the latest HTTP or HTML spec and they’ll likely say yes (and want to demonstrate the latest issues) but if you ask them about the latest WS-x spec you’ll likely draw more blank stares.  When was the last time you saw an attack drawn out as a UML sequence diagram? This is worrying and somewhat sad. I don’t think we are culturing, encouraging and nurturing people with the right skills to make a positive difference.  We need more computer scientists, engineers, designers, architects and builders and less breakers in my humble opinion.

Don’t get me wrong, I get and buy the fact that you can learn about how to protect systems by learning how to break them but this is not my point. If the application security industry is to be taken seriously by the mainstream development community (and by taken seriously I mean engage with them as a partner and not as a PITA) then it has to engage in complimentary activity; the design of secure systems. We have to stop enumerating badness and slinging mud and start adding positive value.

If we think about a typical development team we have;

• Product / Program Managers
• Architects
• Developers
• Testers

Today application security seems more closely aligned to testing than architecture or development and this needs to change. Designing secure software and systems is clearly not as trendy as showing clever parlor tricks to hack a system but there is room for both.

These days I much prefer to attend and speak at development conferences than security ones, even if it’s on security topics. I find that the people are positive and focused on the right things and I think are in general better equipped and motivated to make a real difference to the cause of insecure software. To illustrate this I just got back from TechEd New Zealand and Australia. If you look at the speaking tracks (including the security track) you will find talks on .NET 3.5 security features (CAS etc), Zermatt (our new claims based identity and token framework) and similar topics . Contrast this with popular security conferences and you will see that the security industry continues to enumerate badness.

Take for instance the upcoming OWASP conference in NYC.  I love OWASP, brilliant stuff but it’s almost all attacks based. Even a talk entitled “Web Application Security Roadmap” looks like its about more testing and more enumeration of badness.

Loads of talks about injection attacks, not a single one on WS standards or SAML or ………

The great divide between the builders and breakers seems to be widening. I think we need more builders.

PS: Ironically this blog post was crafted sat outside a cafe at the Rocks in Sydney underneath the awe inspiring Sydney Harbour Bridge. Imagine what Australia might not be if the settlers took a look around and only focused on the things that were bad with the country!

- Mark Curphey

Comments (1)

By Mark Curphey, September 7, 2010

I have an interesting personal project brewing looking at ways to build better community software and am exploring emerging thinking about the next generation of web applications. Tim O’Reilly wrote a seminal blog (part one and part two) describing the Internet as THE new operating system. In the post he uses the analogy of traditional operating systems like Windows or Unix and the computing services they provide (file storage, networking, user management etc.) and then describes the Internet as an Operating System providing information services to distributed applications. There are some obvious fundamental differences in thinking about building scalable applications on the Internet Operating System such as binding together distributed services. There are also a number of less obvious but fundamentally important things to consider such as the fact that there will be many choices for common services such as authentication (Google, Yahoo, LinkedIn, Twitter, FaceBook Connect etc.) and smart application designers will need to adopt new architectural and functional models that provide the user with their preferred choice and not just one option as is the norm with traditional operating systems.

As I have started to think about the model I started to capture the potential services you could consume in a diagram (below). Its a first pass that I plan to update. The simple rule I am operating under is that to be considered a service there should be a published API in which to connect.

What else would you include?

Comments (1)

By Mark Curphey, September 7, 2010

I recently heard a wonderful story about design that I simply had to re-tell. Claudia Kotchka is the head of design at Proctor & Gamble. P&G make stuff and they make lots of it. From household goods to food P&G design and manufacture a wide range of goods that I am sure you use. In October 2005 Kotchka spoke at an industry event about the emotional connection between people and design and in an attempt to drive home the point that design is not just about being functional used the Altoid tin as an example. Altoids are the curiously strong mint that come in a distinctive tin.

Here is how she described the Altoid experience:“Open the metal tin with the nostalgic typeface; hear and feel the crinkly liner paper; smell the scent of peppermint oil wafting out the of box; and see the hand-made appearance of the uneven size mints. Even the tin appears to be hand filled and packaged. The whole thing is very authentic.”

Of course Altoids are as mass produced as other candy but the company has maintained the design as they have modernized their production. Kotchka described a scenario of how Altoids might look if P&G owned the brand (before their focus on design of course). P&G are a functional company who do a great job designing packaging that is highly efficient. The management would almost certainly attempt to get rid of the expensive tin and put in it a diaper-wipe type container with a single cheap mono-tone sticker. The liner paper would go and mints would be normalized in shape to reduce the size of the container and hence reduce manufacture, shipping and storage costs. She even suggested that P&G would probably rename the new product Proctoids to maintain the brand but promote P&G. To drive the point home she had an industrial designer mock-up the new product for full visual effect. The only image I can find is poor quality (see above) but certainly provides a good visual.  It’s unidentifiable from a pill dispenser; functionally great design, low cost, high performance but with zero emotional connection. Gone would be the pleasure people get when they buy Altoids in a tin and ironically gone would be the significant price premium over other mints (that far outweigh the additional manufacturing costs).

In the software world Apple get design and the Apple Design Awards recognize great software design. If you haven’t played Flight Control (one of this years Apple Design Awards for the iPhone) then I recommend it. There are some wonderful examples of web based software appearing that creates an emotional connection and that has loyal fans. Zendesk.com is one example but there certainly aren’t enough.

When I was at University I shared a house for a short period of time with a student artist. I used to laugh at his stupid bits of art and fall on the floor when he used to tell me “You aren’t qualified to make a judgment on whether its good or not”. I was young and frankly he was an idiot. His response was an excuse to being challenged much like you hear the god squad preach “god exists because you can’t prove he doesn’t”. What was missing though was an appreciation that an emotional connection between a person and a design (art or software) is a personal thing. Good design is rarely the optimal functional design but when we get design right for a large portion of the potential user population it will result in loyal passionate fans who are prepared to pay a premium. The same principle applies to a work of art by Rembrant or a web site by a young Rails coder.

Factoid : Design matters.