A company called Audible Magic is now offering an
“anti-piracy” network
appliance that purports to identify and block P2P file transfers of
copyrighted material, from a passive perch inside customers’ networks. From their press release:

Audible Magic’s CopySense (copyright-sensing) technology is based upon
patented techniques that generate digital fingerprints for audio content.
Fingerprints are generated by electronically “listening” to the song or
audio file, and do not depend on metadata imbedded in a file which can
be corrupted or changed.

But with easy, free, legal encryption — as is being widely adopted by
file-sharing software — passive network appliances can no more “listen”
to P2P file traffic than they can intercept credit card numbers.
Both kinds of user information can, and usually will, be protected by strong end-to-end encryption.

Thus this hardware solution — requiring physical installation, weekly
database updates, and a deployment cost that scales linearly with the amount
of traffic to be monitored — can be rendered permanently moot by a one-time
fixed-cost software upgrade, using free code libraries, making P2P
traffic opaque to passive eavesdropping.

That’s a radically asymmetric battlefield, with the technology and economics rigged against the forces of control.

Like the pre-World War II Maginot
Line, it’s an impeccable defense against a static, simpleminded attack — but utterly worthless against the inevitable enemy adaptation.

Digital copy controls work no better inside the network than they do at the endpoints — unless
you expect encryption to be outlawed.

And if encryption is outlawed, bayl bhgynjf naq glenagf jvyy unir cevinpl.

What do you think?

Related link: http://www.ventureblog.com/articles/indiv/2003/000203.html

VentureBlog’s Naval Ravikant visits the Dartmouth campus for the Unleashed Conference, and thanks to the ubiquitous wireless computing there, sees the clear outlines of our near future. My favorite of his observations:

• Instant Messenger for voice will emerge [and will eventually be packaged in a hearing-aid sized device]
• Voice is just an app [”The phone companies will suffer mightily.”]
• Un-terminated [many — perhaps most — wireless access points can do without a landline uplink]
• Bandwidth matters! [people find uses to fill all the local wireless bandwidth — including file sharing — despite slower landline uplinks to the outside internet]

These are just a few of his insights — check out the rest at: Ubiquity Breeds Utility.

Is that guy mumbling to himself engaging in Voice IM with a tooth-mounted microphone and WiFi earbud? Or just insane?

I admit it. Despite having ample private indicators, trends, and statistics on just how well my books are doing, I still hit amazon.com every now and again and search for my name. There’s just something cool about seeing the live page rank of something I wrote, particularly when people are actively talking about it.

Imagine my surprise the other day when searching for “flickenger”, I suddenly got 20 or so results (rather than the four I usually see). Apparently, amazon was searching not only for title and author, but was grep’ing the actual content of some of its books.

There I read about a Flickenger who was a pilot in WWII, whose B-17F (”Werewolf”) went down in fiery glory. Then there was LTCOL Don Flickenger (not the same man?) who was a pioneer of pararescue in 1943. There are also references to doctors, anthropologists, chemical engineers, and environmentalists who all share my (fairly unique) last name, but none of whom I’ve ever met.

Then, just as I went to show this crazy new feature to a friend, it suddenly disappeared. Apparently, a beta test got leaked to the production servers for a couple of hours, and I happened to get lucky.

Well, it seems that the feature has just gone live. As of today, Amazon allows full-text search for many of its titles.

It’s an eerie ability, sort of an extension of the omniscient feeling one gets when digging around in google or the Internet Archive. It extends easy search capabilities to printed material, which fights the old addage about grepping dead treees. Of course, you’re limited to a subset of Amazon’s catalog (and not every book ever printed), but it’s still an insanely useful feature.

With Amazon’s web services initiative, it could lead to all sorts of interesting implications. Imagine if your local library had the ability to search the entire contents of its store of books, quickly and free of charge, and not only told you instantly which books were relevant, but offered to deliver them to your door for a reasonable fee. Good heavens.

If you could do a full text search on every book ever written, what would you use it for?

Here’s an interesting article from Computerworld talking about the success of Schlotzsky’s free wi-fi service. For an outlay of $8000 per store, they are seeing roughly $100,000 in increased sales per year in each of their 30 stores which offer free hotspots.

But Schlotzky’s isn’t the only free wireless successs story. Ron Shaich, chairman and CEO of Panera Bread, sees free wi-fi as something that customers should expect as a courtesy, as it is very inexpensive to operate and entices customers not only to stay, but to come back.

Here’s a choice quote:

In fact, Shaich considers free Wi-Fi to be such an essential marketing tool that he dismisses any discussion of ROI. “What is the ROI on a bathroom?” asked Shaich, pointing out that the day of pay restrooms in restaurants has long since passed.

When considering for-pay and for-free hotspots (as well as truly free network projects), I can certainly see the value in one free resource that makes all of these valuable propositions possible: public spectrum. None of these communication services would be possible without license-free portions of the public airwaves (FCC Part 15 here in the U.S.) Tell your government how important free access to the public airwaves is to your business and community!

Is free wireless access to the Internet a valuable resource, or a waste of spectrum?

Related link: http://www.bayarea.com/mld/cctimes/news/transportation/6831579.htm

In October 2000, a Village Voice article described the torturous procurement process for New York City’s MetroCard transit pass. I doubt the main storyline is at all surprising, since it’s the age-old attempt of proprietary software developers to lock in customers.

In this case, the New York Metropolitan Transit Authority (MTA) contracted out all the development work for a new system to Cubic Corporation. Cubic retained all the rights to the support systems, such as ticket vending machines and fare gates, for the MetroCard. Although there was an initial competitive bid for the system, Cubic owns the rights and therefore only Cubic can perform ongoing maintenence and development. Additional features require contract extensions, as do bug fixes. According to the article, nothing has been competitively bid for a decade. (If that trend continued since the article, it would be 13 years by this point.)

The fundamental problem the MTA faces is that Cubic has an great deal of power as the sole supplier of a proprietary system. Andrew Friedman, the author of the Village Voice article, ends with a discussion of open-source development of transit software as a way for transit agencies to regain some power as buyers.

It’s an interesting proposal, but one that probably isn’t necessary. Transit authorities need to create some competition in the system. Open-source development certainly creates competition, but so would the development of industry standards. Create a standard fare card reader, and let the developers implement the standards and compete on the quality of their implementations. (I suspect that it is more efficient to have developers competing on standards-based products than to have many public transit agencies the world over getting into the software development business, but that’s just an off-the-cuff opinion.)

Customers in the market for network hardware keep their hardware vendors honest by insisting on standards-based products. There is no open-source Ethernet hardware, but there is a whole universe of Ethernet switching hardware, all built to adhere to standards. Discipline comes because customers insist that vendors adhere to the standards. Once the decision is made to move all the data around a network in Ethernet frames, there is a choice of several vendors of Ethernet switches. Standards ensure that buying from one vendor today does not preclude going with another vendor tomorrow if the first vendor screws up, so there is an incentive to continue to serve customers.

Getting standards off the ground will take time, though. (For all I know, public transit agencies may already be thinking in that direction.) In the meantime, though, a second approach comes to mind. Retain rights to the software. I was pleasantly surprised to see this in the paper a few weeks ago. In the San Francisco Bay Area, public transit is a mess. Multiple agencies are responsible for overlapping areas of coverage and modes of transit. Every agency has its own fare structure and transfer policies, so it’s often confusing to know what the right fare is and how to buy the right types of tickets. Most other systems throughout the world are simpler: you buy a ticket, and it’s good for the whole region. You can even buy unlimited usage tickets that make it possible to transfer between trains and buses with no hassle. The Bay Area has no such integrated ticket, but the Metropolitan Transit Commission is taking baby steps toward it with a universal smart-card based ticket called Translink.

Translink hasn’t been without it’s setbacks along the way, but at least ownership of the system shouldn’t be a particularly big problem. The second to last paragraph says that “[t]he agency [MTC] also owns all the rights to Translink software, which means it could give the system to another operator.” We may not have standards keeping the developers honest, but the ability to give the code away should serve the same purpose.

One note on the content: the article describes BART’s refusal to participate in the Translink system. BART announced an agreement on Thursday, September 25, three days after the front-page article in the newspaper.

Last week, I had the marvelous opportunity to meet Stuart Cheshire, one of the founding fathers of Apple’s Rendezvous implementation. (If you haven’t heard of Rendezvous, think of it as a simple way for computers on a network to find services, without the need for a sysadmin to set anything up.)

Poor Stuart. He heroically volunteered to throw a couple of impromptu Rendezvous sessions at FOO camp, the last of which ran pretty late. And what talk would be complete without a pile of nifty Rendezvous-enabled gadgets and a live demo using the local wireless network, feeding directly to the video projector?

What a trusting soul. Of course, he couldn’t possibly know that a third of the audience was made up of wireless hackers who have been fiddling with Rendezvous for well over a year. Seeing that Stuart was about to demo a nifty little Rendezvous print server dongle, some nameless troublemaker in the audience fired up RendezvousBeacon, and created a new “printer service”:

And so, when Stuart Cheshire, champion of Rendezvous and hacker extraordinaire, went to select his printer device from the list of available Rendezvous printers, he (and everyone in the audience) saw this:

Things just got funnier when he fired up SubEthaEdit (formerly Hydra). Five or six of us (er, them ;) in the audience already had it running, and started a running commentary of the presentation. No one (not even Doc Searls) was spared from the now interactive video projector.

And don’t even get me started on the fun we had with Safari and advertising available web sites.

Taking it all in stride, Stuart managed to reign in the laughter from the audience and bring the point of the exercise home: Rendezvous is tremendously powerful and easy to use, even for the beginner. It presents network information (which has a history of being unintelligible and involving yucky looking hex numbers and dotted quads) in plain English, or indeed, plain UTF-8.

This was just one of the innumerable FOO moments of the weekend, where phenomenally bright people continually tried to out-hack each other, not for ego or some sort of “cred”, but in celebration of the possibilities of technology. Whatever you might hear about FOO camp from other circles, it was unquestionably a fun (and stimulating!) weekend for all who attended.

Seen any neat Rendezvous tricks?

Related link: http://csrc.nist.gov/publications/drafts/Draft_SP_800-38C_9-04-2003.pdf

One of the major tasks for 802.11i is to shore up the link-layer security of wireless networks. In the short term, security is improved by adding a enhancements on to standard
RC4-based WEP. (The most notable enhancements are the Temporal Key Integrity Protocol, TKIP, and the Michael message integrity check. The Wi-Fi Alliance has branded these as Wi-Fi Protected Access, WPA.)

Many in the industry views WPA as a stopgap measure intended mainly to buy time to get link-layer security right. 802.11i has always included a privacy algorithm based on the Advanced Encryption Standard (AES). It has always been a stated goal that the AES-based encryption in 802.11i should offer the strongest level of privacy possible. One way that the goal is often phrased is that 802.11i should offer security mechanisms that allow deployment of 802.11 networks without requiring extra network components for encryption. Put another way, 802.11i is designed to offer cryptographic security over the air equivalent to IPSec.

U.S. Government agencies are required by Federal Information Processing Standard (FIPS) 140-2 to use only approved cryptographic components to protect “sensitive” data. Obtaining approval for a cryptographic module, such as a networking component, has two major steps. First, the module must use approved encryption ciphers, and the ciphers must be used in approved modes of operation. Second, the actual product itself is subject to extensive testing and validation to ensure that it meets FIPS requirements. FIPS certification is quite difficult, but often important for manufacturers of security products because it is often a requirement for purchase. U.S. government agencies are required to use FIPS certified products. Companies that do extensive business with the government may be subject to downstream application of FIPS, or they may adopt the requirements as a “best practice” security procedure to satisfy security auditors.

802.11i includes both RC4-based encryption (the collection of protocol mechanisms that make up WPA) and the AES-based algorithm called the Counter Mode CBC-MAC Protocol (CCMP). The flawed design of WEP, and fact that WPA is simply a patch, make it unlikely that WPA would ever gain FIPS approval. CCMP is based on a FIPS-approved cipher, and is the future of wireless security at the link layer. However, CCMP cannot currently become FIPS-approved because it uses an unapproved mode.

On September 4, NIST released a draft of Special Publication 800-38C, the main document linked above. If adopted, it would be the first step in gaining approval for 802.1X-based solutions in sensitive, security-conscious networks. Many of the existing networks were built years ago, in the bad old days of easily cracked static WEP. What many administrators have discovered is that VPNs impose a significant performance tax, and there is often significant network administration overhead to run them. With NIST working to approve CCMP in principle, it opens the door to build networks based on 802.11i, without requiring the use of a VPN.