An interesting bit of corporate research was recently performed by
the EFF's Seth Schoen, who attended the Microsoft Windows Hardware
Engineering Conference and wrote up a four-part report on what he learned
, part 2
, part 3
and part 4
The resulting picture suggests that Microsoft is going out of its way to
appease the entertainment industry with its future products. Upcoming
Windows releases will be able to ensure that no "unauthorized" hardware or
software exists on the system. Load an application which the "protected
media path" code does not like, and much of the system's multimedia
capability could be shut down. A Microsoft-controlled "revocation list"
will allow drivers to be disabled by Microsoft in the future should those
drivers be determined to not properly implement the DRM specifications.
Overall, it is a vision of a world where "our" computers are, increasingly,
not under our control and not operating in our interests.
The comments on the original LWN
posting pointing to Seth's reports suggest that many readers believe
that this sort of intrusive DRM technology will provoke a massive consumer
backlash and, as a result, fail in the market. There are some signs that
this hope could be realized; there is currently a fair amount of grumbling
in the U.S. over the HDCP copy-protection mechanism, which can prevent the
delivery of high-resolution video to large numbers of high-definition TV
monitors which do not implement HDCP. As others have often said: Americans
will put up with all sorts of misbehavior from both governments and
corporations, but they will not tolerate anybody who messes with their TV.
All of this may be wishful thinking, however. It may well be that the
industry will get its DRM technology working to the point that it no longer
interferes greatly with the life of the average couch potato. If things
"just work" for most people, they will be accepted by those people. Few of
us have the time or knowledge to worry about the larger issues of fair use,
control over our own systems, or long-term sustainability of the cultural
commons. After all, there's a game on in a few minutes.
Consider also the reports
that Apple is planning to make use of the trusted platform module (TPM)
chip in its future kernels. The primary purpose here, most likely, is to
keep people from running Mac OS on non-approved x86 systems. But it
is hard to believe that Apple would not also use the TPM, for example, to
help ensure that audio files do not escape from the one system where they
are authorized to be.
Then consider that the latest Linux kernel includes basic TPM support, and
work is underway to increase that support. As was discussed at the Ottawa Linux Symposium, the
TPM can do a number of good things for Linux users. It can also, however,
be used to deprive a Linux user of control over the system and implement
all of the same DRM stuff which is being added elsewhere. A Linux-based
set-top box could be just as user-hostile as one based on Windows.
Availability of source would not be helpful in such a situation; the TPM
can be used to ensure that the system will boot only kernels which have
been signed with a specific key. Linus Torvalds has stated in the past that this sort of usage is
fine with him.
Now, Linus is not the only copyright holder for the kernel, and others may
yet decide that the GPL requires that the keys used to sign the kernel be
distributed with the source. The GPL's source distribution requirements do
"the scripts used to control compilation and installation of the
executable," after all. It may even be that a court will buy that
argument. But any such finding will be at the far end of a long process of
litigation; it is an uncertain and distant prospect. In the mean time, it
is safe to assume that we will see more systems which, while running Linux,
allow no more user control than their equivalents based on proprietary
At OLS, Jim Gettys compared the DRM situation to the American experiment
with crypto export regulations. We'll win in the end, but there may be a
decade or two of pain in the middle. Sadly, it appears that we are just
beginning to enter the "pain" phase of this battle. This is a fight
we can win; we will likely be helped by the fact that the entertainment
industry will have a hard time stopping short of the point that makes
consumers rebel. But there may indeed be some unpleasant times between
here and there.
Comments (16 posted)
The story has been sufficiently widely reported that we do not need to go
into the details here; see Bruce
if you have some catching up to do. In short: Cisco
is going after ex-ISS employee Michael Lynn after he made a presentation in
Las Vegas on security vulnerabilities in Cisco's IOS. There is now an FBI
investigation in the works, and Mr. Lynn faces the possibility of lawsuits
from Cisco or ISS (or both). Meanwhile, copies of his presentation are
circulating on the net, closely followed by lawyers with takedown notices.
BoingBoing has posted a
list of mirrors
for those of you who have not yet gotten your copy.
Cisco's argument is that Mr. Lynn's presentation discloses Cisco's trade
secrets. By this reasoning, Cisco's customers are not entitled to know
about vulnerabilities in the boxes they have used to put their networks
together. In fact, it appears that Cisco has known about this
vulnerability since April, but did not see fit to tell its customers - or
anybody else - about it until after Mr. Lynn's presentation.
Cisco's concern for its public image has clearly outweighed its
concern for its customers' security. The company has turned against
disclosure of security problems, and also seems to have forgotten what the
net has taught us over the last twenty years or so: attempting to suppress
information which has escaped onto the net is not only futile, but it
increases the distribution of that information.
There is another aspect of this situation which is worth looking at,
however. It has often been said that users of embedded systems do not care
about which operating system is running inside. The system is invisible,
and all that matters is that it does its job.
Security problems clearly increase the visibility of an embedded system.
But so do trade secrets, and in an unpleasant way. If Cisco's routers ran
Linux, there would be no question of the company using trade secrets to
shut down disclosure of vulnerabilities in the core system. There cannot
be trade secrets embedded within GPL-licensed code - at least, any such
secrets will not remain secret for long. So an attempt to use trade
secrets to block disclosure of a security problem is almost certain to
This is a good thing, and a nice added benefit from the use of free
software. People may not care about the code running inside their router,
phone, music player, automobile, or Furby, but they may yet learn to care
about having vulnerabilities in those devices hidden from them. Among the
many promises carried by free software is this one: it does not contain
secrets which may be used to censor those who would tell you
about a problem with your gadget.
That is a worthwhile freedom.
Comments (1 posted)
Andy Oram's report from the
Ottawa Linux Symposium
notes that OpenOffice.org took some grief there:
Already, two speakers have made wisecracks about OpenOffice.org,
tagging it as a bloated memory hog. I have the suspicion that some
attendees see Linux as something to run for its own intrinsic
value, rather than as a platform for useful applications that can
actually help people accomplish something.
As one of those speakers, your editor will plead guilty to taking a cheap
shot for an easy laugh (and people did laugh). But the remark had nothing
to do with the value of OpenOffice.org as an application. It was about
In a private conversation at the same conference, an engineer working with
a services company in a developing country mentioned a valuable line of
business for his employer. It seems that there are customers with large
numbers of older desktop computers running legacy operating systems; they
would like to extend the life of those computers by putting Linux onto
them. But Linux does not run as well on these systems as anybody would
like; it is simply too big. OpenOffice.org is especially problematic on
smaller systems, but the problem does not stop there.
Not that long ago, Linux was a relatively small and fast system which could
run well on a wide variety of older hardware. That may still be true in
some specific cases - Linux-based firewall/routers, for example - but, as a
general-purpose operating system, Linux has become just as bloated as its
proprietary competition. Your editor just looked at his desktop system,
with two days of uptime, to see where the memory went. A few examples:
|Program||Resident set (MB)|
It is a sad world when 10MB of memory is required to display a clock, and
21MB to run a terminal emulator.
Developers who have taken a class in data structures have probably heard
all about time-space tradeoffs. Programs can often be made faster at the
expense of higher memory usage. The truth of the matter, however, is that
these tradeoffs are often illusory. Big code is slow code. From inferior
processor cache usage through to virtual memory thrashing, large code slows
things down across the entire system. On contemporary systems, the way to
faster code is often by using less space, not more.
There are signs that more developers are beginning to understand the costs
of bloat. There is a GNOME
memory reduction project underway, for example, though it does not
appear to be progressing rapidly. But a more serious effort will be
required if the Linux desktop is going to lose some significant weight.
And it should lose that weight. Some growth is to be expected from the
development of the software itself - Linux systems can do much more than
they could a few years ago. But it seems clear that much of our
development has been aimed at the addition of new features, and relatively
little attention has been paid to memory usage. At this point, Linux need
not feel insecure about the features it offers; maybe the time has come to
put some more effort into implementing those features with fewer
resources. Otherwise, Linux is inflating itself out of a number of
possible applications and losing the leanness which used to be one of its
Comments (77 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: NuFW; New vulnerabilities in ethereal, gaim, powerdns, proftpd, ...
- Kernel: How fast should HZ be?; A new path to the refrigerator; ACPI, device interrupts, and suspend.
- Distributions: About Source Mage; Slackware freezes for 10.2
- Development: Linux-HA reaches the 2.0 milestone,
new versions of JACK, JabRef, iptables, Nagios Plugins, Xprobe2,
CentraView CBM, Campsite, OpenWFE, KDE, KMyMoney, FOX Toolkit, Arsenal,
Mozilla, Gourmet, SBCL, Jacl and Tcl Blend, Valgrind.
- Press: The Commons and business, Ruby intro, Open-source for career growth,
Ballmer on Linux, Novell plans to open SUSE development,
Patents Don't Compute, EU IP Infringement law, FreeNX.
- Announcements: OSCON 2005 announcements, Mozilla creates a for-profit corp,
RISKS turns 20, FSF Award nominations, Python Game Challenge,
PostgreSQL Bootcamp, Linux Migration Seminar Series,
Open Source Desktop Workshop, Business Readiness Ratings.
- Letters: Flaws in Firefox and Internet Explorer.