Fair question, as long as it's not being used as a vehicle to express resentment toward "security experts" for a topic you can't be bothered to understand. That sort of sophistry is the refuge of the ignorant. And as the subject has received widespread attention, it's not as if your question hasn't been answered many times over.
But assuming that your question is genuine, here is a short, and by no means exhaustive, list of areas is where Microsoft falls down with respect to security:
security of supply
modularity
interoperability
containment
least privilege
security by default
verifiability
Many of these factors are interrelated. When Microsoft engages in illegal monopoly practices, it has the effect of reducing the security of supply to the industry by limiting the number of competing products. It does so by deliberately breaking interoperability with competing products through a strategy which it calls "embrace and extend."
Another strategy, called "integrated innovation," likewise promotes the questionable virtues of integration at the expense of the fundamental virtue of modularity. Integration is fine for microprocessor chips, but software components are not transistors, and the software engineering problem, as Fred Brooks pointed out, is not about how to efficiently replicate such components. On the contrary, we often need to replace individual software components in order to repair security problems in their design or implementation. Modular systems are thus intrinsically more favorable to security than integrated, monolithic ones.
Independent of this effect, it's also possible to reason more effectively about security in a modular design than in a monolithic one. The analysis of security between communicating entities has been very well studied, and in a modular system this communication takes place in formally defined ways. The strongest demonstration of this capability lies, again, in how well a module interoperates with others. So when Microsoft attests in court that Internet Explorer can't be removed from Windows, it's acknowledging a basic failure to attend to modularity.
Security factors such as containment and least privilege are only possible where modularity is already well established and effectively managed. Usually these factors are what people think of as being characteristic of secure design, but they are in some sense derivative of more general security and design factors such as modularity. In any case, from all of the foregoing we can easily predict that problems will arise when bringing them late to a design, as Microsoft has characteristically tried to do.
Other critical design factors, like security by default and verifiability, require a further degree of commitment to security which Microsoft has a history of actively avoiding. I could cite many examples of these, but surely you can think of some on your own with modest effort.
Yep, Microsoft made the design choices that created the problem. No doubt they'd also like to sell you the solution.
And Paul Bryan is right when he suggests that it would be a good idea to "make sure people have fewer security products". And the very best way to do that is to switch to a more secure platform. Then you don't need additional security products to solve the problems that should have been solved during platform design. Sheesh.
I gather that you're not a software developer. This is simply application software that manipulates data. What this has to do with kernel architecture is not clear. If an application can't be straightforwardly ported to multiple platforms, something is fundamentally wrong with its design.
According to Steve Ballmer, that something is called "integrated innovation". This is a strategic decision to compromise modularity, and thus portability, in order to more effectively lock customers into the product. As such, it's essentially a marketing strategy. As a software engineering strategy it's deeply flawed, because it encourages brittle design and leads to brittle implementation. It creates unnecessary codependence between applications and system.
From a system management perspective, it delivers systems which are monolithic and poorly interoperable with standard infrastructure. Integration at the system level is hard enough, without adding application codependence to the problem. Support would be a nightmare, indeed.
From a security perspective, this kind of nonmodularity has even more fundamental badness. How can you improve security in an environment where the components are not replaceable?
Never mind asking whether I'd pay $500 for MS Office on any platform. I wouldn't use Microsoft Office if you paid me. It's just not worth the risk.
This infringment is by a legal minor, a legal minor is a legal minor because children are not considered capable of making clear rational decisions. GPL violations are not done by legal minors because legal minors can't enter into the GPL contract. Even if it was the same person, the situations are clearly not the same.
That thinking is why the RIAA brought the original case against the parent instead of the minor, where it was dismissed with prejudice. From a legal standpoint it proved to be the wrong approach. The court has to be convinced in sequence that (a) a violation of copyright occurred, (b) a specific person committed that act, and (c) since that person is a minor, responsibility properly falls to the parent. The plaintiff attempted, and failed, to bypass this process.
Emotionally, my first reaction was to go along with your argument, but on reflection I see that it's flawed. Sure, minors aren't contractually responsible, but the GPL is not a contract, it's a license. Copyright remains with the author, so that outside the terms of the license, use of the work is strictly a copyright violation.
So, comparisons between software, text, and recorded music are legitimate, because all are protected by copyright. If you object to such comparisons, in other words, you're bound to lose the argument.
What are the logical ways out of this? Well, one is to argue for discarding copyright completely, in which case a lot falls down, including the GPL. Philosophically it's always an instructive exercise to think about this, but copyright protections were not established for philosophical reasons but pragmatic ones. Something demonstrably better would have to be put in place, and I'm not aware of any suitable replacements.
The other way to proceed is to follow legal tradition by refinement or elaboration of the principle of copyright. In Canada, for example, we have the elaborated the broad application of copyright to exempt various forms of fair use such as personal copying. It's unlicensed publication of a copyrighted work that is not permitted. In my view, this is very intelligent legislation. It protects copyright holders from substantial harm, while respecting individual privacy and fair use. And it isn't a problem for the GPL, because the GPL explicitly licenses such publication.
Hear that, Dell? I'm not paying for Microsoft when I have no desire to use it. Offer laptops certified for Linux or Solaris and I'll not only buy them for my company, I'll recommend them to our clients.
Oh, and don't worry about installing the operating system. We have to be able to prove that can be done in the field anyway.
Actually this database isn't new, and isn't managed by NIST. CERT has been running the CVE database project for years, which makes the obvious limitations of this new virus naming scheme seem all the more strange.
But these are details. Your comments are in the right spirit. Of course it makes sense for the same institution to resource these two highly related activities. With a commitment to a common, stable nomenclature, the two databases will be able to reference each other.
It also seems to ignore the existing CVE numbering scheme which surely was designed with similar intent.
This all reminds me somewhat of the patch numbering schemes developed by different software vendors. The one that I've found best in practice comes from Sun Microsystems. Rather than being a plain integer or some equally cryptic enumerator, it's a pair of integers, one identifying the patch, and the other its version. This provides an explicit distinction between intent and implementation, very useful considering that patches themselves often undergo refinement over time, and may need to be reapplied to the same system.
We already know that a similar approach is needed for viruses as well, since many viruses are recognized as minor variants of the same code. The existing ad hoc virus naming scheme already takes this effect into account, though without the rigor that would potentially be available in a vendor-neutral format.
So there's no question that a common virus taxonomy is a great idea, and that CERT would be a natural candidate to be responsible for the virus database, as it has for the CVE list. But the scheme itself seems belated and remarkably toothless. Is this really offered as some kind of sop to the virus detection industry?
I've stopped believing in the "engineering" part of software development altogether.
It seems that engineering gets brought to bear when economic forces justify the effort. Such justification depends on both need and ability. That's where engineered solutions historically emerge first.
I guess that software is at the stage where the equivalent of knocking a tree over the creek or letting grapes rot is still generally perceived as sufficient to meet the need for a bridge or an alcoholic beverage. For example, I just met with some new clients last week who want help building a video surveillance product. These are professional engineers, by the way. As I went through my usual dialogue with them to gain a sense of the necessary functional elements and the interfaces between them, I could feel their impatience growing. They just wanted, you know, secure code. The little thing you put into the hardware. Clearly, a need was being expressed here for software, just not for engineered software.
Software isn't like hardware anyway. It has no material properties which conveniently help to constrain the configuration space. In creative terms, that's a blessing. In engineering terms, it's a curse. All bridges essentially solve the same problem using the same selection of materials. It would be pretty hard to design a bridge using implicit requirements and arbitrary materials, yet that's the equivalent problem we encounter in software design all the time. Likewise, I think that our ability to bring an engineering approach to software design will emerge where the problem space and solution space are both highly constrained.
Isn't this [poor administration] the same flaw Windows has?
It's a reasonable question to ask.
Yes, fundamentally it's true that configuration management has a significant effect on security. To be precise, this is not a flaw, but a characteristic. A site which is in full control of system configuration will have formal security advantages over one which isn't, and this is universally true regardless of platform.
However, the story is told from a much different perspective when it comes to evaluating the security of a given platform. Configuration remains a major factor in security, but it has to be weighed in light of platform capability. So, for example, a very simple network appliance with a very small configuration space has the prospect of being very secure. An ideal appliance cannot be configured insecurely. In practice, that may or not be the case, depending as always on design tradeoffs and correctness of implementation.
Apart from pure appliances, all computing platforms must, for reasons of generality, offer configuration possibilities that put some security tradeoffs in the hands of site administrators. Such is the case for both Linux and Windows, so indeed poor administration can always result in poor security on a sufficiently general platform.
The practical focus, therefore, has turned to how securely these platforms are configured by default. Interestingly, even though Windows is marketed for nonexpert use, it has a long tradition of being configured insecure by default, exactly the opposite of what would be appropriate for a nonexpert market. It also, in my opinion, embodies a lot of fundamentally insecure design tradeoffs, neglecting principles such as modularity, containment, and least privilege, for example. These are extremely deep design problems, not easily fixed.
Linux and Unix, although designed by developers for developers, and therefore intended for expert use, have a record of delivering much better security by default. I can think of lots of particular exceptions, but they have tended to be minor design tradeoffs that could be, and were, easily corrected. Security incident statistics seem to reinforce these observations very strongly.
In my line of work, I get to see what goes on behind the scenes at a lot of sites. It's not often that I come upon a site which is not suffering to some significant degree from a chronic neglect of configuration management. All discussion of platform characteristics aside, this is a real problem on the ground for security.
The issue, in terms of value for effort, then becomes to identify which of these sites is (a) at most immediate risk, and (b) has the best potential of improvement. In the former case, I find that the answer is Windows, and in the latter, it's Linux.
I don't see why your thumb is not an artifact according your definitions.
Because you don't get to manufacture a new thumb in order to meet changing requirements. That would qualify it as an artifact, whereas a thumb, like all sources of biometric information, occurs naturally, and thus is constrained in the range of requirements it can meet.
Early authentication schemes employed naturally occurring artifacts such as jaggedly broken rocks and pieces of wood
In the case of an artificial object or a biometric you are still measuring one or more properties of a physical object.
Here you're treating your conclusion as a premise. No, artifical objects are artificial. They need have no reference to any physical object. For example, a digital certificate is an object created from a cryptographic, that is, mathematical, process. It has no physical properties. Conversely, biometrics are strictly derived from physical properties.
biometrical testable properties of the human body can be altered or spoofed
That may make them bad candidates for use in strong authentication. I made that observation already. A good biometric obviously would be one that is hard to spoof. But that is all beside the point. Clearly these are natural properties that you carry with you. You can't manufacture them to arbitrary standards in the same way as you can an artifact such as a digital signature. That constraint may make them better or worse in certain applications. The point, and you're helping to make it here, is that these two classes require fundamentally different treatment.
Biometric devices have to be built to test certain properties of a human body and those properties must be measured in advance in order to be used. Other "something you have" schemes are built to test specific properties of some object which has to be set (or measured) in advance.
I notice that you're again applying your conclusion as a premise. We've already established that your argument rests on making no distinction between "being" and "having." So far, you haven't produced anything in support of that premise.
How then does a biometric measurement and testing of something that is part of your body differ from the measurement and testing of something that is not part of your body
Because artifacts are not about measurement and testing of natural properties in the first place! That's your claim, not mine, and I don't see that it can be successfully defended.
I think that this will be the end of my contribution, since I've presented my point of view and clarified my understanding of yours. If you want to add any final comments, please feel free.
A system which is impossible to modify is a good candidate for being a secure system. It also has limited usefulness.
The security requirements for a system which can be modified take us to another level. Provided a system meets those requirements, there is little need to distinguish between software approved by a vendor and software approved by a user.
A physical device with a key on it is something you have. You claim that being a person carries a different set of characteristics, but authentication schemes can't identify what is a "person" only known physical characteristics that that person carries with them as part of their body. Having your thumb or someone else's thumb is no different than having your key or someone else's key.
Your comments are very useful in clarifying where we differ, and why.
On the assumption that there is no distinction between "having" and "being", your argument follows logically and is well reasoned. It only depends on there being no fundamental or nontrivial difference between "something you have" and "something you are". It might seem that authentication schemes can't distinguish between "having" and "being", but in fact they can do so at a fundamental level.
To refer to my previous post, something you "have" is strictly an artifact. An artifact can be anything agreed between the parties, which means (a) it can be given arbitrary cryptographic properties, and (b) a different artifact can be substituted by mutual agreement from an infinite space of possibilities. A good cryptosystem takes specific advantage of these conditions, for example by allowing different signature algorithms and key lengths. In general, artifacts permit arbitrary cryptographic strength, which is clearly valuable, but not all that authentication is about.
Something you "are," on the other hand, is by definition a natural measurement associated with your person, not an artifact. Not being an artifact, it does not have arbitrary properties, but natural ones. Being a measurement of a certain object, the space of possible substitutions is also finite. In practice, there aren't many suitable biometric properties. Some would argue that there aren't any, but that remains an open debate. In case it turns out there are, it should be clear that they require very different treatment than artifacts.
The point is that authentication built around "something you are" has to operate within the constraints of both measurement and a finite set of properties. Authentication around "something you have" does not have such constraints. The difference is fundamental, and indeed testable.
To return to your claim that authentication schemes can't distinguish between these two classes, of course it's possible to build a naive authentication model that ignores the distinction, but I'd argue that's simply bad engineering. Good engineering doesn't just treat these properties as a set of bits, but recognizes the difference between how these properties are derived, and treats them appropriately.
Thanks for keeping this discussion rigorous, and interesting.
I take your point about the importance of understanding and applying design principles, and of course there are engineering programs around the world which go to considerable lengths to run projects and create encounters with industry just for the purpose of exercising the design aspects of engineering practice.
Likewise, there are other typical engineering activities which may be more analytical, more consultative, and so on. A school with a good undergraduate curriculum will present a realistic variety of these, and will help students to develop the learning styles which are the most effective for each of them.
However, it's to be expected that universities, and individual science and engineering programs, will vary enormously in what they do best. A great reputation for research, or prestigious political connections, turns out to be not at all a useful predictor of the quality of undergraduate teaching.
I understand that there are many students like Kern who may simplistically assume that it is. The lesson here is to not assume, but to research these things in advance. That's true for any situation where you expect to put in a whole lot of money and effort before seeing results. It's a tough lesson, no doubt about it, but it's also very typical of the kind of research found in science and engineering. Here you're designing your own life. Best to make sure you're specifying the right parts.
I strongly object to this bastardization of traditional authentication scheme theory.
Your argument begins by objecting to a widely accepted partitioning of the authentication space, but the reasoning you present seems only to support the partitioning as given.
As you point out, biometrics is not just something you have, but something you are, since they are based on nonsubstitutable parts of your person. This condition leads to a particular set of authentication characteristics which, as you point out, must be considered on their particular merits.
By contrast, something you have, such as a cryptographic token, is an artifact. Being an artifact carries quite a different set of characteristics than being a person, and requires a different analysis.
In other words, you make an effective case that it's completely appropriate to partition the authentication space as given. Your objection seems not to be with the theory, as you claim, but with some fairly narrow applications of the practice.
I'm not a lawyer, and not especially familiar with United States law, but since nobody else has responded so far, let me take a guess at it.
If you're going to develop a legal case, you have to clearly identify the parties in question. The case then proceeds on evidence relating to those specific parties. Here, the litigant failed to identify the proper party, an error which happens surprisingly often in civil law.
This is important background, because it points out that what would have happened in a similar, but not identical case brought against the child is open to speculation, as it would depend on a different presentation and interpretation of evidence.
But supposing that the litigant had prevailed and the court had found against a minor child. The court formulates its judgement in relation both to specific context and to case law. In principle, the guardian of a minor is legally responsible for the conduct of that individual, and in many countries there is ample case law which serves to clarify how this principle has been applied in practice, for example in theft of a vehicle by a minor, and so on.
Much will depend on circumstance. For example, was the guardian aware or unaware of the misconduct of the minor? Did the guardian create conditions favorable to the misconduct? Would a reasonable person have understood the possible consequences arising from those conditions, and acted to mitigate risk? The financial and other circumstances of the guardian would also likely be presented by the defendant somewhere during the this phase of the proceedings.
Microsoft wants one thing and one thing alone: money.
I'm not sure whether money or dominance is at the top of Microsoft's list, but it's abundantly clear from past conduct that both are core priorities. In tactical terms, the record shows that Microsoft quite readily makes concessions where money was concerned, but almost never where it has to give up any degree of situational or market dominance.
Their game is far from exclusively about money, in other words. I suppose you could argue that the game is ultimately about maximizing money, or shareholder value, or some other related quantity, but again if you look at the overt strategy and rationale, most of the evidence seems to point to an almost pathological desire for dominance.
This recent antagonism toward Google is a case in point. Google is not a threat to Microsoft in any way related to present revenue models. It's a threat only in that it might take up some of the space which Microsoft might at some point in the future want to move into. In other words, Microsoft has to dominate that space simply because it exists.
If Microsoft were just about money, it would exist in a happier equilibrium with social needs and social controls. Most of our social controls around corporate behavior are based, as you suggest, on an assumption that the corporation will optimize around money. So a government can levy fines against monopoly practises or pollution or other forms of misconduct. But Microsoft will not acknowledge such controls. Look at how it has responded in the EU antitrust proceedings, for example. What did Microsoft do in the choice between paying $650M or unbundling a software application from the operating system?
In a word, where dominance is concerned, Microsoft is intransigent. I don't think that there is evidence to support the same case for money.
Well, that was exactly what set Unix apart. Unlike competing operating systems, it was written for portability.
Never mind its multiprocessing features, and the hierarchical filesystem, and user protections, and the command shell, and the C programming language. Everybody was after it because they wanted portability. People hated being stuck in a proprietary environment.
Sound familiar? History repeats itself. Commercial Unix variants, initially written to enable hardware sales, became increasingly differentiated as feature sets in their own right. These arguably added value to the system, but of course also impaired portability. Differentiation also, unfortunately, gave jealous vendors a new excuse to lock customers into their products. So today Unix variants are substantially similar, but also gratuitously different. Thus it is that Unix loses out to Linux, not by comparison of features but by reason of portability.
A separate portability issue takes place at the kernel and driver level, as it must on different hardware. For the same reason that Unix could be ported to different processors, Sun could and did develop Solaris for Intel. But somebody had to write the device drivers, and that turned out not to scale out very effectively in the marketplace. Maybe more encouragement from Sun would have done the trick, it's hard to know for sure. If it had, maybe we'd be seeing AIX or HP-UX on alternate hardware as well. But now they're well and truly stuck.
Linux, against all odds, is not. In some future history of computing, Linux will stand out as the rightful heir of the grand principle of portability, because it didn't sell out to something else. And somewhere in that history there will be a footnote, I hope, that Linux could not have succeeded without a widespread commitment to driver development. Let's not forget that. It's not just about the processor architecture.
This is a good development for Sony. Its organizational structure has been overpartitioned for a long time, so that it has functioned not as a single organism but as several, sometimes competing, ones.
For example, Sony used to have something like five different divisions which developed and marketed video cameras. This kind of effect is going to arise sooner or later in any large organization, but a bit of refactoring and consolidation now and then has to be a good thing.
Fundamentally more secure means there's something inherent in their technology that makes it more secure.
There are indeed fundamental differences in the security between the two approaches. One obvious difference is modularity. A browser which is monolithically integrated with a system is a greater security risk than one which can be removed or replaced, since its risk cannot be mitigated.
Another fundamental difference is in transparency. Security fundamentally requires verification. Closed source strictly prevents verification.
Another is containment. What are the consequences to the system if the browser is compromised? If the browser is designed, say, with the intent of installing software or modifying the window system, then it fails to contain security risks compared to a browser which defers these actions to the part of the system which is nominally responsible for system configuration.
Don't be a troll. An opinion is a statement based on subjective criteria. And yes, everyone has them, and comparisons between them are not particularly interesting.
But we're not talking about subjective matters here. Symantec has released a security analysis, whose premises and reasoning may or not be correct at various points. That's what we're discussing here. Symantec is not saying, "We think Britney Spears is cute." It's claiming that vulnerabilities have been found faster in one browser versus another over a certain period of study.
Our discussion is about the merits of that claim. It's called a rational discussion. I'm sure there will be some subjective opinions thrown in as well. After all, we're not a corporation issuing a press release on the findings of a security study, so tests of intellectual rigor are a bit different here.
Assuming customer choice is important, a customer can elect to not use Firefox and remove it from their system. Can the customer remove IE?
This is a great point. It's not just an abstract matter of customer choice, either. It has fundamental implications for security.
Consider that all manufacturing industries are concerned about security of supply. That means if I'm making cars, for example, I want to be sure that I can get drivetrain components from multiple suppliers. If I find some kind of defect in a component, I can switch to another supplier. That's critical to my manufacturing operations, so a supplier that tries to limit my choice is a supplier that threatens the security of my business.
The other factor, of course, is modularity itself. Gordon Bell famously said, "The cheapest, fastest, and most reliable components of a computer system
are those that aren't there." Secure designs are modular, so that (a) insecure components can be replaced by secure ones, and (b) the security risk from components not required can be removed entirely.
And what methodology was followed in order to ensure that such comparisons would be meaningful?
This is old stuff, as we all know. So why does a supposed authority on security not only miss the obvious analytical and statistical requirements of meaningful comparison, but go on to publish its findings?
Could there be any possibility of bias as a result of the strategic partnership between Symantec and Microsoft? Just a thought.
Slashdot Mirror
Fair question, as long as it's not being used as a vehicle to express resentment toward "security experts" for a topic you can't be bothered to understand. That sort of sophistry is the refuge of the ignorant. And as the subject has received widespread attention, it's not as if your question hasn't been answered many times over.
But assuming that your question is genuine, here is a short, and by no means exhaustive, list of areas is where Microsoft falls down with respect to security:
Many of these factors are interrelated. When Microsoft engages in illegal monopoly practices, it has the effect of reducing the security of supply to the industry by limiting the number of competing products. It does so by deliberately breaking interoperability with competing products through a strategy which it calls "embrace and extend."
Another strategy, called "integrated innovation," likewise promotes the questionable virtues of integration at the expense of the fundamental virtue of modularity. Integration is fine for microprocessor chips, but software components are not transistors, and the software engineering problem, as Fred Brooks pointed out, is not about how to efficiently replicate such components. On the contrary, we often need to replace individual software components in order to repair security problems in their design or implementation. Modular systems are thus intrinsically more favorable to security than integrated, monolithic ones.
Independent of this effect, it's also possible to reason more effectively about security in a modular design than in a monolithic one. The analysis of security between communicating entities has been very well studied, and in a modular system this communication takes place in formally defined ways. The strongest demonstration of this capability lies, again, in how well a module interoperates with others. So when Microsoft attests in court that Internet Explorer can't be removed from Windows, it's acknowledging a basic failure to attend to modularity.
Security factors such as containment and least privilege are only possible where modularity is already well established and effectively managed. Usually these factors are what people think of as being characteristic of secure design, but they are in some sense derivative of more general security and design factors such as modularity. In any case, from all of the foregoing we can easily predict that problems will arise when bringing them late to a design, as Microsoft has characteristically tried to do.
Other critical design factors, like security by default and verifiability, require a further degree of commitment to security which Microsoft has a history of actively avoiding. I could cite many examples of these, but surely you can think of some on your own with modest effort.
And Paul Bryan is right when he suggests that it would be a good idea to "make sure people have fewer security products". And the very best way to do that is to switch to a more secure platform. Then you don't need additional security products to solve the problems that should have been solved during platform design. Sheesh.
According to Steve Ballmer, that something is called "integrated innovation". This is a strategic decision to compromise modularity, and thus portability, in order to more effectively lock customers into the product. As such, it's essentially a marketing strategy. As a software engineering strategy it's deeply flawed, because it encourages brittle design and leads to brittle implementation. It creates unnecessary codependence between applications and system.
From a system management perspective, it delivers systems which are monolithic and poorly interoperable with standard infrastructure. Integration at the system level is hard enough, without adding application codependence to the problem. Support would be a nightmare, indeed.
From a security perspective, this kind of nonmodularity has even more fundamental badness. How can you improve security in an environment where the components are not replaceable?
Never mind asking whether I'd pay $500 for MS Office on any platform. I wouldn't use Microsoft Office if you paid me. It's just not worth the risk.
Microsoft doesn't want to support OpenDocument? Fine, that leaves the field open to competitors.
It seems that everywhere I turn, there's another good reason for avoiding Microsoft products.
That thinking is why the RIAA brought the original case against the parent instead of the minor, where it was dismissed with prejudice. From a legal standpoint it proved to be the wrong approach. The court has to be convinced in sequence that (a) a violation of copyright occurred, (b) a specific person committed that act, and (c) since that person is a minor, responsibility properly falls to the parent. The plaintiff attempted, and failed, to bypass this process.
Emotionally, my first reaction was to go along with your argument, but on reflection I see that it's flawed. Sure, minors aren't contractually responsible, but the GPL is not a contract, it's a license. Copyright remains with the author, so that outside the terms of the license, use of the work is strictly a copyright violation.
So, comparisons between software, text, and recorded music are legitimate, because all are protected by copyright. If you object to such comparisons, in other words, you're bound to lose the argument.
What are the logical ways out of this? Well, one is to argue for discarding copyright completely, in which case a lot falls down, including the GPL. Philosophically it's always an instructive exercise to think about this, but copyright protections were not established for philosophical reasons but pragmatic ones. Something demonstrably better would have to be put in place, and I'm not aware of any suitable replacements.
The other way to proceed is to follow legal tradition by refinement or elaboration of the principle of copyright. In Canada, for example, we have the elaborated the broad application of copyright to exempt various forms of fair use such as personal copying. It's unlicensed publication of a copyrighted work that is not permitted. In my view, this is very intelligent legislation. It protects copyright holders from substantial harm, while respecting individual privacy and fair use. And it isn't a problem for the GPL, because the GPL explicitly licenses such publication.
Hear that, Dell? I'm not paying for Microsoft when I have no desire to use it. Offer laptops certified for Linux or Solaris and I'll not only buy them for my company, I'll recommend them to our clients.
Oh, and don't worry about installing the operating system. We have to be able to prove that can be done in the field anyway.
But these are details. Your comments are in the right spirit. Of course it makes sense for the same institution to resource these two highly related activities. With a commitment to a common, stable nomenclature, the two databases will be able to reference each other.
It also seems to ignore the existing CVE numbering scheme which surely was designed with similar intent.
This all reminds me somewhat of the patch numbering schemes developed by different software vendors. The one that I've found best in practice comes from Sun Microsystems. Rather than being a plain integer or some equally cryptic enumerator, it's a pair of integers, one identifying the patch, and the other its version. This provides an explicit distinction between intent and implementation, very useful considering that patches themselves often undergo refinement over time, and may need to be reapplied to the same system.
We already know that a similar approach is needed for viruses as well, since many viruses are recognized as minor variants of the same code. The existing ad hoc virus naming scheme already takes this effect into account, though without the rigor that would potentially be available in a vendor-neutral format.
So there's no question that a common virus taxonomy is a great idea, and that CERT would be a natural candidate to be responsible for the virus database, as it has for the CVE list. But the scheme itself seems belated and remarkably toothless. Is this really offered as some kind of sop to the virus detection industry?
It seems that engineering gets brought to bear when economic forces justify the effort. Such justification depends on both need and ability. That's where engineered solutions historically emerge first.
I guess that software is at the stage where the equivalent of knocking a tree over the creek or letting grapes rot is still generally perceived as sufficient to meet the need for a bridge or an alcoholic beverage. For example, I just met with some new clients last week who want help building a video surveillance product. These are professional engineers, by the way. As I went through my usual dialogue with them to gain a sense of the necessary functional elements and the interfaces between them, I could feel their impatience growing. They just wanted, you know, secure code. The little thing you put into the hardware. Clearly, a need was being expressed here for software, just not for engineered software.
Software isn't like hardware anyway. It has no material properties which conveniently help to constrain the configuration space. In creative terms, that's a blessing. In engineering terms, it's a curse. All bridges essentially solve the same problem using the same selection of materials. It would be pretty hard to design a bridge using implicit requirements and arbitrary materials, yet that's the equivalent problem we encounter in software design all the time. Likewise, I think that our ability to bring an engineering approach to software design will emerge where the problem space and solution space are both highly constrained.
It's a reasonable question to ask.
Yes, fundamentally it's true that configuration management has a significant effect on security. To be precise, this is not a flaw, but a characteristic. A site which is in full control of system configuration will have formal security advantages over one which isn't, and this is universally true regardless of platform.
However, the story is told from a much different perspective when it comes to evaluating the security of a given platform. Configuration remains a major factor in security, but it has to be weighed in light of platform capability. So, for example, a very simple network appliance with a very small configuration space has the prospect of being very secure. An ideal appliance cannot be configured insecurely. In practice, that may or not be the case, depending as always on design tradeoffs and correctness of implementation.
Apart from pure appliances, all computing platforms must, for reasons of generality, offer configuration possibilities that put some security tradeoffs in the hands of site administrators. Such is the case for both Linux and Windows, so indeed poor administration can always result in poor security on a sufficiently general platform.
The practical focus, therefore, has turned to how securely these platforms are configured by default. Interestingly, even though Windows is marketed for nonexpert use, it has a long tradition of being configured insecure by default, exactly the opposite of what would be appropriate for a nonexpert market. It also, in my opinion, embodies a lot of fundamentally insecure design tradeoffs, neglecting principles such as modularity, containment, and least privilege, for example. These are extremely deep design problems, not easily fixed.
Linux and Unix, although designed by developers for developers, and therefore intended for expert use, have a record of delivering much better security by default. I can think of lots of particular exceptions, but they have tended to be minor design tradeoffs that could be, and were, easily corrected. Security incident statistics seem to reinforce these observations very strongly.
In my line of work, I get to see what goes on behind the scenes at a lot of sites. It's not often that I come upon a site which is not suffering to some significant degree from a chronic neglect of configuration management. All discussion of platform characteristics aside, this is a real problem on the ground for security.
The issue, in terms of value for effort, then becomes to identify which of these sites is (a) at most immediate risk, and (b) has the best potential of improvement. In the former case, I find that the answer is Windows, and in the latter, it's Linux.
The parent is simply pointing out that your argument begins with a false premise.
Because you don't get to manufacture a new thumb in order to meet changing requirements. That would qualify it as an artifact, whereas a thumb, like all sources of biometric information, occurs naturally, and thus is constrained in the range of requirements it can meet.
Early authentication schemes employed naturally occurring artifacts such as jaggedly broken rocks and pieces of wood
Naturally occurring objects are not artifacts. An artifact is "an object produced or shaped by human craft". The word comes from the same root as "artificial." Got it?
In the case of an artificial object or a biometric you are still measuring one or more properties of a physical object.
Here you're treating your conclusion as a premise. No, artifical objects are artificial. They need have no reference to any physical object. For example, a digital certificate is an object created from a cryptographic, that is, mathematical, process. It has no physical properties. Conversely, biometrics are strictly derived from physical properties.
biometrical testable properties of the human body can be altered or spoofed
That may make them bad candidates for use in strong authentication. I made that observation already. A good biometric obviously would be one that is hard to spoof. But that is all beside the point. Clearly these are natural properties that you carry with you. You can't manufacture them to arbitrary standards in the same way as you can an artifact such as a digital signature. That constraint may make them better or worse in certain applications. The point, and you're helping to make it here, is that these two classes require fundamentally different treatment.
Biometric devices have to be built to test certain properties of a human body and those properties must be measured in advance in order to be used. Other "something you have" schemes are built to test specific properties of some object which has to be set (or measured) in advance.
I notice that you're again applying your conclusion as a premise. We've already established that your argument rests on making no distinction between "being" and "having." So far, you haven't produced anything in support of that premise.
How then does a biometric measurement and testing of something that is part of your body differ from the measurement and testing of something that is not part of your body
Because artifacts are not about measurement and testing of natural properties in the first place! That's your claim, not mine, and I don't see that it can be successfully defended.
I think that this will be the end of my contribution, since I've presented my point of view and clarified my understanding of yours. If you want to add any final comments, please feel free.
A system which is impossible to modify is a good candidate for being a secure system. It also has limited usefulness.
The security requirements for a system which can be modified take us to another level. Provided a system meets those requirements, there is little need to distinguish between software approved by a vendor and software approved by a user.
Your comments are very useful in clarifying where we differ, and why.
On the assumption that there is no distinction between "having" and "being", your argument follows logically and is well reasoned. It only depends on there being no fundamental or nontrivial difference between "something you have" and "something you are". It might seem that authentication schemes can't distinguish between "having" and "being", but in fact they can do so at a fundamental level.
To refer to my previous post, something you "have" is strictly an artifact. An artifact can be anything agreed between the parties, which means (a) it can be given arbitrary cryptographic properties, and (b) a different artifact can be substituted by mutual agreement from an infinite space of possibilities. A good cryptosystem takes specific advantage of these conditions, for example by allowing different signature algorithms and key lengths. In general, artifacts permit arbitrary cryptographic strength, which is clearly valuable, but not all that authentication is about.
Something you "are," on the other hand, is by definition a natural measurement associated with your person, not an artifact. Not being an artifact, it does not have arbitrary properties, but natural ones. Being a measurement of a certain object, the space of possible substitutions is also finite. In practice, there aren't many suitable biometric properties. Some would argue that there aren't any, but that remains an open debate. In case it turns out there are, it should be clear that they require very different treatment than artifacts.
The point is that authentication built around "something you are" has to operate within the constraints of both measurement and a finite set of properties. Authentication around "something you have" does not have such constraints. The difference is fundamental, and indeed testable.
To return to your claim that authentication schemes can't distinguish between these two classes, of course it's possible to build a naive authentication model that ignores the distinction, but I'd argue that's simply bad engineering. Good engineering doesn't just treat these properties as a set of bits, but recognizes the difference between how these properties are derived, and treats them appropriately.
Thanks for keeping this discussion rigorous, and interesting.
Likewise, there are other typical engineering activities which may be more analytical, more consultative, and so on. A school with a good undergraduate curriculum will present a realistic variety of these, and will help students to develop the learning styles which are the most effective for each of them.
However, it's to be expected that universities, and individual science and engineering programs, will vary enormously in what they do best. A great reputation for research, or prestigious political connections, turns out to be not at all a useful predictor of the quality of undergraduate teaching.
I understand that there are many students like Kern who may simplistically assume that it is. The lesson here is to not assume, but to research these things in advance. That's true for any situation where you expect to put in a whole lot of money and effort before seeing results. It's a tough lesson, no doubt about it, but it's also very typical of the kind of research found in science and engineering. Here you're designing your own life. Best to make sure you're specifying the right parts.
Your argument begins by objecting to a widely accepted partitioning of the authentication space, but the reasoning you present seems only to support the partitioning as given.
As you point out, biometrics is not just something you have, but something you are, since they are based on nonsubstitutable parts of your person. This condition leads to a particular set of authentication characteristics which, as you point out, must be considered on their particular merits.
By contrast, something you have, such as a cryptographic token, is an artifact. Being an artifact carries quite a different set of characteristics than being a person, and requires a different analysis.
In other words, you make an effective case that it's completely appropriate to partition the authentication space as given. Your objection seems not to be with the theory, as you claim, but with some fairly narrow applications of the practice.
If you're going to develop a legal case, you have to clearly identify the parties in question. The case then proceeds on evidence relating to those specific parties. Here, the litigant failed to identify the proper party, an error which happens surprisingly often in civil law.
This is important background, because it points out that what would have happened in a similar, but not identical case brought against the child is open to speculation, as it would depend on a different presentation and interpretation of evidence.
But supposing that the litigant had prevailed and the court had found against a minor child. The court formulates its judgement in relation both to specific context and to case law. In principle, the guardian of a minor is legally responsible for the conduct of that individual, and in many countries there is ample case law which serves to clarify how this principle has been applied in practice, for example in theft of a vehicle by a minor, and so on.
Much will depend on circumstance. For example, was the guardian aware or unaware of the misconduct of the minor? Did the guardian create conditions favorable to the misconduct? Would a reasonable person have understood the possible consequences arising from those conditions, and acted to mitigate risk? The financial and other circumstances of the guardian would also likely be presented by the defendant somewhere during the this phase of the proceedings.
I'm not sure whether money or dominance is at the top of Microsoft's list, but it's abundantly clear from past conduct that both are core priorities. In tactical terms, the record shows that Microsoft quite readily makes concessions where money was concerned, but almost never where it has to give up any degree of situational or market dominance.
Their game is far from exclusively about money, in other words. I suppose you could argue that the game is ultimately about maximizing money, or shareholder value, or some other related quantity, but again if you look at the overt strategy and rationale, most of the evidence seems to point to an almost pathological desire for dominance.
This recent antagonism toward Google is a case in point. Google is not a threat to Microsoft in any way related to present revenue models. It's a threat only in that it might take up some of the space which Microsoft might at some point in the future want to move into. In other words, Microsoft has to dominate that space simply because it exists.
If Microsoft were just about money, it would exist in a happier equilibrium with social needs and social controls. Most of our social controls around corporate behavior are based, as you suggest, on an assumption that the corporation will optimize around money. So a government can levy fines against monopoly practises or pollution or other forms of misconduct. But Microsoft will not acknowledge such controls. Look at how it has responded in the EU antitrust proceedings, for example. What did Microsoft do in the choice between paying $650M or unbundling a software application from the operating system?
In a word, where dominance is concerned, Microsoft is intransigent. I don't think that there is evidence to support the same case for money.
Never mind its multiprocessing features, and the hierarchical filesystem, and user protections, and the command shell, and the C programming language. Everybody was after it because they wanted portability. People hated being stuck in a proprietary environment.
Sound familiar? History repeats itself. Commercial Unix variants, initially written to enable hardware sales, became increasingly differentiated as feature sets in their own right. These arguably added value to the system, but of course also impaired portability. Differentiation also, unfortunately, gave jealous vendors a new excuse to lock customers into their products. So today Unix variants are substantially similar, but also gratuitously different. Thus it is that Unix loses out to Linux, not by comparison of features but by reason of portability.
A separate portability issue takes place at the kernel and driver level, as it must on different hardware. For the same reason that Unix could be ported to different processors, Sun could and did develop Solaris for Intel. But somebody had to write the device drivers, and that turned out not to scale out very effectively in the marketplace. Maybe more encouragement from Sun would have done the trick, it's hard to know for sure. If it had, maybe we'd be seeing AIX or HP-UX on alternate hardware as well. But now they're well and truly stuck.
Linux, against all odds, is not. In some future history of computing, Linux will stand out as the rightful heir of the grand principle of portability, because it didn't sell out to something else. And somewhere in that history there will be a footnote, I hope, that Linux could not have succeeded without a widespread commitment to driver development. Let's not forget that. It's not just about the processor architecture.
No, the claim was with respect to Unix on Intel. Certainly AIX and HP-UX are viable Unix variants, but they don't run on Intel.
For example, Sony used to have something like five different divisions which developed and marketed video cameras. This kind of effect is going to arise sooner or later in any large organization, but a bit of refactoring and consolidation now and then has to be a good thing.
There are indeed fundamental differences in the security between the two approaches. One obvious difference is modularity. A browser which is monolithically integrated with a system is a greater security risk than one which can be removed or replaced, since its risk cannot be mitigated.
Another fundamental difference is in transparency. Security fundamentally requires verification. Closed source strictly prevents verification.
Another is containment. What are the consequences to the system if the browser is compromised? If the browser is designed, say, with the intent of installing software or modifying the window system, then it fails to contain security risks compared to a browser which defers these actions to the part of the system which is nominally responsible for system configuration.
Don't be a troll. An opinion is a statement based on subjective criteria. And yes, everyone has them, and comparisons between them are not particularly interesting.
But we're not talking about subjective matters here. Symantec has released a security analysis, whose premises and reasoning may or not be correct at various points. That's what we're discussing here. Symantec is not saying, "We think Britney Spears is cute." It's claiming that vulnerabilities have been found faster in one browser versus another over a certain period of study.
Our discussion is about the merits of that claim. It's called a rational discussion. I'm sure there will be some subjective opinions thrown in as well. After all, we're not a corporation issuing a press release on the findings of a security study, so tests of intellectual rigor are a bit different here.
This is a great point. It's not just an abstract matter of customer choice, either. It has fundamental implications for security.
Consider that all manufacturing industries are concerned about security of supply. That means if I'm making cars, for example, I want to be sure that I can get drivetrain components from multiple suppliers. If I find some kind of defect in a component, I can switch to another supplier. That's critical to my manufacturing operations, so a supplier that tries to limit my choice is a supplier that threatens the security of my business.
The other factor, of course, is modularity itself. Gordon Bell famously said, "The cheapest, fastest, and most reliable components of a computer system are those that aren't there." Secure designs are modular, so that (a) insecure components can be replaced by secure ones, and (b) the security risk from components not required can be removed entirely.
This is old stuff, as we all know. So why does a supposed authority on security not only miss the obvious analytical and statistical requirements of meaningful comparison, but go on to publish its findings?
Could there be any possibility of bias as a result of the strategic partnership between Symantec and Microsoft? Just a thought.