I was featured in a UK article about the conference that I spoke at in Bristol a few weeks ago.
DevOps Topologies: considering all the ways that development and operations organizations can work together (or separately) and what’s wrong (or right) about each option.
Conferences typically have two official parts, talks (including big keynotes, little presentations in small gatherings, and everything in between) and the trade show floor. The talks are what people come for and are what brings press attention to the conference. The trade show floor pays the bills.
Trade show floors are infinite grids of elaborate temporary architecture, with each plot of land covered in concrete and cheap carpet and leased to a vendor for the duration of the show. The plots are sized according to how much the vendor pays for their sponsorship. On the plots, vendors and their marketing event companies build simple or elaborate booths, like the sukkōt of the Feast of the Tabernacles, only with no roofs. Also unlike a sukkah, the walls of a booth may, in fact, sway in the wind, or if a vendor walks behind them and knocks them down.
Some vendors have small ground height booths, but most go up, so that they can be seen from afar. Unfortunately, with every vendor “going up,” the effect is often lost and you end up with an air space arms race. I’ve seen a marketing manager from one company snarling at another because the second company’s booth cast a shadow on the first.
The trade show floor is a gathering; it is constructed quickly knowing it is only temporary, and demolished just as quickly. But in between, it’s a linear descendent of the oldest traditions of human commerce: the agora. Because to this giant assemblage of bright booths come booth staff—people like me—and conference attendees. Some attendees come to talk to vendors because they have a need to fill; most come for freebies. At this conference, the freebies include brochures, keychains, cheap electronic gizmos, stuffed animals, alcohol, and—critically important—coffee. And so people meet and trade. Maybe not directly, but they may take the first steps to an agreement. It’s a ritual that hasn’t changed in thousands of years.
Springer has published a bunch of its books online for free. (Hundreds more were free until this morning but the plug has been pulled.) I went looking to see what I could find. There are some interesting finds there, including a festschrift for Ted Nelson, the inventor of hypertext. And, relevant to my work interests, a text called The Infosec Handbook.
What’s that, you say? A free textbook on information security? Sign me up! Well, not so fast, pilgrim.
Admittedly, I come to the topic of information security with a very narrow perspective—a pretty tight focus on application security. But within that topic I think I’ve earned the right to cast a jaundiced eye on new offerings, as I’m going to celebrate my eighth year at Veracode next month. And I’m a little disappointed in this aspect of the book.
Why? Simple answer: it’s not practical. The authors (Umesh Hodeghatta Rao and Umesha Nayak) spend an entire chapter discussing various classes of threats, trying to provide a theoretical framework for application security considerations, and discussing in the most general terms the importance of a secure development lifecycle. But the SDLC discussion includes exactly one mention of testing, to wit, in the writeup of Figure 6-2: “Have strong testing.” And an accompanying note: “Similarly, testing should not only focus on what is expected to be done by the application but also what it should not do.”
It’s pretty widely understood in the industry that “focus(ing) on what is expected” and “[focusing] on what [the application] should not do” are two completely different skill sets and that even telling a functional tester what to look for does not ensure that they can find security vulnerabilities. The problem has been well known for so long that we’re nine years into the lifespan of the definitive work on the subject, Wysopal et al’s The Art of Application Security Testing. But there’s no acknowledgment of any of the challenges raised by that book, including most notably the need to deploy automated security testing to ensure that vulnerabilities aren’t lurking in the software.
As for the “eight characteristics” that supposedly ensure that an application is secure, take a look at the list for yourself:
- Completeness of the Inputs
- Correctness of the Inputs
- Completeness of Processing
- Correctness of Processing
- Completeness of the Updates
- Correctness of the Updates
- Maintenance of the Integrity of the Data in Storage
- Maintenance of the Integrity of the Data in Transmission
Really? Nothing about availability. Nothing about authorization (determining whether a user should be allowed to access information or execute functionality). Nothing about guarding against unintended leakage of application metadata, such as errors, identifying information, or implementation details that an attacker could use. And nothing about ensuring that a developer didn’t include malicious or unintended functionality.
The chapter also includes no mention of technologies that can be deployed against application attacks, though this may be a blessing in disguise given the poor track record of web application firewalls and the nascent state of runtime application self-protection technology.
All in all, if this is what passes for “state of the art” in a security curriculum from the second biggest textbook publisher in the world, I’m sort of relieved that information security isn’t a required curriculum in a lot of CS programs. It might be better to learn about application security in particular from a source like OWASP, SANS, or your favorite blog than to read a text as shallow as this.
You’ll be able to catch me in my professional capability twice next week. I’ll be giving a talk on Tuesday in Austin, TX to the Austin chapter of ISACA (the Information Systems Audit and Control Association) on “Best Practices for Application Risk Management.” The argument: the current frontier in securing sensitive data and systems isn’t the network, it’s the applications securing the data. But just as it’s hard to write secure code, even with conventional testing tools, it’s even harder to get a handle on the risk in code you didn’t write. And, of course, it’s the rare application these days that is 100% code that you wrote. I’ll talk about ways that large and small enterprises can get their arms around the application security challenge.
I’ll also be joining one of our customers to talk in more depth about a key part of Veracode’s application risk management capability, our developer elearning program and platform, in a webinar. If you are interested in learning how to improve application security before the application even gets written, this is a good one to check out.
The recent flap over the impending death of tr.im reminds me of a discussion I had at the Berkman Center when I crashed one of their meetings back in 2004. The question was, do you use external services with your blog? That is, do you host your images on Flickr or a related service? Do you outsource comment management? These days, the question is do you host your own videos or do you let YouTube do it; or do you use a URL shortener.
Fundamentally, these are strategic questions like the ones that product managers face every day. The question is “Build, Buy, or Partner?” and it’s a question about how you add functionality to your product offering. In this case, the “product offering” is your public presence on the Internet–which is to say, in public, on-the-record discourse. As the question is conventionally understood, “build” means build it yourself, “buy” means acquire the functionality via some sort of purchase of rights, and “partner” means make a business arrangement where the partner delivers the functionality directly. In web development terms:
- Build: You can build most of the functionality that people use on the web, from photo galleries to URL shorteners, yourself if you are a reasonably competent programmer.
- Buy: You are acquiring via a license (even a free one) functionality from a third party and providing that functionality to your users. Can include purchased software or free software, whole packages or plugins.
- Partner: You are using third party services directly–embedding photos and video from someone else’s server, using a third party URL shortener, etc.
So how do you decide to build, buy or partner? You can ask yourself the same questions that product managers everywhere ask:
- Do I have the capability to create this functionality?
- Do I want the responsibility of maintaining this functionality and adding to it over the long run?
- Is this functionality a core part of what I do? Do I derive some sort of competitive advantage from it?
- How much control over the final product do I want?
- Can I afford to have the content go away?
If you can do #1 but not #2, buy might be a better option than build. If the answer to #4 is “a lot”, partnering is not an appropriate option.
Let’s look at some people’s reactions to the event in this light:
Dave Winer had chosen the “partnership” model with tr.im (in the sense described above, that he is using their services and building atop them), building a lot of functionality on top of their APIs. He sees tr.im’s collapse as an argument to eliminate URL shorteners altogether, or at least to require that they provide a portability option. Portability is a way that you can escape Question #5, a safety clause if the partner goes out of business or if you don’t like what they’re doing with your content. I think that shortened-URL portability is in this analogy the equivalent of source code escrow and other safety provisions in conventional software contracts–it’s your escape hatch to make sure your personal data isn’t threatened. This is a perfectly sane request if you’re entering a real partnership relationship, where you’re adding value to the other party’s offering.
By contrast, Jeffrey Zeldman went the “buy” path, installing a WordPress URL shortening plugin to share pointers to his own content. For him, having short links to his content that work indefinitely is too important to risk having “the third-party URL shortening site [go] down or [go] out of business.”
Looking at it through the build-buy-partner lens, it’s also easy to see why WordPress has become such a dominant platform. The ability to add third-party developed plugins to add functionality provides a wide variety of options to add new functionality and allows you more options than simply blindly partnering with another organization, without any assurance that they’ll continue to support you.
Why go down this path at all? Why worry about the longevity of what are almost certainly transient services? One way to look at it is this: at the end of the day, your web presence is your product, and you are its product manager. You are responsible for the strategy that determines how the world views you. And in that light, it makes sense to borrow some strategies from product management to plan that strategy. Others use the formulation “You are your own CEO”; as your own CEO, consider that what people interact with online is not you but a product.
I’ve been up to my eyeballs in user doc recently, our software-as-a-service product offering having matured to the point that novice users need some guidance to get started with the software. This being a startup, we don’t have a tech writer, and I’ve added the relevant hat to my normal product management job–and rediscovering my deep respect for the profession.
A tech writer has to know the software better than anyone else from the user’s perspective, and has to understand the compromises, incomplete implementations, and other hazards of software well enough to explain to the user how it’s supposed to work in a clear, intuitive way. Tech writing reminds me of Henry Miller’s description of proof-readers in Tropic of Capricorn, which I took many years ago as a motto while working on the production of the second or third issue of Rag & Bone:
The world can blow up — I’ll be here just the same to put in a comma or a semi-colon. I may even touch a little overtime, for with an event like that there’s bound to be a final extra. When the world blows up and the final edition has gone to press the proof-readers will quietly gather up all commas, semi-colons, hyphens, asterisks, brackets, parentheses, periods, exclamation marks, etc., and put them in a little box over the editorial chair. Comme ça tout est réglé…
…A good proof-reader has no ambitions, no pride, no spleen. A good proof-reader is a little like God Almighty, he’s in the world but not of it.
So tech writers are a little like proof-readers–the release may blow up, but the tech writer will still be there updating the user documentation and taking the latest screenshots.
Which brings me around to the question at hand: the tension between the need for screenshots in documentation and the definitive non-agileness of it all. A thread on the Joel on Software Discussion Group questions the need for screenshots entirely but comes around to the concept that, yes, you have to retake the screenshots every time you update the GUI, and yes, it’s a pain in the butt, but it’s part of the cost of doing business. I was hoping for some more practical guidance: is there a rule of thumb on what to illustrate with a screenshot and what to leave out?
One of the downsides of being an early adopter in some areas is that I’m a late adopter in many others. I was using a desktop RSS aggregator back in 2002 (Radio Userland, then NetNewsWire) and so came late to the web-based news aggregator market. When I did hop on board, I used Bloglines, one of the early web based aggregators, and so missed out on Google Reader. I’ve stuck with Bloglines because it works and because it works well on the iPhone.
Yesterday, Bloglines wasn’t working. I haven’t seen anything posted about this, but while the site’s UI was up I didn’t get any new results for any of my 175 feeds from about 11 AM on. So in the early afternoon I decided to give Google Reader a spin.
One of the nice things about feed readers is that it’s pretty easy to take all your feeds to a new reader, thanks to OPML (one of Dave Winer’s many innovations in this area). Most feed readers support exporting your feed list to OPML, a structured XML format, and support importing feed lists from OPML. So you can pack up your feeds and easily bring them to a new place–minimizing vendor lock-in. I did that with my Bloglines feeds and was up and running quickly in Google Reader.
One thing that struck me almost immediately was the poorer UI in Google Reader. While it uses the same left pane navigation–right pane reading metaphor as Bloglines, the left pane is cluttered with a bunch of stuff on the top–starred items, trends, shared items and notes, a big help pane, and THEN your list of feeds. Bloglines’ feed list takes up the whole left pane and is just your content–much easier to manage–while other information like your personal blog and “clippings” are in separate tabs. If you’re just interested in reading feeds, Bloglines’ navigation is easier and less cluttered.
The right pane UI is a little better too, imho. I find the separate drop-shadowed feed boxes in the expanded view (what NetNewsWire used to call “smash view”) distracting; Bloglines’ zebrastriped list is visually flatter and doesn’t get in the way of the content. And I can’t imagine a use for the list view for most of my RSS feeds; though perhaps the notification-only ones are better suited for this kind of presentation, I can’t imagine trying to read BoingBoing or even Krugman this way.
Google Reader does feel a little snappier–feeds update more frequently and quicker. But the reading experience is actually slower, because items don’t get marked as read on display, but only if you scroll them off the screen. That might be beneficial for some people, but I’m a quick scanner and like to run through the feed list quickly. And because Google Reader doesn’t fetch all the items in a folder at once, dynamically fetching items as the user scrolls, there’s no way to quickly scroll to the bottom and read everything all at once. You have to wait for the fetch to catch up, then scroll to the bottom again.
So this morning I was pleased to see Bloglines is back online. I’ll still test out the Google Reader iPhone experience, because there are things that don’t quite work for me in Bloglines’s. But I’ll be continuing to use Bloglines in my browser.
I wrote previously about “technical debt,” the concept that the decision to defer necessary technical work (adopting an updated version of a new component, refactoring code to reduce cruft, etc.) accumulates across releases until it absorbs a project team’s entire capability to develop code. You “pay interest” on technical debt because it’s much harder and consumes many more resources to make a necessary technical change the further downstream you get from the point where the change becomes necessary.
It occured to me today that there’s a specific flavor of technical debt, security debt, that is both more insidious and much easier to see in operation, because we have so many prominent examples of it. It might not have cost the developers of Windows too much more to make the OS more secure at design time, but some of the decisions were deferred, until the point where you had whole features introduced to address security deficiencies in prior features, and the six month long security push that postponed Vista’s launch while the team took care of outstanding security issues in the already-shipped version of the OS.
What’s interesting about security debt to me is that it balloons over time. My once-favorite mix sharing site, Art of the Mix, is a good example. The guy who developed it didn’t really understand SQL injection or XSS, or at least didn’t code defensively against them, and it’s become a hive of malware as a result–and is now flagged as a “reported attack site” and blocked by Firefox 3. So, to carry the metaphor to its logical conclusion, the site’s security debt drove it into a kind of “bankruptcy” when it proved susceptible to drive-by SQL injection attacks.
So how do you avoid incurring security debt? Learning good development practices is a good start; keeping up on the prevalent attacks–the current risk space–is another. But there’s one key thing to remember about security debt: in many cases fixing the underlying flaw that permits exploitation is far far cheaper than getting hacked, or even putting bandaids like web application firewalls in place.
…because something tells me this race is going to be a rollercoaster for the next few weeks.
Screenshot below from the excellent Election ’08 iPhone App, from Pollster.com and Slate. For a more nuanced view, look to the fine folks at Electoral-Vote.com, which shows Obama’s lead 338 to 185 electoral votes, with 15 ties. This high margin is pretty new in the race–back in early September, the lead was only about 100 electoral votes.
For more context, check out the historical trends on Electoral-Vote.com, where you can see what happens if you don’t count the states with a less than 5% margin of victory (answer: we don’t have a clear winner yet).
With the WordPress 2.7 Navigation Options Survey, the fine folks at WordPress.org have opened the kimono on one of the trickiest product management tasks: user experience design. The context: the administrative interface of WordPress. The UI was famously redesigned earlier this year by Happy Cog studios, who applied a rigorous information architecture along with a highly readable visual style. So why redesign now?
Well, it appears that users didn’t like the way the dashboard used screen real estate. While the WordPress team doesn’t describe what the users complained about, the key navigation options are currently along the top, and I would guess that users who have widescreen monitors are pointing out that horizontal screen real estate is less precious than vertical. So the team has created a survey to get user feedback about some design options.
This is a tricky task, and it could have been made a little easier by some better user requirements gathering. For instance, what the team is fundamentally trying to do in identifying top-level command categories is classically served by “card sorting,” a classic usability design exercise. They might get better feedback by doing a card-sort study, either offline or with a software package like WebSort.
Second, the presentation of the choices doesn’t include a control. It assumes that all users prefer the vertical menu and presents variations on that option. Adding an option for the existing horizontal menu might present some valuable information on how users feel about the existing option.
My opinion may be tainted by my personal preferences; I’m one who finds the current administrative interface design preferable to what I’ve seen so far of the new direction. But regardless of my personal feelings, there’s something to be said for rigorous user centered design in determining the next direction.
There’s a cute comic up at WPLover that highlights an interesting UI trend: the rise of the speech bubble. If you don’t have a WordPress blog, you may never have seen this UI, but it’s pretty much as the comic strip shows it. In the dashboard UI, there are a series of tabs for common tasks–comment management, etc.–and if something needs your attention on one of those tabs, a “speech bubble” pops up with the number of things you need to address.
What the comic points out is that this makes perfect sense for comments (a speech bubble with the number of comments is a congruent metaphor). But indicating the number of plugins needing updates is a little different–should your WordPress plugins really be talking to you?
I think the first treatment of this concept that I saw was Apple’s new mail count in Mail.app, but they didn’t treat it as a speech bubble (there was no “tail” on the little red badge showing the count). This treatment is probably the more portable UI convention.
After the difficulty I had with the WordPress 2.6 upgrade, I was both hopeful that 2.6.1 would fix some of the bugs, and a little hesitant about the upgrade. Apparently both my anticipations were incorrect. WordPress 2.6.1 was released yesterday, and while there’s no explicit mention of the admin cookie bug that I hit on the 2.6 upgrade, my own upgrade to 2.6.1 was pretty easy.
The full fixed bug list is on the WordPress Trac, so you may want to see if there’s any fixes you need. As another commenter pointed out, there are few security fixes, but that doesn’t mean there aren’t any–the thing about a plugin without headers not appearing on the plugins page raises concerns about hidden malware that might be worth upgrading to avoid. Just remember to clear your cookies before you try to log back into the admin console after the upgrade.
According to Matthew Marlowe’s Blog, VMWare instances running ESX 3.5U2 in enterprise configurations have a license management bug that will prevent them from starting, beginning tomorrow.
The post has turned into a list of pretty helpful tips, including:
- A link to the VMWare KB article that has status updates
- Turn DRS off (or set sensitivity to 5)
- Avoid VMotion
- Avoid powering off VM’s
While the licensing bug does not appear to be related to security issues, this is a pretty good reminder of how mission critical hypervisor software is. It should be held to the same standards as operating systems.
I was about to delete an email from Bob Cramblitt on my old blog, until I actually read it and realized it was relevant to at least some of my readers:
Thought you’d like to know that Seth Godin, Joel Spolsky, Jason Fried and others are coming to Boston for the Business of Software 2008 conference. This is the only conference run by people who actually manage successful software companies. All substance, no BS and not a Web 2.0 to be found.
Your blog readers can get $100 off registration by entering “MASS” when registering at www.businessofsoftware.org.
So there you go. Never let it be said that reading my blog got you nowhere. (Disclaimer: this was my only contact with Bob Cramblitt and I’m not getting anything for posting this.)