The reason I ask is that in my professional life I often find myself working with people who generally appear to be talented but are almost invariably uncooperative.
And this is not about the hard or contentious problems where reasonable people might be expected to differ. It's the simple stuff, sending a requested file, enabling access for a new employee, things that only take a couple of minutes to do, but which stall projects completely when not done.
Such is not my experience in any other field, technical or otherwise. And the computing culture didn't use to be this way even a decade ago. Something has changed, and I would really like to understand it better.
The judgement was to dismiss a motion for relief which would have disallowed the case from being heard in Ontario.
The judge seems to have thorougly considered the factors which bear on the motion. In particular, the jurisdiction where harm has taken place and continues to take place, while not exclusively Canada owing to the international reputation of the plaintiff, is substantially Canada at this time. Conversely, the defendants are not all in one jurisdiction, so that it's not clear, from the position of judging this motion, that a more satifactory jurisdiction can be identified.
The section of the judgement entitled Comity and the standards of jurisdiction is interesting to me because it shows that the judge has closely followed how similar matters have been settled recently in other jurisdictions:
The High Court of Australia has very recently rendered judgment in a very similar factual situation. In Dow Jones & Company Inc. v. Gutnick, [2002] H.C.A. 56 (10 December 2002), a corporation registered in the United States, published material on the Internet that was allegedly defamatory of Mr. Gutnick, who sued in the Supreme Court of Victoria to recover damages to vindicate his reputation. In a unanimous decision, the High Court of Australia held that the Australian courts had jurisdiction over the matter.
Altogether, the law that is emerging here is extremely valuable. It takes us, by reasonable steps, toward international accountability for torts which have international effect. In other words, you can make a mess in your own back yard, but once you start throwing things over the fence, your neighbors have jurisdiction.
Engineers do not get one thing: no invention can be spread around the world until it can be sold.
So, I guess things like the wheel, the lever, the inclined plane, writing, agriculture, wine, bread, these inventions came into use principally by being sold by one party to another?
How about sailing vessels, windmills, the crossbow, the printing press, the steam engine, aircraft? These exist only through a process of being manufactured and then sold to a waiting market? What about radio, vacuum tubes, the computer, the Internet? Interest in these inventions spread only because of artifacts being sold?
History gives me a different understanding of how inventions come into use. All of these inventions spread because they were interesting. People began by sharing their principles of operation, learned methods of construction, and then applied the results directly to their own needs. Sometimes the application was private, sometimes collective. Sometimes, but not inevitably, the application is suitable for commercialization and sale. Seldom does it prove exclusively a commercial product.
In this world everything is sold, not bought.
Evidently not. I've given several examples, and I'm sure you can imagine others. Open source is one of them.
The idea that a design isn't finished until the system (as implemented) has been tested and shown to work is helpful, in my opinion. After all, fundamental design problems can show up at any point.
I absolutely agree.
My comments were in response to a posting entitled "ideally this would be true" which in turn was a comment on the choice of title for the Slashdot article "The Code is the Design".
I take it that you find the Shashdot title misleading, to which, again, I can only agree.
If you subsume the design into the implementation, then someone who goes looking at the implementation will have no way to distinguish between what was a design decision from what should be relatively arbitrary implementation decisions.
I should acknowledge that you could subsume the implementation into the design, if only you had some perfect means of generating code directly from design. That's what the original post was suggesting.
You'll still end up with an implementation separated from the design by whatever mechanism was used to generate it. Implementation errors would then be evidence of a problem with the mechanism. How you would know that is a bit of an open question.
At any rate, if you could express the design in a completely formal way, such a mechanism would in principle be sufficient. And that raises the question of how valuable comments would be in the design document. If they were meaningful to the design, they would have to take the form of assertions in design language. If not meaningful in a design sense, they would have to refer purely to externalities.
If you subsume the design into the implementation, then someone who goes looking at the implementation will have no way to distinguish between what was a design decision from what should be relatively arbitrary implementation decisions.
Why is the distinction important? Two reasons, really. One is versatility. You don't want to constrain a design to having just one implementation. It's useful to be able to choose among competing implementations, say for the Java Virtual Machine for example, because implementation tradeoffs tend to have practical, often emergent and unforseen, consequences.
The other is containment, an aspect of modularity. Since errors, including security vulnerabilities, can be expected to arise during both design and implementation, the most basic way to identify and manage them is to separate them during development. No implementation can make up for bad design, not if it's correct with respect to that design anyway, but at least the effects of a bad implementation can be addressed without breaking the design. But only if the two are clearly separated.
All we need for transmission is a solar cell that will produce power at 10KV AC or higher. Or an efficient way to invert from low voltage DC to transmission voltage, while maintaining phase synchronization with the grid.
I'm inclined to agree. Technical language can be embarrassingly ponderous, especially when used imprecisely by management and others who don't quite know what a term means but want to give the impression of expertise. My current favorites are:
utilize
- You mean "use"?
architecture
- A fairly precise term in system engineering, its common meaning, like art, merely invites debate.
granular
- As in "a more granular approach." Used correctly, means that the granules are more evident, ie larger. In recent practice, intended to mean that the granules are smaller, for which the correct term is fine-grained.
leverage
- The verb "to leverage." Commonly used to demonstrate that the speaker is illiterate.
going forward
- The prepositional phrase. Can be safely removed from any context without loss of meaning.
It's wise to remember that we're working in a field which is fundamentally engaged with the question of how to build things from zeroes and ones. In effect, we're defining the physics of a new universe. Thus we're bound to create new ways of talking about what that means, and since language is based on metaphor, we typically proceed by adapting terms from other disciplines.
So, in the case of methodology for example, it's quite accurate to say that we are making a "study of methods," even if that fact happens not to be apparent to some of the people using the term. When it comes to application, the term has come to mean "a body of related methods," which in its own way seems a distinctive and useful extension of the original meaning. And, by the way, we can no longer simply use the word method since that has acquired its own distinctive meaning in object-oriented programming.
But yeah, "apply a methodology?" Probably doesn't mean what the speaker thinks it means.
The longstanding pattern of providing easy credit predates the Internet. It has led to practices that are insecure by the most rudimentary standards. And yet, it has certainly been profitable for the providers.
Between the transaction fees charged to the merchants, and the interest collected on credit, revenues for the providers have been greater than losses due to fraud.
You would think that all parties would benefit from better security, but evidently the providers don't see it that way. As you probably know, their core operations are very secure, so it's not as if they haven't been willing to act on security risks which they perceive to be significant.
As you imply, various levels of government are already responsible for issuing the various forms of primary identification which will subsequently be used, by third parties, to sign your certificates.
It makes perfect sense to issue a companion certificate to each of these primary forms of identification. There are good reasons for expiring many forms of identity, and certificates are no different in this regard. Just make the expiry date of the certificate correspond to the expiry date of the identity document or license. The authority and all of the related procedural infrastructure is already in place. So how hard could it be?
By the way, Canada Post was registered a few years ago as a Certificate Authority, but no longer. I'd be interested in knowing the politics behind its disappearance.
In OpenSSL, just call SSL_set_verify with a mode of SSL_VERIFY_NONE. The connection will be encrypted without verifying the identity of either the server or the client.
Aren't you just trading one monopoly (the telco's and cable company) for another (the municipality)? [...] Is there something obvious that I'm missing?
You get to elect the municipal government.
You have zero say in the affairs of a corporation unless you have an ownership interest.
Listen, there's no law that says that an organization has to run an incompetent IT operation. But it's clearly up to the organization to come up with the resources to sustain a competent IT operation.
What doesn't make sense is to download this role onto individual users. That never makes sense in an organizational setting. It may make sense when there is no organization, no resources in common, no computing infrastructure. Under those circumstances, of course, people are free to do whatever they want.
But if I'm providing your computing environment, no, sorry, your claims that as an engineer you "understand the problem domain" of computing infrastructure better than my computing staff are not something I'm likely to entertain. I didn't contract with you for that function. I hired them for that. If I hired the wrong people (as happens often enough) the correct solution is not for you to take over that function. The solution is for me to hire competent people.
I don't doubt that people in your organization think that users need to be able to install their own software. I've seen many organizations like that.
However, these people are wrong, and your organization is suffering because of it. Why are your staff "playing" with software instead of getting on with their work? Are they all professionally engaged as software testers?
Surely, if the software is considered valuable to productivity, it should be up to the organization to identify it, obtain it, and maintain it in a consistent and reliable manner.
It's extremely inefficient to have each user figure out how to do this individually, since such an arrangment offers zero economies of scale. Never mind that this kind of chaos creates barriers to integration, produces inconsistent results, induces support costs, and compromises security. The direct loss of individual productivity and cost control should be obvious to anyone responsible for the computing environment.
Typically, the problem is that nobody is properly responsible for the computing environment, or they have inadequate resources. Under those conditions, of course users will be on their own, and then they have a legitimate reason for doing as you describe. But all that's happening is that the organization has pushed the support costs down onto the users.
Now you've got some engineer earning six figures whose salary is being spent in playing with software instead of working on projects that earn revenue for the organization. And you say that every other engineer is doing some personal variation of the same thing? Anything strike you as odd about this picture?
If a support tech can only support 40 windows PCs, but another support tech can support 200 Linux PCs, is the difference the amount of support or the intelligence of the tech.
That doesn't logically follow. You have expressed two free variables in the statement, so any difference in outcome could be due to either.
Okay, so what was the point of the hash? It was supposed to already be a sufficient basis for uniquely identifying the data.
If it is sufficient, then adding additional metadata is not useful. If it isn't sufficient, then you really need a cryptographically comparable substitute, or all you will have achieved is a false sense of security combined with additional complexity and greatly reduced portability. So simple metadata is not useful, you have to apply and compare multiple algorithms. I'll come back to this later.
I guess it really comes down to whether or not you buy into a cryptosystem approach to security in the first place. It's certainly not the only architectural approach. But considering that security is highly sensitive to both simplicity and modularity, anything that advances these principles will tend to yield a more secure design, as well as a more reliable one. The choice to use a cryptosystem is usually made because it promises to do so better than other approaches.
Simple, modular systems are easier to reason about, therefore have greater potential of being designed and verified correctly. The whole motivation for developing something like a hash function is driven by conservative design. The hash is supposed to have known cryptographic properties, consume known computational resources, and interoperate in known ways with other subsystems.
So from an architectural perspective, it makes very limited sense to think about externally enhancing a cryptosystem used for any general purpose. Either it's inherently good enough as it stands, or it has inherent problems which need to be fixed within the cryptosystem. Given limited resources, and in view of basic design principles, it makes sense to put the development and verification effort into a common system. Then everyone benefits.
To return to the more general question of whether a system could use multiple algorithms to provide a form of fault tolerance, yes, that could be useful in a cryptosystem context, as it is in other critical applications. Bear in mind that it comes at a high computational price, and with more structural complexity. If our scenario is that we don't fully trust any single algorithm, then it makes sense to have them watch each other. Usually we do trust the algorithm, in which case any additional cycles and bits might as well go directly into making it stronger.
So, couldn't you just add the size of the file to the signature?
Think about it like this. You'd have to add it in such a way that the signature length remains constant.
Any bits you reserve for data length are thus taken away from bits available to hash the data. You lose considerably more uniqueness that way than you stand to gain.
You seem to be arguing that hypocrisy is just a refinement of opinion.
And yes, since you asked, whenever I put my point of view on record, I think it only reasonable to expect it to be scrutinized for consistency with other expressions I may make at other times.
This attitude is called taking responsibility. I understand that not everyone has a firm grasp of the concept. But when someone with enormous wealth and influence shows a consisten neglect for responsibility, I see no merit in coming to their defense.
That's why the file begins with the following text:
/* Do not edit this file. * * If you make changes to this file while the browser is running, * the changes will be overwritten when the browser exits. * * To make a manual change to preferences, you can visit the URL about:config * For more information, see http://www.mozilla.org/unix/customizing.html#prefs */
Sometimes it's not a simple black-and-white issue.
Here we have an apparent tradeoff between generality and security, manifested as a phishing exploit. Support for international character sets seems innocent enough it itself, but it turns out to have some potential to mislead the human observer.
However, precisely the same security problem exists even without reference to international character sets. In plain ASCII, the characters "0" and "O" are nearly homologous, as are "1" and "I".
In general, phishing attacks exploit any kind of substitution which can at least temporarily deceive a human observer. A plausible, but deceptive, domain name would do just as well.
It's not clear, therefore, that an effective security solution to phishing can ever be automated. Instead, it will have to create more favorable conditions for human perception.
If you set it only in the browser session, it will survive as long as the session.
Permanent browser settings for Mozilla and Firefox can be made by editing the configuration file user.js. To set network.enableIDN, add the following line:
Slashdot Mirror
The reason I ask is that in my professional life I often find myself working with people who generally appear to be talented but are almost invariably uncooperative.
And this is not about the hard or contentious problems where reasonable people might be expected to differ. It's the simple stuff, sending a requested file, enabling access for a new employee, things that only take a couple of minutes to do, but which stall projects completely when not done.
Such is not my experience in any other field, technical or otherwise. And the computing culture didn't use to be this way even a decade ago. Something has changed, and I would really like to understand it better.
The judgement was to dismiss a motion for relief which would have disallowed the case from being heard in Ontario.
The judge seems to have thorougly considered the factors which bear on the motion. In particular, the jurisdiction where harm has taken place and continues to take place, while not exclusively Canada owing to the international reputation of the plaintiff, is substantially Canada at this time. Conversely, the defendants are not all in one jurisdiction, so that it's not clear, from the position of judging this motion, that a more satifactory jurisdiction can be identified.
The section of the judgement entitled Comity and the standards of jurisdiction is interesting to me because it shows that the judge has closely followed how similar matters have been settled recently in other jurisdictions:
Altogether, the law that is emerging here is extremely valuable. It takes us, by reasonable steps, toward international accountability for torts which have international effect. In other words, you can make a mess in your own back yard, but once you start throwing things over the fence, your neighbors have jurisdiction.So, I guess things like the wheel, the lever, the inclined plane, writing, agriculture, wine, bread, these inventions came into use principally by being sold by one party to another?
How about sailing vessels, windmills, the crossbow, the printing press, the steam engine, aircraft? These exist only through a process of being manufactured and then sold to a waiting market? What about radio, vacuum tubes, the computer, the Internet? Interest in these inventions spread only because of artifacts being sold?
History gives me a different understanding of how inventions come into use. All of these inventions spread because they were interesting. People began by sharing their principles of operation, learned methods of construction, and then applied the results directly to their own needs. Sometimes the application was private, sometimes collective. Sometimes, but not inevitably, the application is suitable for commercialization and sale. Seldom does it prove exclusively a commercial product.
In this world everything is sold, not bought.
Evidently not. I've given several examples, and I'm sure you can imagine others. Open source is one of them.
I absolutely agree.
My comments were in response to a posting entitled "ideally this would be true" which in turn was a comment on the choice of title for the Slashdot article "The Code is the Design".
I take it that you find the Shashdot title misleading, to which, again, I can only agree.
I should acknowledge that you could subsume the implementation into the design, if only you had some perfect means of generating code directly from design. That's what the original post was suggesting.
You'll still end up with an implementation separated from the design by whatever mechanism was used to generate it. Implementation errors would then be evidence of a problem with the mechanism. How you would know that is a bit of an open question.
At any rate, if you could express the design in a completely formal way, such a mechanism would in principle be sufficient. And that raises the question of how valuable comments would be in the design document. If they were meaningful to the design, they would have to take the form of assertions in design language. If not meaningful in a design sense, they would have to refer purely to externalities.
Why is the distinction important? Two reasons, really. One is versatility. You don't want to constrain a design to having just one implementation. It's useful to be able to choose among competing implementations, say for the Java Virtual Machine for example, because implementation tradeoffs tend to have practical, often emergent and unforseen, consequences.
The other is containment, an aspect of modularity. Since errors, including security vulnerabilities, can be expected to arise during both design and implementation, the most basic way to identify and manage them is to separate them during development. No implementation can make up for bad design, not if it's correct with respect to that design anyway, but at least the effects of a bad implementation can be addressed without breaking the design. But only if the two are clearly separated.
All we need for transmission is a solar cell that will produce power at 10KV AC or higher. Or an efficient way to invert from low voltage DC to transmission voltage, while maintaining phase synchronization with the grid.
It's wise to remember that we're working in a field which is fundamentally engaged with the question of how to build things from zeroes and ones. In effect, we're defining the physics of a new universe. Thus we're bound to create new ways of talking about what that means, and since language is based on metaphor, we typically proceed by adapting terms from other disciplines.
So, in the case of methodology for example, it's quite accurate to say that we are making a "study of methods," even if that fact happens not to be apparent to some of the people using the term. When it comes to application, the term has come to mean "a body of related methods," which in its own way seems a distinctive and useful extension of the original meaning. And, by the way, we can no longer simply use the word method since that has acquired its own distinctive meaning in object-oriented programming.
But yeah, "apply a methodology?" Probably doesn't mean what the speaker thinks it means.
The longstanding pattern of providing easy credit predates the Internet. It has led to practices that are insecure by the most rudimentary standards. And yet, it has certainly been profitable for the providers.
Between the transaction fees charged to the merchants, and the interest collected on credit, revenues for the providers have been greater than losses due to fraud.
You would think that all parties would benefit from better security, but evidently the providers don't see it that way. As you probably know, their core operations are very secure, so it's not as if they haven't been willing to act on security risks which they perceive to be significant.
As you imply, various levels of government are already responsible for issuing the various forms of primary identification which will subsequently be used, by third parties, to sign your certificates.
It makes perfect sense to issue a companion certificate to each of these primary forms of identification. There are good reasons for expiring many forms of identity, and certificates are no different in this regard. Just make the expiry date of the certificate correspond to the expiry date of the identity document or license. The authority and all of the related procedural infrastructure is already in place. So how hard could it be?
By the way, Canada Post was registered a few years ago as a Certificate Authority, but no longer. I'd be interested in knowing the politics behind its disappearance.
In OpenSSL, just call SSL_set_verify with a mode of SSL_VERIFY_NONE. The connection will be encrypted without verifying the identity of either the server or the client.
But haven't you thought about this? The former strictly requires the latter.
You get to elect the municipal government.
You have zero say in the affairs of a corporation unless you have an ownership interest.
In a Grid context, people usually mean Condor-G.
What doesn't make sense is to download this role onto individual users. That never makes sense in an organizational setting. It may make sense when there is no organization, no resources in common, no computing infrastructure. Under those circumstances, of course, people are free to do whatever they want.
But if I'm providing your computing environment, no, sorry, your claims that as an engineer you "understand the problem domain" of computing infrastructure better than my computing staff are not something I'm likely to entertain. I didn't contract with you for that function. I hired them for that. If I hired the wrong people (as happens often enough) the correct solution is not for you to take over that function. The solution is for me to hire competent people.
However, these people are wrong, and your organization is suffering because of it. Why are your staff "playing" with software instead of getting on with their work? Are they all professionally engaged as software testers?
Surely, if the software is considered valuable to productivity, it should be up to the organization to identify it, obtain it, and maintain it in a consistent and reliable manner.
It's extremely inefficient to have each user figure out how to do this individually, since such an arrangment offers zero economies of scale. Never mind that this kind of chaos creates barriers to integration, produces inconsistent results, induces support costs, and compromises security. The direct loss of individual productivity and cost control should be obvious to anyone responsible for the computing environment.
Typically, the problem is that nobody is properly responsible for the computing environment, or they have inadequate resources. Under those conditions, of course users will be on their own, and then they have a legitimate reason for doing as you describe. But all that's happening is that the organization has pushed the support costs down onto the users.
Now you've got some engineer earning six figures whose salary is being spent in playing with software instead of working on projects that earn revenue for the organization. And you say that every other engineer is doing some personal variation of the same thing? Anything strike you as odd about this picture?
That doesn't logically follow. You have expressed two free variables in the statement, so any difference in outcome could be due to either.
Because the simulation can't be cross-examined.
If it is sufficient, then adding additional metadata is not useful. If it isn't sufficient, then you really need a cryptographically comparable substitute, or all you will have achieved is a false sense of security combined with additional complexity and greatly reduced portability. So simple metadata is not useful, you have to apply and compare multiple algorithms. I'll come back to this later.
I guess it really comes down to whether or not you buy into a cryptosystem approach to security in the first place. It's certainly not the only architectural approach. But considering that security is highly sensitive to both simplicity and modularity, anything that advances these principles will tend to yield a more secure design, as well as a more reliable one. The choice to use a cryptosystem is usually made because it promises to do so better than other approaches.
Simple, modular systems are easier to reason about, therefore have greater potential of being designed and verified correctly. The whole motivation for developing something like a hash function is driven by conservative design. The hash is supposed to have known cryptographic properties, consume known computational resources, and interoperate in known ways with other subsystems.
So from an architectural perspective, it makes very limited sense to think about externally enhancing a cryptosystem used for any general purpose. Either it's inherently good enough as it stands, or it has inherent problems which need to be fixed within the cryptosystem. Given limited resources, and in view of basic design principles, it makes sense to put the development and verification effort into a common system. Then everyone benefits.
To return to the more general question of whether a system could use multiple algorithms to provide a form of fault tolerance, yes, that could be useful in a cryptosystem context, as it is in other critical applications. Bear in mind that it comes at a high computational price, and with more structural complexity. If our scenario is that we don't fully trust any single algorithm, then it makes sense to have them watch each other. Usually we do trust the algorithm, in which case any additional cycles and bits might as well go directly into making it stronger.
Think about it like this. You'd have to add it in such a way that the signature length remains constant.
Any bits you reserve for data length are thus taken away from bits available to hash the data. You lose considerably more uniqueness that way than you stand to gain.
And yes, since you asked, whenever I put my point of view on record, I think it only reasonable to expect it to be scrutinized for consistency with other expressions I may make at other times.
This attitude is called taking responsibility. I understand that not everyone has a firm grasp of the concept. But when someone with enormous wealth and influence shows a consisten neglect for responsibility, I see no merit in coming to their defense.
Especially when you contradict yourself:
That's why the file begins with the following text:
Persistent changes are made using user.js.Here we have an apparent tradeoff between generality and security, manifested as a phishing exploit. Support for international character sets seems innocent enough it itself, but it turns out to have some potential to mislead the human observer.
However, precisely the same security problem exists even without reference to international character sets. In plain ASCII, the characters "0" and "O" are nearly homologous, as are "1" and "I".
In general, phishing attacks exploit any kind of substitution which can at least temporarily deceive a human observer. A plausible, but deceptive, domain name would do just as well.
It's not clear, therefore, that an effective security solution to phishing can ever be automated. Instead, it will have to create more favorable conditions for human perception.
Permanent browser settings for Mozilla and Firefox can be made by editing the configuration file user.js. To set network.enableIDN, add the following line: