Bruce Schneier Weighs in on IT Lock-in Strategies

dhavleak writes "Wired has an article from Bruce Schneier on the intersection of security technologies and vendor lock-ins in IT. 'With enough lock-in, a company can protect its market share even as it reduces customer service, raises prices, refuses to innovate and otherwise abuses its customer base. It should be no surprise that this sounds like pretty much every experience you've had with IT companies: Once the industry discovered lock-in, everyone started figuring out how to get as much of it as they can.'"

Comments

Re:As in...

[trolltalk.com]

lock-in = subscription based business model...for those that don't know :)

Nope.

Lock-in is anything that creates barriers to moving to a competitor. For example, file formats. Or email address non-portability between different ISPs (or freemail providers, for that matter). Or (in the case of telecoms) number non-portability.The subscription model is one of the ways to milk extra bucks from lock-in, but it isn't itself a "lock-in."

Re:Build-your-own systems are starting to look goo

[milsoRgen]

http://www.opencores.org/

As far as the cost of getting one of those built, I'd like to know that myself... Reminds me when I was part of the crew dismantling the old fabs responsible for the Z80... Shoulda paid one of the drivers to deliver one of those Canon machines to my garage...

Re:As in...

[Sciros]

That's completely wrong! A lock-in is when the consumer is "stuck" with a particular vendor. This may be due to any number of things, but subscription is not one of them. A subscription-based service only locks you in if it makes unsubscribing difficult (which may translate to costly), which has nothing to do with being a subscription-based service in the first place.

A company that runs on a subscription-based business model would *benefit* from lock-in (to keep subscriptions going), but it doesn't have to do it. Magazines don't lock you in, neither do websites with subscription-based access (e.g. IGN, or newspapers), etc. You're always free to cancel and subcribe to something else if you wish.

Re:As in...

[misleb]

Or email address non-portability between different ISPs (or freemail providers, for that matter).

This being an unintentional form a lock-in, of course. You wouldn't actually expect an email address to be portable, would you?

-matthew

Re:As in...

[Kadin2048]

Portability for phone numbers makes sense, because they are just arbitrary numbers and AT&T can give you 12345 just as well as any other provider. They can now. This is a relatively recent development. The old rotary-pulse dial switching system didn't allow for such things, and although numbers might have appeared arbitrary to the customer, they were anything but to the phone company. Individual phone lines (last four digits, in our current numbering scheme) were connected to exchanges (first three digits of the 'phone number,' but in the past these were lettered or had other designations, like city or town), and if you moved from one exchange to another, your number changed. The phone number actually drove the routing equipment -- you couldn't just give someone a random 7 or 10 digit number and make it work. (Similar to how IP routing worked under classful networks.)

Over time, telephone call routing got more flexible. I'm not familiar with exactly how it works today, but there is obviously another layer, probably many layers, beneath the "phone number" you use and remember. That has been abstracted away from the actual 'hardware' and can be assigned arbitrarily.

Email addresses are currently hierarchical, in the same way that phone numbers used to be (under exchanges). If you want to send it to bob@company.com, you first send it to the mailserver for "company.com" and then it sends it on to Bob. But that's sort of an arbitrary design consideration. If you wanted to have a different MX record for "bob@company.com" than "joe@company.com", there's no fundamental reason why you couldn't, provided you were willing to completely trash and rewrite the DNS servers and MTAs.

More usefully, rather than screwing around with DNS, the best way to accomplish email portability would be to build another layer of abstraction on top of email as it currently exists. Instead of remembering people's emails, remember their real names or handles, and then have your email program consult some sort of global distributed database in order to find their email address (which would change whenever they moved ISPs or networks). Then you could change emails whenever you wanted and the people sending you mail would never know; it would all be hidden below the user level. And in fact there are some electronic-mail systems (e.g. Lotus Notes) that don't operate using user and domain names, and have their own systems allowing for more flexibility.