Month: April 2005

Michael has my comment to his comments on my earlier post about Evan Williams’ post on web applications (Good god! Let’s just say we’re having a conversation).

He considers the fact that web app hosters have root access to your data a point against web applications, as a hosting insider could do any number of undesirable things with the data.

It could be argued that the same applies to internal IT staff. Your IT guy could be selling company email addresses to spammers on the side, for example. I agree, though, that when a hosting company does it, they are probably better organized and can do more damage.

Michael also points out the dearth of APIs for web applications, which I agree is regrettable. On the other hand, there’s no technical reason that a web application can’t have a decent API for manipulating its data. We’ve come to expect API’s for local applications, why not for web-based ones?

I just discovered feedmap, a website that tracks RSS (and Atom) feeds by geographical location. Very cool! (via Scobleizer)

Larry Borsato is a prolific blogger, averaging a Scoblian 6-7 posts per day by my count, writing on a wide variety of topics ranging from the Kyoto accord to note-taking; but, from what I gather, mainly Canadian politics, marketing, and technology. Judging by his resume, he also has god-like powers when it comes to marketing technology. He reads gapingvoid and Paul Graham. What’s more, he lives in Waterloo!

Blog on, Waterloo!

It’s nice to see AMI Semiconductor’s DSPs getting some press. Electronicstalk has a story about Phonak’s SmartLink SX:

Through built-in microphones, audio inputs, and a Bluetooth link, the highly compact SmartLink receives and processes audio signals and transmits them to the user’s hearing aid using Phonak’s industry-leading MicroLink technology.

Michael is leery of using web applications for business, writing

I don’t know if I’d want to take the risk of having my corporate data spread over several vendor’s applications and servers, but there is some appeal in handing over the technical, administrative and security tasks to someone else willing to take on that pain.

I’ve heard similar concerns about the risk of using web applications before. I suspect they are greatly exaggerated.

The arguments usually goes something like this. If my company’s data is kept on web application, there is a chance that the web application will be cracked and my valuable data will find its way into the hands of my competitors or other unscrupulous agents eager to apply it to some nefarious endeavor sure to harm me. If I spread my data across several applications the risk is multiplied because it increases the odds that one of the applications will be cracked. On the other hand, if I keep that data centralized within the company, protected by my IT people, it is safe from outside crackers because I control it.

I find some things fishy about this argument.

First, why should I expect that my IT people will be any better at securing my data than a web application sysadmin? It would stand to reason that a web applications would be more secure. As Paul Graham argues:

The argument against this approach usually hinges on security: if access is easier for employees, it will be for bad guys too. Some larger merchants were reluctant to use Viaweb because they thought customers’ credit card information would be safer on their own servers. It was not easy to make this point diplomatically, but in fact the data was almost certainly safer in our hands than theirs. Who can hire better people to manage security, a technology startup whose whole business is running servers, or a clothing retailer? Not only did we have better people worrying about security, we worried more about it. If someone broke into the clothing retailer’s servers, it would affect at most one merchant, could probably be hushed up, and in the worst case might get one person fired. If someone broke into ours, it could affect thousands of merchants, would probably end up as news on CNet, and could put us out of business.

Second, does keeping all the data centralized really reduce the risk? If a cracker gets into a central database, he’s hit the jackpot. He’s only got to crack one system. If the data is distributed across many web applications, he needs to crack into every one to do the same amount of damage.

Third, what is the danger of having the data publicized? Is the data really as valuable as you think? Consider this thought experiment: imagine that somebody cracked into Intel and managed to steal the source code for the design their latest processor, arguably their most valuable data, and posted it on the web for all to see. End of the world for Intel? I don’t think so. For the vast majority of people the code would be worthless. Unless you have access to a multi-billion dollar fabrication facility, it would be impossible to manufacture cheap knock-offs. Those that do have access to such a fab would have to invest considerable effort in learning how to build the chip, as manufacturing chips is not a straightforward process.

So for the sake of argument, let’s say along with the source code, the cracker also managed to publicize all of the process documentation, too. Then they could make the chip without a huge investment, right? I don’t think so. Though it might reduce the effort to manufacture the chip, it wouldn’t eliminate it. Somebody would still have to read all the documentation and understand it. There would be gaps in the documentation, too; information that resides in the heads of Intel employees that was never written down. Somebody would have to figure all that out, too?

But couldn’t somebody use the source code as the basis for an enhanced chip; something even better than what Intel is producing? Possibly, but Intel will be doing the same thing. Who do you think will come up with the better enhancement, the Intel engineers who developed and are intimately familiar with the code or somebody who has never seen the code before? My bet is on the Intel team.

Would it be a different story if we imagined that source code was for Microsoft Windows or the Google Internet Search routines. I don’t think so. Anybody considering competing with the creator would still have the same issues of understanding what they have stolen and building the product for themselves.

So there you have it: three reasons web applications are not as risky as you might think. They’re probably full of holes. Poke away.

In Happiness helps people stay healthy, New Scientist reports:

People who are happier in their daily lives have healthier levels of key body chemicals than those who muster few positive feelings, a new study suggests. This means happier people may have healthier hearts and cardiovascular systems, possibly cutting their risk of diseases like diabetes.

These kinds of stories annoy me. Reporters are so eager to get people to read their stories that they extrapolate a causal relationship from a mere correlation.

Scientist have discovered that happy people are healthier than unhappy people. Are people healthier because they are happy? Are people happier because they are healthy? Is there something other unidentified cause that results in people being both happy and healthy. However it turns out, I’m glad folks are investigating.

Johnnie Moore points toward Patricia Digh’s wonderful blog, 37 Days:

In October of 2003, my stepfather was diagnosed with lung cancer. He died 37 days later.

The timeframe of 37 days made an impression on me. We act as if we have all the time in the world – that’s not a new understanding. But the definite-ness of 37 days struck me. So short a time, as if all the regrets of a life would barely have time to register before time was up.

And so, as always when awful things happen, I tried to figure out how to reconcile in my mind the fact that it was happening and the fact that the only thing I could do was try to make some good out of it. What emerged was a renewed commitment to ask myself this question every morning: ‘what would I be doing today if I only had 37 days to live?’

It’s a hard question some days.

Among the many helpful links in Y Combinator’s startup resource page is alarm:clock, a blog about tech startups:

alarm:clock covers the business of technology startups. Each weekday, we add a new profile of a privately-held technology venture. We analyze the business model and tell you how the company fits in to the technology landscape. You’ll also find ongoing news and updates about the companies we cover and about the technology industry at large.