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.'"

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/ [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 [wikipedia.org]... Shoulda paid one of the drivers to deliver one of those Canon machines to my garage...

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

[Anonymous Coward]

Prohibitively expensive and time consuming (unless you want to make a 4 bit processor, some one did that recently by hand).

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:Urgh... some worse than others.

[Anonymous Coward]

No, no system randomizes the MAC address on boot. that would be insane.

Anyway, all systems allow you to set the MAC address for a NIC if you dont want to use the factory default.

ifconfig can change the MAC address on unixens, editing (i think it is) PROTOCOL.INI on windows does the same thing unless you already have a dialog in control panel for the driver for your NIC to do it through the gui.

If you change the MAC address, you should set it to an address that has the second least significant bit in the first octet to 1. This bit is called the "LocallyAdministratedAddress" and its whole purpose is that IF you set it when you change a MAC address, this bit will allow you to distinguis between globally unique MAC addresses (as you have in the factory default) and ones you have modified yourself and which therefore are not guaranteed to be globally unique. This to make it easier to see if it is your own fault or not if/when you get a duplicate mac on your network.

WRONG! iPhone application signing key not leaked!

[prxp]

The key published in tuaw's erica sadun's blog post is NOT the iphone's application signing key (as wrongly infered by Scheneier).
The key is actually an AES key for the DMG ram disk image file that is part of the iphone firmware update process. Nothing to do with application signing. The key doesn't even have enough size to be mistaken for an usable RSA key (I wonder if Scheier has noticed that).
Anyone can check that out on the various iPhone hacking blogs (and also on the very same one that posted this key in the first place).
People should get their facts straight before spreading misinformation.

Re:They said the same thing about cell phone numbe

[Kadin2048]

You need to read up on how the internet naming works before you make such ridiculous assertions.

In the GP's defense, telephone numbers worked like that at one point, too. It was basically a hierarchical system, where all the numbers beginning with a certain exchange would be physically connected to that CO. It just would not have been possible to take the same number from one part of a city to another, because the infrastructure didn't support it.

Telephone number portability only became possible when the telcos added an additional level of abstraction into the call-routing systems. This wasn't trivial -- the telephone switching system as it exists today looks almost nothing like the system that was around when the telephone numbering system was conceived and evolved. (Mechanical rotary switches that turned in response to the dial on your phone producing pulses; these switches cascaded, one after another, for each digit, routing the call.)

You could probably get 'portable email addresses' with some sort of extension to DNS; basically allow DNS records for individual email addresses instead of just domains. It would be a weird use for DNS, thinking of it as we think of it now, and in fact it might overwhelm the current infrastructure, but it's not impossible. Just probably more trouble than it's worth.

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 [e-mail], 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 "[e-mail]" than "[e-mail]", 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.