P16: Practical Progress

Website security audits -- how to get on the right track, for web startups

Someone asked me a rather interesting question today, and I'd like to share it (and my reply) with you.

Imagine you're in charge of a internet startup. You haven't launched yet, but the product is coming together and you'll be launching and promoting it soon. Everyone on your small team is working flat-out and doesn't have a second to spare for anything. At. All.

In one of those seconds you didn't have to spare, you think, "How do I ensure our website is secure?" So you don't have a big, gaping security breach on your shiny-new webapp the moment it gets some positive press?

Usually the answer is "Ack! I don't have time for this!" and you move on. Maybe you cross your fingers the next time the thought crosses your mind.

If you happened to be product manager within Yahoo!, instead of a startup, you'd have access to a wonderful resource: the "Paranoids". They're a highly experienced security assessment team who can quickly and clearly spell out best practices, find the booby-traps in your code, and smack your developers' wrists when necessary.

Alas, Yahoo still hasn't bought your startup yet. What now?

BusinessWeek article on Daylife.com

Have I mentioned that I have a new gig? We were just written up in BusinessWeek.

BusinessWeek: Redirecting the Web's News Stream

If that went over year head (it did for me), here's a simpler explanation of what we do:

Daylife: a guide to today's news

(ps: According to our homepage, George Carlin just passed away...)

Why DRM and the DMCA sucks, part 27,541

Dear Amazon.com,

You really should get out of the business of making e-book readers. Not that there's anything wrong with the Amazon Kindle, your wireless reading device. But I don't want yet another gizmo to carry around. I want to read e-books on the devices I already have.

Please stop trying to build e-book readers. Instead, let other developers build them, legally. Let a thousand e-book readers bloom.

The Kindle uses an e-book format from your subsidiary Mobipocket. I bought an e-book from Mobipocket -- once. I read it on my Nokia E62 using the Mobipocket Reader for Symbian OS. It was a crappy experience. Oh, it was nice being able to read on the subway, one teeny screen at a time. But I would have much preferred to read on the larger screen of my Nokia N810.

When I was done, I wanted to refer to some passages I'd highlighted. Ideally, I'd do this on my Macintosh laptop. Unfortunately, Mobipocket doesn't have reader software for the Mac (!?!?). So I wound up using VMWare to run a copy of Windows to... just look up a passage in that e-book.

That was an awful set of hoops that you made me jump through, Amazon.

Oh the ironies of this situation. Amazon has an MP3 Download service, which offers non-DRM'd music unlike iTunes. But DRM copy-protection is exactly the thing that keeps me from reading that e-book on my N810 using FBReader.

Conflicting priorities:

• Mobipocket (and Amazon) don't have unlimited budgets to build and support e-book reader programs for every random gadget in the universe
• The universe of pocket-size gadgets that could be e-book readers is expanding, not contracting
• I would love to step into this fray and set things straight, but I don't want to become a martyr like Dimitri Sklyarov

Amazon -- you can fix this situation. Create a web service to decrypt Mobipocket e-books. Make it accessible to registered developers who sign a terms-of-use agreement and agree to take reasonable steps within their programs to prevent unauthorized copying. Heck, you can even verify ownership of the e-book when the service is called.

You already have a thriving web services business. This should be a no-brainer for you.

If you don't want to invest in this right now -- heck, I'm willing to build this service and market it to e-book software makers, if and only if you provide me with legal indemnification so none of your publishers sue me under the DMCA.

Because... even though this could be a really nice niche business, and it would clearly benefit the e-book and publishing industries if implemented, all I need is one publisher's lawyer with his knickers in a twist to make me a fuckin' grease spot.

Until then, I'll stick to paper books.

A recipe for web-startup success

This week several big-name pundits spoke up about what, if you're running a web startup, one should do to prosper:

• Jason Calacanis: How to save money running a startup
• Michael Arrington: Startups Must Hire The Right People And Watch Every Penny. Or Fail.

Fine, do those things. Buy a fancy espresso machine and cheap desks and nice chairs and 2nd monitors. Lots of distractions gone. Then what? What do you focus on?

Marc Andreessen has claimed, "the only thing that matters is getting to product/market fit". I agree -- but how do you achieve this?

You have an idea for a web startup. You want to build it, and you want it to be a big success. Where do you start?

I'm not as famous as these guys, but I've seen many web startups up-close. I've had my skin in the game. I even just had an old friend ask for my opinion about it this week.

So here's my answer.

One recipe for web-startup success

Take your awe-inspiring, world-changing idea. Apply Occam's Razor ruthlessly, stripping away every aspect that is not essential. Keep cutting until you arrive at a core value proposition for users -- the reason anyone will care. Now design the simplest possible website that actually delivers this promise. Describe the whole website as closed-circuit -- no undefined link destinations.

Pare it down again and again. Can you see the entire web site in your head yet? Every navigation element, every piece of content? Nope? Then keep cutting.

You want a complete, coherent design for the simplest-possible website that delivers on your value proposition.

When you can finally describe the whole damn product in a handful of page-sketches, and how every UI element should behave -- only then should you:

• Build it (yourself, or hiring people)
• Start promoting it
• Run like hell

Why? Because you want to save money! And you want to get to product/market fit as quickly as possible!

Writing code takes time. If it's not your time, it's someone else's and you're paying the bill. Save time and money by writing less code. Debug less code by having less code. Get to market fast by knowing what to build. Verify your idea in the marketplace faster using a real implementation in a real timeframe.

Nearly every startup I've ever seen tries to avoid this process. It's easier to just start building something. Hire a team, let them figure out the details. Action feels good! The problem is, I've never seen this work -- not once. The missing pieces never fall into place on their own.

Plant the wrong seed, grow the wrong roots. Simple as that.

If you're having trouble getting to a radically stripped-down vision of the product, you could try:

• use-case specifications
• wireframe mockups
• "build one to throw away"

But these are just "planning tools". They're only good helping you when you hit a dead-end mentally. They are not a substitute for the end result -- a radically actionable plan.

And... If you never get to the radically stripped-down plan that is actionable and would be valuable to users on day #1 -- maybe it's just not worth building. Seriously.