[Bas: When I got to the bottom of your note, I realized that I should have started this from another direction entirely. I want to send out these comments anyway, but I suggest that we need to proceed through the design from the bottom and work up in order to have a clearer discussion.]
On Tue, 2005-11-08 at 20:57 +0100, Bas Wijnen wrote: > You're saying that as if we aren't this distributor. ;-) Of course we shall > not be the only distributor, but I think we don't want others to accept this > burden either. That is not your decision to make. It is the distributor's. > The GNU project is meant to allow people the freedom to change software. If a > distributor will only support unchanged versions of the system, he is really > setting up a barrier against changing it. We don't want to stimulate that > kind of thing. So as supporting it has this as a potential side effect, a > cost would be that we are losing our principles. It is true that the GNU project allows people to change their software, and protects their right to do so. But it is also true that a distributor can offer things **in addition to** software, and these offers may be conditioned on *not* changing the software. For example, I can ship you a completely GPL system, and I can offer you a warranty and/or support contract on that system. You are free to change the system, but I am free to say "the warranty and/or support contract applies only to the configuration that I sent you." GPL has *never* required that support providers be willing to support arbitrary code changes by the customer. The philosophy encourages that the support provider should be reasonable and flexible, but it doesn't require it. GPL also does not say "you, as the user, must be changing your system all the time". It says that you *can*, not that you *must*. From the user perspective, it is very likely that I would prefer to pay for support, and that as part of this deal I understand that there are freedoms that I will refrain from exercising in order for meaningful support to be possible. > > > Furthermore, it costs control. That is, it creates a system where the > > > user > > > may loose control to a content provider. > > > > Nonsense! The user absolutely has not lost any control at all. They can > > always remove anything installed by the content provider. If they choose > > not to agree, then they never had the content in the first place to > > control or fail to control. > > Compared to a system where the user can debug any program that he starts (this > does not include programs which take external capabilities such as su), > assuming that there is a way to make debugging impossible does cost the user > control. Not over the content, but over the executable which cannot be > debugged. Nobody has required the user to execute the program that declines to be debugged, in the same way that nobody requires the user to execute Windows after buying a laptop. Please explain the distinction between these two examples. > Anyway, I don't think this is a big thing, as this loss of control only > happens with the explicit consent of the user. We agree that consent is hugely important. If we were talking about something where the user was deprived of the ability to exercise choice, I would be arguing strongly against doing any of this. If it is done at all, it should not be done behind the user's back. > > What you are really arguing is that the two parties should not be able to > > jointly negotiate middle positions on control according to their needs and > > requirements. > > I'm not arguing for that, I'm just claiming that it follows from not > supporting those chips. Yes. If we do not support these chips, then we reduce all control negotiations to the choices "all" or "nothing". If we *do* support these chips, then a much wider range of possibilities is opened. But what you *appear* to be arguing is that two competent parties should be *prevented* from forming these relationships, and to ensure that they cannot do so we should not support the chips. > > This sounds like exactly the sort of restrictive policy that we should be > > trying to avoid. > > You say that like it follows from a design principle. Which one is that? I'm > interested because I want to know if I agree that we want it. The principle is a social principle, not a technical principle: if two competent parties wish to engage in a feasible relationship that does not harm third parties, it is not appropriate for me to decide by fiat that they should not, nor is it appropriate for me to engineer into my designs a decision that would have the effect of preempting their freedom. > > The metaconstructor (and, for that matter, the constructor) is part of > > the TCB. > > I know that the meta-constructor is. But I'm creating an object, pretty much > like any other process, which happens to work like the meta-constructor. But > when someone asks the meta-constructor if it created one of its > "constructors", it will say "no". But they aren't going to ask the > meta-constructor, because I'll give them a pointer to my object and claim that > it is the meta-constructor. Sure, but the only way you could do that is by modifying the account setup software. Ultimately, this will work its way back in the chain of trust to something that can be detected. You can definitely make the changes you describe, but you cannot make them in a way that is undetectable of a TPM/TCPA chip is present and in use and the underlying system is structured to support detection. The question at hand is: do we *want* to support detection. > > I don't want untrusted code in control either, but control is not > > binary. It is not either/or. It can be factored. Why do you believe that > > control should be absolute? > > Because I think all control should be with the user. It may be possible to > give all or part of it away, but that shouldn't be done, and therefore I think > it may not need to be supported. Yes. This is what I thought. You wish to make an a priori design policy that I, as a competent user, should not be permitted to engage in certain relationships that harm no third party. I understand that you do not mean to do so, but you are firmly advocating an architecture that profoundly constrains my freedom. > This is the same reason for which you don't > want to support grabbing the display, I think. :-) Only there I think it is > useful, and so it should be possible (although it shouldn't happen > accidentily) In my mind, the two cases are very different. I want to prevent display grab because if this is done the user has totally lost control altogether. In the previous discussion, the user has given up *partial* control, but they are able at any time to stop the activity and regain control (e.g. by killing the programs involved). Once the mouse has been stolen, they cannot stop any activity of any sort. Try it this way: The user should always be able to pull the plug on an interaction. > > > The administrator can do anything he likes at install time, including > > > adding a spying wrapper. > > > > The administrator can do what the installation software permits them to do. > > Nothing more. > > Sure. But that will include installing new code. And so he can install any > code he likes (he may have prepared it before using the installation > software). Perhaps, but the installer does not need to agree to replace parts of the system TCB. > > > > Alternatively, are you saying that the administrator should be able to > > > > alter the behavior of my compiler simply by virtue of being the > > > > administrator? > > > > > > Yes. He needs this control because he is the one who installs updates to > > > the compiler. > > > > This is simply not correct. Even if he updates the compiler, the > > administrator does not require this control. > > If he updates the compiler, he can choose to put in a new one which does what > he wants. Only if the installer permits this. > > > The situation is that I get some code which a > > > content provider wants me to execute to protect his content. I'm saying > > > that > > > I can spy on that code, because I'm the one who creates the constructor > > > for > > > it, *and* I'm the one calling that constructor. > > > > You are making a bunch of assumptions that may be valid in some systems, > > but they are not necessarily valid, and in my opinion you have offered > > insufficient justification. > > I'm happy to explain (or change my mind ;-) ). Can you tell me what > assumptions I am making that may not be valid? I think I'm only making > assumptions which directly follow from design choices. However, I didn't make > those choices explicitly, and I guess I should. I don't really know what they > are though, and knowing what strange things I'm assuming may help with that. > :-) That will be good for both of us. I could be missing things as well. I need to go do something else at the moment, so let me come back to this. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
