Re: Separate trusted computing designs

[Michal Suchanek]

On 8/30/06, Jonathan S. Shapiro <address@hidden> wrote:
> I claim that Marcus's essential concern here is not about the features
> of any particular operating system, but about the balkanization of
> content. I definitely think that this is a good thing to worry about,
> but it is not obvious that this concern should have any impact on the
> long-term design of Hurd.
>
> For the sake of discussion, let us assume that we build an operating
> system -- I shall call it "Hurd" -- that does not support TC. Hurd does
> not make these features available to users or applications. Let us
> further assume that there exists in the world a popular operating system
> -- I shall call it "Windows" -- that *does* support TC.
>
> Observe that the vast majority of machines will run Windows, and that
> this is sufficient to ensure that balkanizable content will be
> balkanized. Further, this is true whether or not Hurd supports TC.
>
> So: there exists content in the world that is going to get balkanized.
> When that happens, the decision that users will really face is between
> two options:
>
>   1. They can enable TC to gain access to that content.
>   2. They can elect not to enable TC and decline access to that content.
>
> This choice is not a choice about operating systems. Choosing Hurd is
> entirely equivalent (in this regard) to choosing Windows with TC
> disabled or choosing Linux with TC disabled.
>
> BUT, by denying support for TC, Hurd elects to make a choice as well. It
> forcibly divides users into two mutually exclusive camps:
>
>   1. Users who require access to balkanized information in order to
>      participate in culture and society in all of the ways that Marcus
>      describes.
>
>   2. Users who can run Hurd.

However, if this balkanization of content ever happens the content
vendors would probably choose this for us. Who will develop and
certify applications for the Hurd that can access the content? Since I
looked at the story with DeCSS and DVD playback on GNU/Linux I think
no vendor would care.

> The problem here is that there are unfortunate choices in the world.
> People who have to deal with balkanized information may nonetheless want
> to support freedom. Even if they are unable to make a black and white,
> 100% commitment, support for freedom is still support. By forcing those
> people off of the Hurd we deprive them of choice. We say, in effect:
> "Unless you are willing to turn your back on culture and society we are
> not interested in dealing with you."
>
> I do not believe that forcing this choice is right, moral, or ethical.
>
> So what (in my opinion) is the moral and ethical path for the Hurd?
>
> In my opinion, Hurd should delay support for TC as long as it can. It is
> not consistent with the Hurd view of freedom to encourage or accelerate
> or facilitate the arrival of TC and the balkanization of information.
> This much seems very clear and obvious.
>
> However, at some point the world will cross an inevitable threshold
> concerning TC, and at that point I believe that the moral imperative
> will swing the other way. In a world where TC is required to participate
> in culture and society, the moral obligation of the Hurd will be to
> maximize those freedoms that people can exercise by running
> non-proprietary systems.
>
> That point is not yet here, but when it arrives I believe that it will
> be immoral and unethical for Hurd (and FSF) to *fail* to support TC.
> Speaking out about the risks and costs and problems of TC will remain
> appropriate, but polarizing the freedoms of users is not.

This whole argument is pointless as nobody found a design so far that
makes use of TPM impossible, or at least hard. The well organized
components of the Hurd will be likely easier to certify than most
popular OSes. You only need to add a TPM driver, and a service that
does the certification.

Thanks

Michal