Yes, this is a (characteristically) misleading report for all the comparative factors you cite.
It also characteristically ignores how each browser embodies accepted security principles. One of the most important of these is modularity.
In any industry, it's important to be able to replace defective components, and by the same token, it's important to have alternate suppliers for these components. But that can only happen when such components are (a) standardized and (b) replaceable.
Standards compliance
Firefox strategically supports web standards. IE strategically breaks them, thus compromising modularity. The issue is not perfection, since no browser is perfectly standards compliant, but intent and degree.
Component replacement
Firefox, and other browsers, can be installed and removed cleanly. Microsoft has famously claimed in court, that IE and Windows systems are so tightly integrated that IE cannot be replaced without breaking the system. It deliberately advances this strategy of breaking modularity, under the term "integrated innovation."
I was going to say that a big part of any support activity is managing expectations.
People on a commercial aircraft can't get up in the middle of the flight and go try to cook their own meals in the galley. It's simply unworkable, so it's not permitted, and people have come to accept this.
The problem in many computing environments is that people expect freedom without responsibility. That didn't use to be so, but even now all it would take to prevent the majority of problems would be to configure the environment to restrict both.
It's not fair to just suddenly lower the boom on users, but as far as I'm concerned, when they are allowed to install software on the office computers, something is deeply out of whack with the organization. It's not a technical problem, it's a policy problem, and senior management is responsible for fixing it.
I can't count how many times each DAY that I hear and/or see someone in IT doing something they would scream at a "user" for doing.
You raise a good point.
Obviously the purpose of making a special group responsible for system administration is to put this very powerful and potentially risky activity in the hands of qualified experts. Thus risk is managed by constraining responsibility. That said, I encourage my system staff to make a practice of "eating their own dogfood."
In other words, if a given policy is such a great idea, let's see what happens when we too have to abide by it. Presenting that challenge sometimes works wonders:
Unworkable policies get discovered and fixed quickly. We get in the habit of trying out a policy change on ourselves before releasing it.
The security principle of least privilege is fully, not selectively, applied in practice.
Technical staff gain some empathy for users.
Staff also gain some leverage over demanding users. Some user claims that he needs root to do something or other, we know the contrary from firsthand experience.
Take it up with the W3C. See if you can get them to change the definition of pixel in the CSS specs.
I sometimes wonder if it might have been a mistake to allow expressions involving pixels at all. I agree that a stylesheet which uses them is either going to induce usability problems, or it's going to have broken semantics. Use scalable metrics such as percent, or points, or ems.
I am the browser's user, the browser exists to serve me.
Oh, what a fun person you must be on an evening out on the town.
But I do admire your willingness to take responsibility. So, go right ahead and hack your browser to your heart's content. It will no longer be standards-compliant, but if that's your preference, you're not affecting anyone but yourself. And maybe you'll come up with something truly innovative that way. It's happened before.
For those interested in standards compliance, here's what the CSS 1 spec has to say about pixels:
Pixel units, as used in the last rule, [referring to font specification] are relative to the resolution of the canvas, i.e. most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the UA should rescale pixel values. The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is about 0.0227 degrees.
Too bad, the stylesheet says 11px, so 11px is what you're going to get. Meh.
It's what you should get, because that's what the designer specified. You specify it in pixels, you get it in pixels. You specify it in points, or ems, then you can expect the fonts to resize.
Esperanto, although more consistent than many national languages because it was created by one man from nothing, has its fair share of irregularities in syntax.
Can you offer any examples? I'm not aware of any, but I don't have your practical exposure to the language. My comments are based on a copy of Cresswell and Hartley, Teach Yourself Esperanto which I have in front of me, in which the grammar is concisely described. It appears completely regular.
Even after a decade I found that Esperanto simply doesn't provide the authentic communication that national languages do.
A few years ago when I was in Amsterdam, I was surprised to notice that telephone services are available there in Esperanto. Are you suggesting that this was in fact impossible?
The [Esperanto] movement in general is somewhat of a cult, and people would do best to stay away from it.
I can't speak to that, since I have no involvement with it. I'm only interested in it in relation to computational grammar processing, which is the subject under discussion.
Certainly it's possible for a technically good idea to become tainted by politics. That's another subject, but a legitimate one so long as we approach it independently. The political dimension seems to be the subject of your essay, and it may well be valid. I remember that when I was an undergrad, I proposed an Esperanto parser for one of my Artificial Intelligence courses, and was a bit shocked at the intensity of the rejection that I got from the professor. A couple of weeks later, we got talking about it, and he confessed that he was really working through some kind of unpleasant family experience involving Esperanto. I figured it was just an isolated thing, but it seems to validate your experience.
Like Esperanto, for example. Its syntax is completely regular. Parsing is straightforward, and independent of semantics. Just as important, the language is also effective for ordinary human communication.
It's known that languages such as English are difficult, and in some cases impossible, to parse without understanding of the world which the language is intended to represent. So, for example:
Time flies like an arrow.
Fruit flies like a banana.
The next problem is that we haven't figured out a way to make security modularise.
You raise several really interesting points.
I think it would be more correct to say that we haven't found a way to reduce the general security problem by means of modularization. It's an open conjecture that we could do so, even in principle, since we don't actually know what the general security problem is.
However, to the degree that we can isolate information processing into modular elements, we can individually reason about their security, and as far as I understand, those security properties are preserved under composition.
There are two parts to this. The first is to show that the application of functions such as F(G(x)) or (F*G)(x) need not expose functions F and G to each other. That is, composition doesn't violate modularity in the ordinary sense. I take your point that a faulty compiler is in a position to violate modularity, but that's an implementation error, not a reason to discard the formalism.
The second is that we have formalize what composition means in terms of information exchange. Ordinarily, composition is assumed to be purely a matter of topology. As in circuit topology, the wires don't count. But in the context of security, the interface explicitly exposes communication. But communication security has been very well studied, and we should be able to apply the results here directly.
Some details of my understanding may be wrong, and I'd be grateful for your thoughts on any of this.
Isn't that rather like setting the fox to guard the henhouse?
The controls that an organization would need to put in place to avoid being utterly exploited in such a scenario are pretty much the same controls needed to manage systems securely in the first place. So as a thought experiment, this is useful. As an actual practice, forget it.
Let's face it, do you want to be the one who has to train all these government employees how to use OpenOffice.
Is that a Request for Proposal? Because sure, I'd be happy to make money training people in a technology that empowers them rather than locks them into the products of a single vendor. It's certainly no harder to develop a curriculum for OpenOffice than it is for Microsoft Office, and the benefits are much more enduring.
In fact, the Government of Ontario contacted me about just this sort of training a couple of weeks ago. Clearly, Massachusetts is not alone in taking this initiative. And as the world moves systematically toward open document formats, I expect there will be many more of these business opportunities coming.
This doesn't even get into explaining to grandparents how to file/read state tax forms online.
You mean that Massachusetts is using an online tax form that only works with proprietary software? If true, it seems pretty irresponsible to limit public access to a process which they are required by law to follow. Yes, it will definitely be an improvement to get rid of artifacts like this.
At current prices and density, disks often work out to be cheaper per byte than tape.
For ordinary backup requirements, where data only has to be retrievable for a few months or years, disks can be useful. Under these conditions, the mean time between failures of the backup drives is at least as good as that of the production drives.
Archival backup, however, depends on an extremely low rate of failure over a very long time. The ideal backup medium is not only stable but can also be read using simple methods, so that failure of mechanism will not make the data irretrievable. For that purpose, disk drives aren't good candidates.
A similar but broader term is "secure by default."
I like it better than "default deny" as a security principle because it suggests a process rather than a static state of affairs. The process begins with a system which is known to be configured secure by default. You then change the configuration to suit your operational requirements.
The list of configuration changes thereby becomes something you can explicitly reason about, validate against security policy, translate to new platforms and new conditions, and track changes over time. It's an extremely powerful reasoning tool, because it relates directly to your requirements.
The article really fails to address any real issue with security.
In my experience, the kind of flawed reasoning which Marcus Ranum describes is pervasive within the computer industry. As such, it specifically impacts security.
And far from being particularly a management problem, this thinking seems to be just as common among technical staff as well. It's a rare pleasure to find a system administrator or software developer who carefully reasons about security in terms of its principles rather than claiming some sort of security expertise by citing a few familiar security phenomena.
Not to pick on you personally, but your comments are a handy way to illustrate the problem. You've correctly identified software design, and a few implementations of the containment principle, as security issues, which they certainly are. You've then incorrectly inferred that solving these few specific problems solves the security problem generally.
It's obvious that security covers a whole lot more ground than these few items, so clearly your reasoning is flawed, yet even highly experienced technical people tend to think the way you do. Why is that? I suspect it's because in most problem domains, a person is thought to do good work who can deliver a solution that satisfies a given set of requirements. Technical people are especially conditioned to do this. You get points for snapping off quick answers, as long as they work, and usually their validation is obvious.
In security, this is utterly the wrong approach. The person who answers the most quickly is often the first to mark himself as an idiot. That's because a secure solution not only has to do the intended action, it must never do any unintended action. How much time did you spend thinking about that second constraint? Usually you don't have to, but if you want to reason about security, it's pretty much all you do.
The shopping list that Dan Zambonini has come up with is fine, as far as it goes. I'd consider someone who'd mastered that list to be well qualified as a computer technologist. He's chosen subject matter which is widely applicable and technologically stable. So this could be an appropriate curriculum for a good technical college. Most colleges, in my experience, fall far short of satisfying this list, so I'd agree that there is definitely room for improvement.
But it's not science. It could be argued that a typical computer science curriculum doesn't teach much science either. Quite possibly the coursework needs to be strengthened, though I know from my modest contacts with curriculum development that in practice it very much depends on how fast students can absorb the material and consider its implications. Faculty discuss this challenge all the time. To get the basics of computer science in four years is, not surprisingly therefore, about the same process, and about as hard, as doing the same thing in chemistry or any other scientific field.
So it seems inevitable that improvements to the computer science curriculum will move it some distance further away from Zambonini's shopping list than it is already. Science, after all, is a systematic discipline for discovering the nature of the universe.
I notice that Zambonini is not in the least concerned about that. So why look to a science degree to deliver something that's not in fact about science? You're shopping in the wrong store. Learning how to program, for example, is like learning how to operate a mass spectrometer. Of course you have to master the tools, but in science that itself is strictly not the goal. In a technology diploma it pretty much is.
Open standards and Open Source have nothing to do with each other.
Actually, they bear a very close relationship.
It's easiest to understand this by thinking of other industries. Standards arise out of a common consensus around design or implementation.
In order to get to the point of developing a standard, the industry must therefore already have gained experience through open comparison of various designs and implementations.
In most industries, these are fairly self-evident, and standardization is a matter of working out the details. For example, a thread pitch, or a particular dimension of roller chain, or a particular size of tire, can simply be observed, and its merits compared with alternatives that are likewise easy to observe. We tend to forget that most industries depend on physical properties, and physical properties are inherently open.
There is a perception that the software industry is somehow exempt. I think that's only true because of its immaturity relative to other industries. We're like the railroad industry of two hundred years ago, everyone still jealous of their own screw threads and their own track gauge. History tells us that a situation like this is always a temporary impasse.
I'm not trying to argue that open source is an effective substitute for standardization, though in the absence of a standard it at least provides a working reference. Open source simply acts as a precursor to standardization, and it also happens to coexist extremely well with standardization efforts once they are underway.
If it's an open standard, where is the specification authorized and published? That, my friend, is what it means to have a standard for something, like for example the definition of what a meter is, or a thread gauge, or a signalling protocol. The word "standard" isn't just what you want it to mean from moment to moment, and it isn't someone's current best guess at reverse engineering some undisclosed mechanism.
If you lend someone a car, you can request limits on their use of the car -- but I sincerely doubt you could have them charged with a felony because they drove to Arkansas when you told them Arkansas was out of bounds.
I've seen car rental agreements which forbid driving on unpaved roads. Conspicuous violation of the contract may result in some kind of action, such as recovery for damages, or cancellation of the contract, but these terms exist specifically because the law doesn't otherwise provide for the rental company to take action.
Not being an American, I don't understand the fine points of your legal system, but isn't a felony a criminal, not a civil, offense? What statute are these students accused of having offended against?
The tech sector is no different in law than any other workplace. Outside of some specfically agreed terms of engagement, the employer exchanges money for the labor of the employee. This is not a lease-to-own agreement over the employees's soul, or expertise, or anything else.
If that doesn't happen to optimize for the employer, too bad.
I don't see any valid reason for cookies bar one, & I'm not even sure if that one is valid: keeping session logins. AFAIK certificates can't do that
Actually, certificates are ideal for doing that, and hence the capability exists in SSL for validating certificates on both the server and client side. If this is done when establishing an HTTPS connection, then the connection is equivalent to a login session. It has much better security, in fact, but that's another discussion.
So, now the server has a secure connection to an authenticated client. As long as it refers to that connection, it has everything it needs to maintain arbitrary session state, including any desired tracking data. No cookies are required.
This only breaks down because of architectural decisions on the server side which force the use of cookies. The principle of an n-tier architecture is to have a clean separation between different processing layers. To some designers, clean means absolute, so the connection/authentication context ends up not being provisioned into the business logic. I don't think that's great design, but it's the prevailing fashion at the moment.
These Microsoft TCO studies present an analysis that seems ready to backfire on them.
The reason there's a high cost of migration off Microsoft systems is because Microsoft intentionally planned it that way. The "embrace and extend" strategy and many similar practices have been found in law to be designed for the purpose of making migration expensive.
If I were running a fair and objective TCO comparison, I would seek to measure the cost of migration both on and off each platform. Ideally, this would track costs not just once, but over several cycles. Since computing infrastructure is constantly evolving, a realistic TCO analysis has to deal with this scenario.
I don't think that ("good") hackers have any special, hardwired mental abilities or specific personality traits, and I do believe you can easily learn to think like a hacker, even when you come from a different background.
(For a contrasting point of view, see Paul Graham's essay on
Great Hackers.)
I'm inclined to agree that hacking is a state of mind. But it seems that only a certain kind of temperment is drawn to cultivate that state of mind. In practical terms, therefore, personality matters greatly.
From long observation, I would have to say that most people don't know -- and don't want to know -- how things work. In fact, many people have developed quite elaborate defenses against knowing, strange though it may seem to the hacker mind. These people will claim that they don't have time, or that it's risky, or that it's more cost-effective to pay someone else, or that they don't see why it all has to be so hard, et cetera. Hackers seem notably disinclined to raise such objections.
I'm not sure that hackers, as a group, are naturally drawn to rigor and formalism any more than the general population, but most of them seem at least willing to go there if the situation calls for it. Hackers might prefer to immediately start prying the covers off stuff, but if that doesn't work, the more committed ones tend to have no problem reading manuals, circuit diagrams, or assembler code if that's what it takes.
Hackers seem to be well represented by the Myers-Briggs INTJ and INTP personality types. On the other hand, this combination (introverted, intuitive, thinker) is rare in the general population. Most people wouldn't dream of taking the covers off a new piece of gear. To them, it would be far safer not to know than to risk voiding the warranty.
My point is that neither position is objectively more correct than the other. It's a question of what you subjectively value.
So yes, I suppose that anyone could, in principle, learn to think like a hacker. After all, it's not like there's any secret to what's involved. And we live in a highly technological era, where it would seem to make excellent sense to cultivate that way of thinking. But I don't see it happening.
global information such as your address, your name, phone, etc. can be held by the browser
That's where the concept starts, but do you see where I was going with this? What about account numbers? The point I was making was that the benefit typically claimed for cookies is to preserve what is essentially form information that you have to supply anyway, and which might be subject to change that only you know about. (There are other, more defensible, uses of cookies in certain kinds of session management, but even then, they're often misused.)
So, given that it's your information, why aren't you in the position of managing it? Cookies take that away. Pursuing this idea a bit further, I mentioned treating certificates, or even digital signatures, in the same way. That is, if the site claims that it needs to store some sort of authentication data in a cookie, I have to ask what design justifies such authentication being done outside my control. If I'm the one supposedly being authenticated, surely I should be supplying the credentials!
Note that this serves a different purpose, at a different granularity, than the client-side certificates used by SSL/TLS to authenticate the connection. Even so, if the browser already lets you manage these certificates, you're more than halfway there.
Nobody wants to work on the mainframe systems anymore because it "isn't cool." It's not the perceived latest and greatest.
...
It wouldn't hurt for computer science students to learn about mainframes.
I did most of my computer science degree on mainframes. That was fine at the time, but in terms of scope, they're really quite limiting. You're in a virtual enviroment which is designed for extremely safe containment of your activity. You certainly can't test device drivers, modify the kernel, develop network protocols, or even reliably measure system performance.
About all you can do as a mainframe user is learn applications programming and requirements analysis. Consequently, the mainframe workplace tends to be extremely conservative. If that's your temperment, then go for it, but if not, beware!
Slashdot Mirror
It also characteristically ignores how each browser embodies accepted security principles. One of the most important of these is modularity.
In any industry, it's important to be able to replace defective components, and by the same token, it's important to have alternate suppliers for these components. But that can only happen when such components are (a) standardized and (b) replaceable.
Standards compliance
Firefox strategically supports web standards. IE strategically breaks them, thus compromising modularity. The issue is not perfection, since no browser is perfectly standards compliant, but intent and degree.
Component replacement
Firefox, and other browsers, can be installed and removed cleanly. Microsoft has famously claimed in court, that IE and Windows systems are so tightly integrated that IE cannot be replaced without breaking the system. It deliberately advances this strategy of breaking modularity, under the term "integrated innovation."
People on a commercial aircraft can't get up in the middle of the flight and go try to cook their own meals in the galley. It's simply unworkable, so it's not permitted, and people have come to accept this.
The problem in many computing environments is that people expect freedom without responsibility. That didn't use to be so, but even now all it would take to prevent the majority of problems would be to configure the environment to restrict both.
It's not fair to just suddenly lower the boom on users, but as far as I'm concerned, when they are allowed to install software on the office computers, something is deeply out of whack with the organization. It's not a technical problem, it's a policy problem, and senior management is responsible for fixing it.
You raise a good point.
Obviously the purpose of making a special group responsible for system administration is to put this very powerful and potentially risky activity in the hands of qualified experts. Thus risk is managed by constraining responsibility. That said, I encourage my system staff to make a practice of "eating their own dogfood."
In other words, if a given policy is such a great idea, let's see what happens when we too have to abide by it. Presenting that challenge sometimes works wonders:
Take it up with the W3C. See if you can get them to change the definition of pixel in the CSS specs.
I sometimes wonder if it might have been a mistake to allow expressions involving pixels at all. I agree that a stylesheet which uses them is either going to induce usability problems, or it's going to have broken semantics. Use scalable metrics such as percent, or points, or ems.
Oh, what a fun person you must be on an evening out on the town.
But I do admire your willingness to take responsibility. So, go right ahead and hack your browser to your heart's content. It will no longer be standards-compliant, but if that's your preference, you're not affecting anyone but yourself. And maybe you'll come up with something truly innovative that way. It's happened before.
For those interested in standards compliance, here's what the CSS 1 spec has to say about pixels:
It's what you should get, because that's what the designer specified. You specify it in pixels, you get it in pixels. You specify it in points, or ems, then you can expect the fonts to resize.
Can you offer any examples? I'm not aware of any, but I don't have your practical exposure to the language. My comments are based on a copy of Cresswell and Hartley, Teach Yourself Esperanto which I have in front of me, in which the grammar is concisely described. It appears completely regular.
Even after a decade I found that Esperanto simply doesn't provide the authentic communication that national languages do.
A few years ago when I was in Amsterdam, I was surprised to notice that telephone services are available there in Esperanto. Are you suggesting that this was in fact impossible?
The [Esperanto] movement in general is somewhat of a cult, and people would do best to stay away from it.
I can't speak to that, since I have no involvement with it. I'm only interested in it in relation to computational grammar processing, which is the subject under discussion.
Certainly it's possible for a technically good idea to become tainted by politics. That's another subject, but a legitimate one so long as we approach it independently. The political dimension seems to be the subject of your essay, and it may well be valid. I remember that when I was an undergrad, I proposed an Esperanto parser for one of my Artificial Intelligence courses, and was a bit shocked at the intensity of the rejection that I got from the professor. A couple of weeks later, we got talking about it, and he confessed that he was really working through some kind of unpleasant family experience involving Esperanto. I figured it was just an isolated thing, but it seems to validate your experience.
Like Esperanto, for example. Its syntax is completely regular. Parsing is straightforward, and independent of semantics. Just as important, the language is also effective for ordinary human communication.
It's known that languages such as English are difficult, and in some cases impossible, to parse without understanding of the world which the language is intended to represent. So, for example:
You raise several really interesting points.
I think it would be more correct to say that we haven't found a way to reduce the general security problem by means of modularization. It's an open conjecture that we could do so, even in principle, since we don't actually know what the general security problem is.
However, to the degree that we can isolate information processing into modular elements, we can individually reason about their security, and as far as I understand, those security properties are preserved under composition.
There are two parts to this. The first is to show that the application of functions such as F(G(x)) or (F*G)(x) need not expose functions F and G to each other. That is, composition doesn't violate modularity in the ordinary sense. I take your point that a faulty compiler is in a position to violate modularity, but that's an implementation error, not a reason to discard the formalism.
The second is that we have formalize what composition means in terms of information exchange. Ordinarily, composition is assumed to be purely a matter of topology. As in circuit topology, the wires don't count. But in the context of security, the interface explicitly exposes communication. But communication security has been very well studied, and we should be able to apply the results here directly.
Some details of my understanding may be wrong, and I'd be grateful for your thoughts on any of this.
The controls that an organization would need to put in place to avoid being utterly exploited in such a scenario are pretty much the same controls needed to manage systems securely in the first place. So as a thought experiment, this is useful. As an actual practice, forget it.
Is that a Request for Proposal? Because sure, I'd be happy to make money training people in a technology that empowers them rather than locks them into the products of a single vendor. It's certainly no harder to develop a curriculum for OpenOffice than it is for Microsoft Office, and the benefits are much more enduring.
In fact, the Government of Ontario contacted me about just this sort of training a couple of weeks ago. Clearly, Massachusetts is not alone in taking this initiative. And as the world moves systematically toward open document formats, I expect there will be many more of these business opportunities coming.
This doesn't even get into explaining to grandparents how to file/read state tax forms online.
You mean that Massachusetts is using an online tax form that only works with proprietary software? If true, it seems pretty irresponsible to limit public access to a process which they are required by law to follow. Yes, it will definitely be an improvement to get rid of artifacts like this.
For ordinary backup requirements, where data only has to be retrievable for a few months or years, disks can be useful. Under these conditions, the mean time between failures of the backup drives is at least as good as that of the production drives.
Archival backup, however, depends on an extremely low rate of failure over a very long time. The ideal backup medium is not only stable but can also be read using simple methods, so that failure of mechanism will not make the data irretrievable. For that purpose, disk drives aren't good candidates.
I like it better than "default deny" as a security principle because it suggests a process rather than a static state of affairs. The process begins with a system which is known to be configured secure by default. You then change the configuration to suit your operational requirements.
The list of configuration changes thereby becomes something you can explicitly reason about, validate against security policy, translate to new platforms and new conditions, and track changes over time. It's an extremely powerful reasoning tool, because it relates directly to your requirements.
In my experience, the kind of flawed reasoning which Marcus Ranum describes is pervasive within the computer industry. As such, it specifically impacts security.
And far from being particularly a management problem, this thinking seems to be just as common among technical staff as well. It's a rare pleasure to find a system administrator or software developer who carefully reasons about security in terms of its principles rather than claiming some sort of security expertise by citing a few familiar security phenomena.
Not to pick on you personally, but your comments are a handy way to illustrate the problem. You've correctly identified software design, and a few implementations of the containment principle, as security issues, which they certainly are. You've then incorrectly inferred that solving these few specific problems solves the security problem generally.
It's obvious that security covers a whole lot more ground than these few items, so clearly your reasoning is flawed, yet even highly experienced technical people tend to think the way you do. Why is that? I suspect it's because in most problem domains, a person is thought to do good work who can deliver a solution that satisfies a given set of requirements. Technical people are especially conditioned to do this. You get points for snapping off quick answers, as long as they work, and usually their validation is obvious.
In security, this is utterly the wrong approach. The person who answers the most quickly is often the first to mark himself as an idiot. That's because a secure solution not only has to do the intended action, it must never do any unintended action. How much time did you spend thinking about that second constraint? Usually you don't have to, but if you want to reason about security, it's pretty much all you do.
But it's not science. It could be argued that a typical computer science curriculum doesn't teach much science either. Quite possibly the coursework needs to be strengthened, though I know from my modest contacts with curriculum development that in practice it very much depends on how fast students can absorb the material and consider its implications. Faculty discuss this challenge all the time. To get the basics of computer science in four years is, not surprisingly therefore, about the same process, and about as hard, as doing the same thing in chemistry or any other scientific field.
So it seems inevitable that improvements to the computer science curriculum will move it some distance further away from Zambonini's shopping list than it is already. Science, after all, is a systematic discipline for discovering the nature of the universe.
I notice that Zambonini is not in the least concerned about that. So why look to a science degree to deliver something that's not in fact about science? You're shopping in the wrong store. Learning how to program, for example, is like learning how to operate a mass spectrometer. Of course you have to master the tools, but in science that itself is strictly not the goal. In a technology diploma it pretty much is.
Actually, they bear a very close relationship.
It's easiest to understand this by thinking of other industries. Standards arise out of a common consensus around design or implementation. In order to get to the point of developing a standard, the industry must therefore already have gained experience through open comparison of various designs and implementations.
In most industries, these are fairly self-evident, and standardization is a matter of working out the details. For example, a thread pitch, or a particular dimension of roller chain, or a particular size of tire, can simply be observed, and its merits compared with alternatives that are likewise easy to observe. We tend to forget that most industries depend on physical properties, and physical properties are inherently open.
There is a perception that the software industry is somehow exempt. I think that's only true because of its immaturity relative to other industries. We're like the railroad industry of two hundred years ago, everyone still jealous of their own screw threads and their own track gauge. History tells us that a situation like this is always a temporary impasse.
I'm not trying to argue that open source is an effective substitute for standardization, though in the absence of a standard it at least provides a working reference. Open source simply acts as a precursor to standardization, and it also happens to coexist extremely well with standardization efforts once they are underway.
If it's an open standard, where is the specification authorized and published? That, my friend, is what it means to have a standard for something, like for example the definition of what a meter is, or a thread gauge, or a signalling protocol. The word "standard" isn't just what you want it to mean from moment to moment, and it isn't someone's current best guess at reverse engineering some undisclosed mechanism.
Speaking of standards:
I've seen car rental agreements which forbid driving on unpaved roads. Conspicuous violation of the contract may result in some kind of action, such as recovery for damages, or cancellation of the contract, but these terms exist specifically because the law doesn't otherwise provide for the rental company to take action.
Not being an American, I don't understand the fine points of your legal system, but isn't a felony a criminal, not a civil, offense? What statute are these students accused of having offended against?
The tech sector is no different in law than any other workplace. Outside of some specfically agreed terms of engagement, the employer exchanges money for the labor of the employee. This is not a lease-to-own agreement over the employees's soul, or expertise, or anything else.
If that doesn't happen to optimize for the employer, too bad.
Actually, certificates are ideal for doing that, and hence the capability exists in SSL for validating certificates on both the server and client side. If this is done when establishing an HTTPS connection, then the connection is equivalent to a login session. It has much better security, in fact, but that's another discussion.
So, now the server has a secure connection to an authenticated client. As long as it refers to that connection, it has everything it needs to maintain arbitrary session state, including any desired tracking data. No cookies are required.
This only breaks down because of architectural decisions on the server side which force the use of cookies. The principle of an n-tier architecture is to have a clean separation between different processing layers. To some designers, clean means absolute, so the connection/authentication context ends up not being provisioned into the business logic. I don't think that's great design, but it's the prevailing fashion at the moment.
The reason there's a high cost of migration off Microsoft systems is because Microsoft intentionally planned it that way. The "embrace and extend" strategy and many similar practices have been found in law to be designed for the purpose of making migration expensive.
If I were running a fair and objective TCO comparison, I would seek to measure the cost of migration both on and off each platform. Ideally, this would track costs not just once, but over several cycles. Since computing infrastructure is constantly evolving, a realistic TCO analysis has to deal with this scenario.
(For a contrasting point of view, see Paul Graham's essay on Great Hackers.)
I'm inclined to agree that hacking is a state of mind. But it seems that only a certain kind of temperment is drawn to cultivate that state of mind. In practical terms, therefore, personality matters greatly.
From long observation, I would have to say that most people don't know -- and don't want to know -- how things work. In fact, many people have developed quite elaborate defenses against knowing, strange though it may seem to the hacker mind. These people will claim that they don't have time, or that it's risky, or that it's more cost-effective to pay someone else, or that they don't see why it all has to be so hard, et cetera. Hackers seem notably disinclined to raise such objections.
I'm not sure that hackers, as a group, are naturally drawn to rigor and formalism any more than the general population, but most of them seem at least willing to go there if the situation calls for it. Hackers might prefer to immediately start prying the covers off stuff, but if that doesn't work, the more committed ones tend to have no problem reading manuals, circuit diagrams, or assembler code if that's what it takes.
Hackers seem to be well represented by the Myers-Briggs INTJ and INTP personality types. On the other hand, this combination (introverted, intuitive, thinker) is rare in the general population. Most people wouldn't dream of taking the covers off a new piece of gear. To them, it would be far safer not to know than to risk voiding the warranty.
My point is that neither position is objectively more correct than the other. It's a question of what you subjectively value. So yes, I suppose that anyone could, in principle, learn to think like a hacker. After all, it's not like there's any secret to what's involved. And we live in a highly technological era, where it would seem to make excellent sense to cultivate that way of thinking. But I don't see it happening.
That's where the concept starts, but do you see where I was going with this? What about account numbers? The point I was making was that the benefit typically claimed for cookies is to preserve what is essentially form information that you have to supply anyway, and which might be subject to change that only you know about. (There are other, more defensible, uses of cookies in certain kinds of session management, but even then, they're often misused.)
So, given that it's your information, why aren't you in the position of managing it? Cookies take that away. Pursuing this idea a bit further, I mentioned treating certificates, or even digital signatures, in the same way. That is, if the site claims that it needs to store some sort of authentication data in a cookie, I have to ask what design justifies such authentication being done outside my control. If I'm the one supposedly being authenticated, surely I should be supplying the credentials!
Note that this serves a different purpose, at a different granularity, than the client-side certificates used by SSL/TLS to authenticate the connection. Even so, if the browser already lets you manage these certificates, you're more than halfway there.
It wouldn't hurt for computer science students to learn about mainframes.
I did most of my computer science degree on mainframes. That was fine at the time, but in terms of scope, they're really quite limiting. You're in a virtual enviroment which is designed for extremely safe containment of your activity. You certainly can't test device drivers, modify the kernel, develop network protocols, or even reliably measure system performance.
About all you can do as a mainframe user is learn applications programming and requirements analysis. Consequently, the mainframe workplace tends to be extremely conservative. If that's your temperment, then go for it, but if not, beware!