LANGSEC: Language-theoretic Security

Wow.  Just wow.  See "LANGSEC explained in a few slogans".

Short, easy-to-grasp explanation of why complex protocols create new problems.

I'm happy with REST and the stack of stuff under it (HTTP, TCP/IP, etc.)

Once upon a time (2001), I invented by own version of a RESTful protocol outside HTTP.  That was cool.  Very simple, and very fast.  But relatively inflexible.  The syntax was more like FTP and SMTP; the semantics where mostly just CRUD rules and RESTful state transfers.

I was way too dumb to leverage HTTP methods and the genius of a URI.

Technology Refresh

I've been refurbishing an older project -- written in 2008.  Probably with Django 1.0.1.  Certainly with Python 2.5.

The Django 1.3 release has been around since March.  The change underscored the importance of technology refresh.

The best part was to delete code.  There were two significant reasons.

• The testserver command allowed me to eliminate a bunch of low-value test harness.   Without this command, we had to create our own test database, start a server, run integration tests, and then kill the server.  With this command, we simply start and kill the server.
• The RESTful web services can be securely integrated into the main web application.  A simple piece of middleware can authenticate requests based on headers containing ForgeRock OpenAM tokens.  It may be that this was always a feature of Django, but over the last few years, we've figured out how to exploit it with simple middleware.

Few things are better than removing old code and replacing it with code written (and tested) by someone else.

In  addition to the deletes, we also rearranged some of the dependencies.  We had (incorrectly) thought of the Django project as somehow central or essential.  It turns out that a bunch of other Python libraries were actually core to the application.  The Django web presentation was just one of the sensible use cases.  A suite of command-line apps could also be built around the underlying libraries.

In addition to this cleanup, we also replaced the documentation with a new Sphinx project.  The project originally used Epydoc markup.  This meant that every single docstring had to be rewritten to use RST markup.  The upside of this is that we corrected numerous errors.

There Was Pain

This wasn't without some pain.  

Was the cost worth the effort?  That's the real question here.

I think that many IT managers adopt a silly "If it ain't broke, don't fix it" policy that focuses on short-term cost and short-term value.  It ignores long-term accrual from even tiny short-term cost savings.

Here's are two important lessons.  

• Money saved today is saved forever.
• Savings accrue.  Forever.

It's important to avoid short-term thinking about cost and benefit.

Color Schemes

I worked with this a few years ago to tweak up some web pages.

http://colorschemedesigner.com/

I just rediscovered it.  It's a cool toy.  You get some colors that all "go" together.  If you're careful with your .CSS definitions, you give people this page and let them fuss around until their positively silly with color palettes.

Good Summary of Bad Security Assumptions

This isn't the OWASP Top 10 list, but it's still very handy.

Top 10 Dumb Computer Security Notions.

I'm particularly fond of the "security can't be perfect; since it can't be perfect, why bother?" approach.

One other notion that amuses me is the silliness of changing a password every 90 days.  The argument is that "it's harder to hit a moving target".  That's obviously false.  A good rainbow table and a bad password without salt can be broken in about half an hour.  There's no "moving target" here.  At 30 minutes to crack a password, the only way the target can appear to move is making every password a 1-time-only password based on some kind of external source (like a token generator.)

The need for ping

Years ago, when designing an interface to a vendor's web services, I did the following.  This isn't a genius move, but it's worth emphasizing how important it is.  And what's most important isn't technical.

1. I built a simple spike solution to access their service.
2. I morphed this into a "sanity check" to be sure that their service really was working.  Mostly, I cleaned up the code so that it was testable and deliverable without embarrassment.
3. I morphed this into a "diagnostic tool" to bypass the higher-levels of the application and simply access the vendor (and optionally dump the results) to help determine what wasn't work.  This involved adding the dump option to the sanity check and renaming the command-line application.
4. I morphed this into a "credentials check and diagnostic tool".  This was -- ahem -- merely taking the hard-wired credentials out of the application.  Yes.  The first versions had hard-wired credentials.

That brings us to the version in use today.  The "vendor ping" application.

The default behavior is a credentials check.

One optional behavior is to dump the interface details.

Another optional behavior is to allow selection among a small number of simple interactions just to be sure things are working.

Unplanned Work

What's important here isn't that I did all this.  What's important is that the deliverables, user stories and project plans didn't include this little nugget of high-value goodness.

It gets run fairly frequently in crunch situations.  The actor in the story ("As system admin...") is rarely considered as a first-class user of the application.  Yet, the admin is a first-class user, and needs to have proper user stories for confirming that the application is working properly.

Statically Typed Language Nonsense

Read this: "Here Comes Functional Programming" by Larry O'Brien in SD Times.

people who should know better continue to assert that statically typed languages are "safer, because the compiler can catch errors that otherwise wouldn't show up until runtime." While it's true a statically typed language can detect that you've assigned a string to a double without running your code, no type system is so strict that it can substitute for a test suite, and if you have a test suite, type-assignment errors are discovered and precisely diagnosed with little difficulty.

Thank you.   A language like Python, which lacks static type declarations for variables, is not evil or an accident waiting to happen.

The article is about functional languages.  But the static declaration statement is universally true.

I'm Confused by this Marketing Ploy

Got this a few weeks back.

My job is to persuade bloggers to link to our site. 

I really love my job! We have a friendly team and good management, but unfortunately I have no idea how to convince a blogger to link to us, I'm afraid I might lose my job because of it :( 

And that is why, instead of sending letters to thousands of different blogs, I am reading yours.

Couldn't parse it.

It seems to be a calculated Pity Ploy.  "I'm afraid I might lose my job...I am reading your [blog]."

The product seemed cool enough.  The pitch, however, was too sketchy for me.

Agile "Religion" Issues

See this Limitations of Agile Software Development and this The Agile "Religion" -- What?.  What's important is that the limitations of Agile are not limitations.  They're (mostly) intentional roadblocks to Agile.

Looking for "limitations" in the Agile approach misses the point of Agile in several important ways.
The most important problem with this list of "limitations" is that five of the six issues are simply anti-Agile positions that a company can take.

In addition to being anti-Agile, a company can be anti-Test Driven Development.  They can be Anti-Continuous Integration.  They can be Anti-NoSQL.  There are lots of steps a company can take to subvert any given development practice.  Taking a step against a practice does not reveal a limitation.

"1. A team of stars... it takes more than the average Joe to achieve agility".   This is not a specific step against agility.  I chalk this up to a project manager who really likes autocratic rule.  It's also possible that this is from a project manager that's deeply misanthropic.  Either way, the underlying assumption is that developers are somehow too dumb or disorganized to be trusted.

Agile only requires working toward a common goal.  I can't see how a project manager is an essential feature of working toward a common goal.  A manager may make things more clear or more efficient, but that's all.  Indeed, the "clarity" issue is emphasized in most Agile methods: a "Scrum Master" is part of the team specifically to foster clarity of purpose.

Further, some Agile methods require a Product Owner to clarify the team's direction.

"A team of stars" is emphatically not required.  The experience of folks working in Agile environments confirms this.  Real, working Agile teams really really are average.

"2. Fit with organizational culture".  This has nothing to do with Agile methods.  This is just a sweeping (and true) generalization about organizations.  An organization that refuses autonomy and refuses flexibility can't use Agile methods.  An organization that refuses to create a "Big Design Up Front" can't use a traditional waterfall method and must use Agile methods.

Organizational fit is not a limitation of Agile.  It's just a fact about people.

"3. Small team...Assuming that large projects tend to require large teams, this restriction naturally extends to project size."

The assumption simply contradicts Agile principles.  It's not a "limitation" at all.  Large projects (with large numbers of people) have a number of smaller teams.  I've seen projects with over a dozen parallel Agile teams.  This means that in addition to a dozen daily scrums, there's also a scrum-of-scrums by the scrum masters.

Throwing out the small team isn't a limitation of Agile.  It's a failure to understand Agile.  A project with many small teams works quite well.  It's not "religion".  It's experience.

A single large team has been shown (for the last few decades) to be expensive and risky.

"4. Collocated team...We can easily think of a number of situations where this limitation prevents using agile:"  These are not limitations of Agile, but outright refusals to follow Agile principles.  Specifically:

• "Office space organized by departments" is not a limitation of Agile.  That's a symptom of an organization that refuses to be Agile.  See #2 above; this indicates a bad fit with the culture.  An organization that doesn't have space organized by department might have trouble executing a traditional waterfall method.
• "Distributed environment" is not a limitation of Agile.  Phones work.  Skype works.
• "Subcontracting... We have to acknowledge that there is no substitute for face-to-face".  Actually, subcontracting is irrelevant.  Further, subcontracting is not a synonym for a failure to be collocated.  When subcontractors are located remotely, phones still work.  Skype works better and is cheaper.  

"5. Where’s my methodology?"  This is hard to sort out, since it's full of errors.  Essentially, this appears to be a claim that a well-defined, documented processes is somehow essential to software development.  Experience over the last few decades is quite clear that the written processes and the work actually performed diverge a great deal.  Most of the time, what people do is not documented, and the documented process has no bearing on what people actually do.  A documented process -- in most cases -- appears irrelevant to the work actually done.

Agile is not chaos.  It's a change in the rules to de-emphasize unthinking adherence to a plan and replace this with focus on working software.  Well-organized software analysis, design, code and test still exist even without elaborately documented (and irrelevant) process definitions.

"6. Team ownership vs. individual accountability... how can we implement it since an organization’s performance-reward system assesses individual performance and rewards individuals, not teams...?"  Again, the assumption ("performance-reward system assesses individual performance") is simply a rejection of Agile principles.  It's not a limitation of Agile, it's an intentional step away from an Agile approach.  

If an organization insists on individual performance metrics, see #2.  The culture is simply antithetical to Agile. Agile still works; the organization, however, is taking active steps to subvert it.

Agile isn't a religion.  It doesn't suffer from hidden or ignored "limitations".

"But did we question the assumption that Agile was indeed superior to traditional methodologies?"  

The answer is "yes".  A thousand times yes.  The whole reason for Agile approaches is specifically and entirely because of folks questioning traditional methodologies.  Traditional command-and-control methodologies have a long history of not working out well for software development.  The Agile Manifesto is a result of examining the failures of traditional methods.

A traditional "waterfall" methodology works when there are few unknowns.  Construction projects, for example, rarely have the kinds of unknowns that software development has.  Construction usually involves well-known techniques applied to well-documented plans to produce a well-understood result.  Software development rarely involves so many well-known details.  Software development is 80% design and 20% construction.  And the design part involves 80% learning something new and 20% applying experience.

Agile is not Snake Oil.  It's not something to be taken on faith.  

The Agile community exists for exactly one reason.  Agile methods work.

Agile isn't a money-making product or service offering.  Agile -- itself -- is free.  Some folks try to leverage Agile techniques to sell supporting products or services, but Agile isn't an IBM or Oracle product.  There are no "backers".  There's no trail of money to see who profits from Agility.

Folks have been questioning "traditional" methodologies for years.  Why?  Because "traditional" waterfall methodologies are a crap-shoot.  Sometimes they work and sometimes they don't work.  The essential features of long term success are summarized in the Agile Manifesto.  Well-run projects all seem to have certain common features; the features of well-run projects form the basis for the Agile methods.