Yesterday somebody defaced this site. This trashed the database that backs the site, so we had to restore it from a backup. Everything seems to be back to normal, except that any comments submitted after the backup (about two days ago) were lost. Sorry for the inconvenience.
Silver Bullet Podcast
August 31, 2006 by
Today we’re getting hep with the youngsters, and offering a podcast in place of the regular blog entry. Technically speaking, it’s somebody else’s podcast – Gary McGraw’s Silver Bullet – but it is a twenty-minute interview with me, much of it discussing blog-related issues. Excerpts will appear in an upcoming issue of IEEE Security & Privacy. Enjoy.
Don't Be Evil, Yet
August 30, 2006 by
Mike at TechDirt writes:
As everyone is talking about Google’s (not particularly surprising or interesting) move into offering hosted business apps (basically taking their existing mail and calendar apps, and allowing you to run them for your business), it seems that the story of AOL’s new download software being criticized for secretly installing plenty of additional apps is perhaps more indicative of the drive away from client-side software. These days, it’s gotten to the point where you basically can’t trust any downloadable software at all not to clutter your machine, whether on purpose or not. So, while many people tout the “access it anywhere” or “no setup involved” features of web-based software, the simple lack of additional annoying crud getting installed on your computer may turn into a powerful added incentive for moving towards hosted apps.
The TechDirt guys are usually pretty sharp, but I’m afraid they’re too optimistic here. I’ll grant that today’s web-based software tends to come with less crud than desktop apps, but I doubt that will last.
It’s quite possible to distribute crud with web apps. AOL’s download app installed a browser toolbar; but a web-based app can carry its own crud-filled toolbar – it just has to put that toolbar inside the browser window, just above its app functionality. The main difference is that web apps’ crud has to be displayed inside the browser window, which doesn’t seem like much consolation to a user who depends on the web app.
So why is AOL distributing crud with its app while Google isn’t? One possibility is that Google practicing its “Don’t Be Evil” motto. Another possibility is that the companies are at different stages of a standard software business model, which goes like this:
- build market share
- lock in customers
- profit from lock-in
Economics tells us that if a customer is locked in so that he would have to pay a cost of C (in money or hassle) to stop using your product, then you can extract extra revenue of C from that customer. You can extract that value by charging him a higher price or by subjecting him to hassles that he would pay C to avoid. In this case the hassle is crudware that the vendor is presumably being paid to deliver.
AOL’s client software is at Stage 3 of this plan, so it makes sense for them to be cashing in with crudware. But Google’s web apps are still at Stage 1, where the goal is to attract customers. The same is true, presumably, of most web-based apps – which means that once we all come to rely on web-based apps, they’re likely to start delivering crudware too. Being an early adopter has its advantages.
Next-Gen DVD Support Yanked from 32-Bit Vista
August 25, 2006 by
Microsoft has announced that the 32-bit version of its forthcoming Windows Vista operating system product won’t support playing commercially-produced next-generation DVDs (i.e., HD-DVD and Blu-Ray discs), according to Dan Warne’s story at APC. 32-bit Vista will be able to access the discs, reading and writing ordinary content, but they won’t be allowed to access DRM-encoded content such as major studio movies.
For those not up on the jargon, Vista is the next major version of Windows. There are different flavors of Vista for 32-bit processors and 64-bit processors. virtually all of the computers in use today, and most of the ones for sale in stores, use 32-bit processors, so they’ll run the 32-bit version of Vista – the one that won’t be able to play next-gen DVDs.
The reason, Microsoft says, is that the DVD cartel won’t license them the right to read DRMed content on 32-bit Vista. The problem is supposedly that 32-bit Vista allows the use of unsigned device drivers, while 64-bit Vista allows only signed drivers. To be signed, a device driver has to be approved by a special testing bureaucracy, according to criteria set up by Microsoft. (Device drivers are small programs that allow the system to interact with external devices or services.)
Optional signing of device drivers is a fine idea. Bad device drivers have caused many headaches for Windows users, so it’s good to give users more control over which drivers are on their systems. Users have to make choices about which drivers to install, and a Microsoft-sponsored stamp of approval, as provided by the signing process, helps users make that decision. All of this is helpful, as long as it is ultimately the user who decides what is safe to use on his computer.
But the reality is that lots of good and useful drivers are unsigned, because companies don’t want to subject themselves to the certification process. Competent users accept unsigned drivers all the time – my two-month-old Windows XP laptop has a few dozen unsigned drivers, many of which were pre-installed by the manufacturer.
In short, moving to 64-bit Vista, to get next-gen DVD playback with Windows, means giving up your current computer and some of your current peripherals and applications. You can be compatible with next-gen DVDs, or you can be compatible with the other stuff you use. Your choice.
Or you could just get one of the other Windows-compatible DVD player applications. According to an anonymous Microsoft source quoted at BoingBoing, Hollywood’s objection to next-gen DVDs on Vista-32 applies to Microsoft but not to third-party player applications like WinDVD and PowerDVD. Those apps will be allowed to play next-gen DVDs on Vista-32 and WinXP, even in the presence of unsigned drivers. If the goal is to stop piracy, this decision makes no technical sense. If unsigned drivers are a threat to DRM, it doesn’t matter whether those drivers are attacking a Microsoft-brand player application or a third-party application. So why did Hollywood refuse to license only Microsoft?
The BoingBoing source offers two hypotheses:
This leads folks at Microsoft to conclude either:
A) The studios don’t understand the technology enough to see these risks clearly, or
B) They just want to screw Microsoft
The studios all have tech consultants, and many of them are not fools, so A seems unlikely. B also doesn’t seem completely likely. It’s probably the usual: human stupidity rolled up in a big ball.
The stupidity-ball explanation is always a contender in cases like this, but I wouldn’t rule out A or B either. Yes, the studios have tech consultants, but they had equally good consultants when they chose the horribly misdesigned CSS as the encryption scheme for first-gen DVDs, which suggests that they don’t always listen to the consultants.
There’s an interesting connection to antitrust policy here. Microsoft’s business strategy is apparently to tie Media Player to Windows. Antitrust authorities, in Europe at least, didn’t like this, and so Microsoft is claiming that Media Player is an Integral Part of Windows and not just a nice application that is designed to work well with Windows. (Recall that they tried the same argument for Internet Explorer in the U.S. antitrust case, and the U.S. courts didn’t buy it.)
This may affect the DVD cartel’s decisionmaking in at least two ways. First, if they fell for the line that Media Player is not just another pretty app, they may have concluded that it made sense to hold Media Player accountable for the Windows “bug” of allowing unsigned drivers. This makes no sense from a content security standpoint, but remember that these are the same people who thought CSS was a good idea.
Another possibility is that the DVD cartel is implementing its own antitrust policy, encouraging competition in the market for Windows-compatible DVD players by neutralizing Microsoft’s tying strategy. Having acquired quasi-governmental power to regulate the design of DVD players and the structure of DVD-related markets, the cartel would naturally want to prevent any player vendor from accumulating market power.
All of this brings us back to Tim Wu’s paper about the drawbacks of putting one small group in charge of a whole economic sector. Markets may make good decisions – if they’re competitive – but there’s no guarantee that a single entity will make good decisions. That’s especially true if we put a small group of movie executives and lawyers in charge of technology design.
Great, Now They'll Never Give Us Data
August 23, 2006 by
Today’s New York Times has an interesting article by Katie Hafner on AOL’s now-infamous release of customers’ search data.
AOL’s goal in releasing the data was to help researchers by giving them realistic data to study. Today’s technologies, such as search engines, have generated huge volumes of information about what people want online and why. But most of this data is locked up in the data centers of companies like AOL, Google, and eBay, where researchers can’t use it. So researchers have been making do with a few old datasets. The lack of good data is certainly holding back progress in this important area. AOL wanted to help out by giving researchers a better dataset to work with.
Somebody at AOL apparently thought they had “anonymized” the data by replacing the usernames with meaningless numbers. That was a terrible misjudgement – if there is one thing we have learned from the AOL data, it is that people reveal a lot about themselves in their search queries. Reporters have identified at least two of the affected AOL users by name, and finding and publishing embarrassing search sequences has become a popular sport.
The article quotes some prominent researchers, including Jon Kleinberg, saying they’ll refuse to work with this data on ethical grounds. I don’t quite buy that there is an ethical duty to avoid research uses of the data. If I had a valid research use for it, I’m pretty sure I could develop my own guidelines for using it without exacerbating the privacy problem. If I had had something to do with inducing the ill-fated release of the data, I might have an obligation to avoid profiting from my participation in the release. But if the data is out there due to no fault of mine, and the abuses that occur are no fault of mine, why shouldn’t I be able to use the data responsibly, for the public good?
Researchers know that this incident will make companies even more reluctant to release data, even after anonymizing it. If you’re a search-behavior expert, this AOL data may be the last useful data you see for a long time – which is all the more reason to use it.
Most of all, the AOL search data incident reminds us of the complexity of identity and anonymity online. It should have been obvious that removing usernames wasn’t enough to anonymize the data. But this is actually a common kind of mistake – simplistic distinctions between “personally identifiable information” and other information pervade the policy discussion about privacy. The same error is common in debates about big government data mining programs – it’s not as easy as you might think to enable data analysis without also compromising privacy.
In principle, it might have been possible to transform the search data further to make it safe for release. In practice we’re nowhere near understanding how to usefully depersonalize this kind of data. That’s an important research problem in itself, which needs its own datasets to work on. If only somebody had released a huge mass of poorly depersonalized data …
