http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0301b&L=wmtalk&T=0&O
=A&P=12347
>There is a lot of speculation here which is not based on facts. PD will
>give you the capability to protect some subsets of your system from
>damage. Imagine having a fire proof safe in your house. Your house can
>still burn down and your safe will still protect your documents that are
>stored in there. Having the safe does not enable the people who sold
>you the safe know what is stored in there.
The problem is that in this case the safe salesman is the only person
with
unrestricted access to the safe. Let's keep in mind an important
characteristic of a real safe: only the safe's owner can access its
contents.
Let's talk about two system subsets: OS data and user data.
Pd protects OS data by only allowing MS-signed code to modify it. From a
system-level standpoint, the OS must decide whether or not a specific
process is allowed to access a certain data structure based on the
information it has about that process. In a traditional system, the OS
only
has information about which user launched it, and so the process has the
effective privileges of the user. This is a problem because a user can
inadvertently run virus code just as easily as that user can run windows
update. In a Pd system, the OS can also decide whether or not the
software
is MS-approved by looking at its digital signature. Note, however, that
making MS's digital signature the sole possible "passport" to elevated
privileges locks the user out of making any changes to the "protected
areas", since the user does not have access to MS's private key.
In the context of the safe analogy, this would mean that the owner of the
safe does not even have its combination. If the owner wants to open the
safe
and modify its contents, it must contact the safe's vendor, and ask that
a
representative of that company be sent out to dial open the safe. Even
then,
only the representative can go inside.
Fortunately, there is another way to prevent viruses while still allowing
the user full access to the system owned by that user. Instead of
creating a
system where the OS must decide whether or not a piece of software may
access system files based on whether or not it carries MS's digital
signature, the OS could keep a list of approved signatures, modifiable by
the user, that would grant a program proper permission to modify OS code
and
data. By guaranteeing that only the user can add digital signatures to
that
list and not programs (like it now guarantees that when the user presses
ctrl-alt-delete, it really is the system responding with a login prompt),
users could still have full access to the system without risking exposure
to
hostile code, at least without jumping through an elaborate set of hoops
at
the direct instruction of the (then unprivileged) malicious code.
Why didn't MS take this approach? Well, by only allowing code signed by
MS
access to the OS, MS has made itself a choke point for new drivers and
hardware, as well as propped up its DRM system (which I'll get to later).
Imagine that one day OpenGL 2.0 is ratified as a full standard. Once
hardware engineers are able to tear their eyes away from the hordes of
flying pigs outside the office, those engineers, at the suggestion of an
aging but still active John Carmack, start work on the latest graphics
card
and accompanying drivers with support for OpenGL 2.0. After many years of
hard work (hey, they happen to be the same people who worked on Duke
Nukem
Forever, it's to be expected), the new board is completely designed and
ready for the market, and the drivers are written. OpenGL 2.0 apps
perform
between 5% and 10% better than Direct3D apps on the same system. This is
what the designers had in mind, as everything coming out of Id Software
is
still OpenGL only, and Id is still very much on top of the 3D FPS engine
industry. In a non-Pd environment, the company would have a viable
product
that they could put on the market themselves or sell to graphics card
manufacturers. However, in a market where Pd is pervasive, they have a
problem: their drivers aren't signed, and a Pd system won't install them
without a signature. So they send them off to the Windows Hardware
Quality
Labs to get them certified at a cost of (say) a couple thousand dollars.
Ka-Ching for MS. A month later, they get the reference card back in the
mail, with a note that says:
"Direct3D support still has a few significant bugs. Please work them out
and
resubmit."
Right. Translation: "OpenGL is faster than Direct3D. This is not ok with
us." Left without any recourse, the developers load up the source code
for
their drivers, add a few delay loops in the OpenGL code, and recompile.
OpenGL performance is now 5% behind Direct3D. Again, the company submits
the
reference board to the WHQL along with the new drivers, and a month later
they get a cd back in the mail. It's a signed binary, and a note that
says,
"Thank you for your cooperation. In the future, smaller driver binaries
would be appreciated." Translation: "Don't bother including OpenGL
support
in your next card's drivers. They will not be signed."
It's a huge win for MS. Since every driver must be signed, the WHQL
department can really rake in the dough, and competing (read: portable)
technologies like OpenGL are eventually crushed. For media professionals,
substitute an mpeg4 capture/encoder card for a graphics accelerator in
the
above example.
Even though users will feel the effects of such restrictions on hardware,
Pd's iron-fisted control of OS software can affect users more directly.
Take
daemon tools, for example. When Diablo II first came out, consumers were
in
for a shock. It sported the latest version of a cd-based copy protection
mechanism, and so duplication of the "Play Disc" was impossible at that
time. This created an interesting dilemma: How could people who had
legally
purchased the game avoid having to risk scratching the original CD if
they
could not back up onto another CD-R and play from that? In a broader
sense,
how could anyone without a CD burner protect any of their discs? Anyone
can
learn to be exceptionally careful, but accidents are called accidents
because they're not planned. Duplication for backup purposes was legal,
but
it didn't seem possible. Enter daemon tools -- a software package that
would
emulate a dvd-rom attached to a scsi adapter inside the computer. By
reading
the entire contents of the disc onto their hard drives with the help of
comprehensive reading software, and then "mounting" this image with
daemon
tools, Diablo II players could enjoy D2 with the actual game CD tucked
safely away inside its jewel case. If Pd had been around when D2 came
out,
this would not have been possible. Installation of daemon tools requires
that its fake scsi driver be installed and recognized by windows.
Daemon tools is freeware, available at no charge from a group of
dedicated
developers who believe that people should be able to exercise their fair
use
rights. They don't have the money to pay for WHQL certification, and if
by
some miracle they were able to come up with it, MS could always decline
to
sign the driver.
And that's only what happens as a result of Pd's "protection" of OS
files.
What about user-level files? It's almost the same story.
I've already laid out the reasons why code must be signed in the Pd model
in
order to access "protected" data, so I won't repeat that here. Let's
assume
that the latest version of word uses Pd's protection to keep viruses from
destroying a user's files. It can do this because word is signed by MS,
and
the system knows that it's ok to let the signed executable modify
documents
that the user owns. What will happen when a competitor to MS office, say
OpenOffice, decides to add support for the upcoming XDocs file format?
Even
if MS fully opens up the structure of the file, I mean documentation and
everything, and the OpenOffice crew implements it perfectly, they're
still
prevented from competing. Why? Their binaries, once again, won't be
signed.
A user would be able to open a word document in OpenOffice (assuming MS
doesn't lock off read access to prevent dangerous worms from exposing
private documents as certain worms have in the past), but would be unable
to
save her work. Quite a few commercial software packages out today ship
"trial" versions that don't have a save feature. It kinda tends to
cripple
the product.
Of course, the above all hinges on whether or not there will be
"protection"
for user files. The TCPA specs make it pretty clear that there will be OS
file protection as described above (because it's necessary to preserve
system integrity), but says nothing about user data.
>And if you don't want to
>have the said safe, then don't use it! Same is true of PD.
Ah, and that's the kicker, isn't it: you can always turn it off. What
about
when you can't? What the MS promotional materials don't say is than when
you
turn off your "security components", certain important things break. This
system behavior is necessary in order to make DRM "work". At this point I
think it would be appropriate to define what DRM means, just for clarity.
DRM, or Digital Rights Management (aka Digital Restriction Management) is
technology that allows the entity that introduces information into a
system
implementing that technology to control what other entities are able to
do
with that information once it is transferred into hardware not under the
direct control of the introducing entity. Basically, information control.
Some possible applications:
-Online movie rental. The idea is that if a movie studio can have control
over its content after it streams it to a customer, the movie studio can
be
comfortable with renting movies online. (This, incidentally, is very
similar
to the logic behind the misguided CBDTPA bill.)
-Emails with timeouts and limitations. Users could send emails to other
users that would delete themselves after a certain amount of time, or not
allow copying or printing.
Now, set aside for a moment the issue of how turning off Pd affects the
user
experience, and consider the implications of such an email system. A boss
could send an employee an email ordering him to take a risky business
action, and have it deleted after recipient read it. A record, of course,
would be kept in the boss's "sent" mailbox. This puts the employee in a
double bind: if he doesn't follow the instructions in the email, his boss
can proceed with disciplinary action as the boss would have proof the
email
was received. If he does follow the instructions, and the action is
successful, his boss can take the credit. If he does follow the
instructions
and the action is unsuccessful, costing the company in some way or
another,
the employee has no record to prove that he was just following orders.
His
boss can delete the email, but the employee can't.
In any case, regardless of the negative experiences a user might have if
victimized by a superior through Pd, there is still the issue of reduced
functionality when Pd is deactivated with respect to DRM. Basically, the
way
Pd ensures that content stays in a trusted environment is by querying a
machine to see if it is running a trusted OS on trusted hardware before
it
sends it any managed content. While I won't explain it in great detail
here
(it would take up _way_ too much space and the specs are freely available
online for anyone who wants to read them), each machine contains a
Trusted
Platform Module (or TPM) which is a little chip soldered onto the
motherboard. (Later it will become part of the CPU itself.) This chip
contains a key pair generated for use with a public key cryptosystem, and
although it can hold many keys in its limited memory, it ships with one
already embedded. This sign-only key pair is signed by the hardware
manufacturer, signifying that the signed key pair is actually part of a
TCPA/Pd system. When TCPA/Pd is deactivated, either by user request or if
the CRTM (Core Trusted Root for Measurement) detects that the user is
trying
to run untrusted software with elevated privileges (e.g. The user is
trying
to boot GNU/Linux), this chip refuses to give up it's private key to the
cpu. This means that when a system with Pd enabled tries to send an email
to
a system with Pd disabled, the receiving system will not be able to
participate in the trusted system challenge-handshake sequence and will
not
be able to receive the email. A similar sequence of events occurs in an
online movie rental scenario when an untrusted system requests a stream,
and
the server requests verification that the client is running trusted
software
on trusted hardware.
So what won't work? Well, secure email, online movie rentals, and pretty
much any other communication involving "managed" content. In other words,
turning off Pd in an environment where Pd is widespread means not being
able
to get managed information from other systems. Once Pd becomes popular
enough, MS can extend its control by causing systems with Pd enabled to
treat everything as managed content, even simple things like web pages.
Turning off Pd in 2003 is an option. Turning off Pd in 2010 won't be.
>As to the original comment regarding privacy, you are seeing our attempt
>to document any and all aspects of the system that could concern anyone.
>So you are going to see us telling a lot more about the capabilities of
>the player and this can appear overwhelming at first.
And this is a good thing. However, MS is just doing something it should
have
done a long time ago -- it's in debt to the public for past privacy
violations. While I applaud MS for finally releasing a player that can be
easily configured not to disclose a user's media viewing preferences,
this
is more than compensated for by the fact that Pd makes past and present
privacy violations look like nothing it all. MS is, for the most part,
halfway fixing the lesser of two evils.
>The good news is
>that you have full knowledge of what we do and the choice to turn one or
>more of these off if your privacy is more important than the
>functionality.
Why can't users have privacy and functionality? You know, like they do
now
if they know how to properly configure WMP's options?
>Competitors probably do the same thing but fail to warn
>you explicitly about them (and burry the detail in long EULAs).
>From a WMP critical update EULA:
"* Digital Rights Management (Security). You agree that in order to
protect
the integrity of content and software protected by digital rights
management
("Secure Content"), Microsoft may provide security related updates to the
OS
Components that will be automatically downloaded onto your computer.
These
security related updates may disable your ability to copy and/or play
Secure
Content and use other software on your computer. If we provide such a
security update, we will use reasonable efforts to post notices on a web
site explaining the update. "
MS's _competitors_ are burying sneaky and unethical terms in EULAs?
Realplayer may spew garbage all over my system, but at least Real doesn't
demand the legal right to install software on my computer without first
receiving my explicit permission or entirely disable software on my
computer, all before I can get access to a patch to fix a bug in their
software that was only there because they put buggy code on store shelves
and sold it at full price.
Then again, maybe Real does do this. I haven't seen their license terms
in a
while.
>Here is a write-up from CNET on our privacy approach in media player:
>http://news.com.com/2100-1023-955514.html. As you see, it is being seen
>as a very positive move and not negative at all. Here is one quote:
>
>"If the final build looks like the software (that CNET News.com)
>described, the implication is that Microsoft is taking consumer privacy
>very seriously indeed and marks a big change for the company," said
>Jupiter Research analyst Michael Gartenberg."
This article is about WMP9, and notes that it still has a few bugs to
work
out in terms of privacy. It is not about TCPA/Pd, DRM, or the next
version
of windows.
_______________________________________________
http://www.mccmedia.com/mailman/listinfo/brin-l
