Written by John Ousterhout, the guy who developed Tcl/Tk. So I guess he has a bit of an axe to grind in promotion of events versus threads, but he makes some good points.
I completely agree. In fact there was a great paper on this which came out about ten years ago. Can't find it for the life of me, but it walked through several common examples of multithreading and showed how each could be more simply reimplemented with events. Anyone recognize this paper?
Threading provides an excellent opportunity for programmers to shoot themselves in the foot. If requirements can be satisfied using events, use them!
In fact, no security, of any kind, anywhere, is absolute.
For example, critical US Department of Defense secrets have ended up in the hands of adversaries, despite extreme efforts to safeguard these secrets. And the same is equally true, of course, for other nations. Thus there is demonstrably not a condition of absolute security, even at the most secure end of the scale.
But we're talking here not about military security and state espionage but about web browser vulnerabilities. For the most part the browsers in question are running on consumer grade systems which are not professionally managed. The perception of value and risk for a consumer product is at a much lower point on the scale relative to a hardened military installation. The same security principles apply, of course, but the tradeoffs are characteristically different.
I agree with your comment that it does not help to obscure the security tradeoffs on consumer systems. That encourages misperception. But it also doesn't help to talk about security as if it were all or nothing. That encourages another misperception.
It's not the case that all information is fully exposed if it's not fully secure. The middle ground is quite acceptable for many purposes. For example, safes are rated in terms of how much time is required to break into them, not whether they are or are not absolutely secure. A safe with a higher rating is bigger, heavier, and more expensive. So there is not an absolute solution but instead a range of solutions to suit different needs.
This works because the rating of safes is easy to understand. What we need in the computer industry is a similar objective rating for system security. And as Bruce Schneier points out, this is likely to come about not because of consumer demand directly, but as a result of pressure by the insurance industry.
What's all this about "new risks and threats"? There's nothing remotely new here.
False certificate revocation is an obvious point of attack on certificate infrastructure, and has been ever since CRLs were proposed. Loss of encryption key is a new risk? Yes, to researchers who have been asleep since, oh, 1466 when Leon Battista Alberti developed key crypto.
It's not that we shouldn't pay attention to these risks and incorporate them into our security metrics. Of course we should. But it's not news. I hate it when people grab for attention but then have nothing to contribute.
Yep. Anything short of nicely modulated antigravity is a non-starter for me. Let's see, why is that? Because even the kinetic energy of my own body falling from my own height can be enough to cause permanent injury? Or because superheated gases sufficient for lift are being generated immediately next to me?
Each of these roles is a career path in itself. Well, not tech support, but seven years in any one of the others takes the average CS grad to somewhere around an intermediate level of professional competence.
We've all had our encounters with incompetent IT managers, so I won't even go into the variety of forms that incompetence can take. But it is a challenging position, and in my view, absolutely requires senior technical ability. You cannot lead unless you know where you're going, and few technical people will support your initiative unless they agree with your reasoning.
It's great to acquire broad work experience in each of these areas. I've made a point of doing that myself, and I have no regrets. But it takes considerably more than dabbling for a couple of years at one of these areas before you can begin to talk about it intelligently, let alone lead others.
If there's one thing that characterizes junior technical people, it's that they think they know what they're doing when in fact they have barely a clue. Those kind make the worst managers. I've managed large staffs myself, and found through experience that it's invariably the most junior, least expert, people that give the most grief.
In order to build secure systems for our own reasonable purposes. It would be really nice if I could have a system which is not hackable except by me, but is truly hackable by me. And you could have yours.
Hey, if privacy and security were really in a zero-sum relationship, then designing systems which diminish one would cause the other to increase.
But we know this doesn't happen. It's easy to conceive of systems in which a decrease in privacy leads to a corresponding decrease in security. For example, take an existing bank system and decrease the privacy of administrative passwords. Does this change make the bank system more or less secure? Conversely, take an anonymous ballot system and decrease its security protections against exposing the choices registered by each voter. Does this increase privacy or decrease it?
If we look at fundamentals, systems are secure when the conditions of identity, ownership, and trust are defined and enforced at each point in the system. Just that. Properly specified and implemented systems will provide appropriate access to appropriate parties (the system meets functional specs), and not otherwise (the system meets security specs). People like Ed Giorgio who don't get this are simply not qualified to talk about security.
Java and C don't map so well. There are some things for which only C makes sense currently, such as driver development. Java is a virtual machine.
To be precise, Java is a language specification. It's typically implemented as a virtual machine, but there's no fundamental requirement to do so.
Let's consider Lisp instead for a moment, since Gosling, Steele, et al used it as a conceptual basis for Java. It has an extremely rich history. Lisp predates Java in being implemented as a virtual machine. The dialect was Interlisp.
The Xerox model 11xx AI workstations used Interlisp as the system language. Lisp device drivers and network stacks were also implemented for the MIT Lisp Machine and its commercial derivatives based on variations of MIT Lisp and later Common Lisp. Note particularly that Lisp is running in silicon on these systems. There is no virtual machine.
These systems were not a great commercial success, because they entered the market as very exotic and very expensive research workstations at exactly the same time as commodity microprocessors were experiencing exponential growth. The various Lisp systems just couldn't keep up with commodity growth effects on price/performance. There was nothing functionally lacking with them, and I can say from firsthand experience that it was a pleasure to work on their operating systems.
I'm not convinced that I would enjoy working with an operating system written entirely in Java, but there's no reason such a thing couldn't exist. If a JVM can perform acceptably on top of a foreign processor architecture, it should only perform better without the virtual machine overhead.
The analogy between cell phones and wine seems rather strained to me.
The reason that individuals can offer credentialed expertise in wine as a restaurant service is because they can base it on a body of knowledge which goes back some 9000 years. Yes, wines are complex, tasting is subjective. To that extent, the analogy holds. But unlike the cell phone market, the characteristics of wine, and the particular requirements of fine wine, are stable and well understood. Therefore, both the somellier and the patron gain an enduring advantage through cultivating their wine expertise over time, and the dialogue between them can be efficient and meaningful.
Cell phone capabilities and services, on the other hand, are so extremely volatile that there can be no ground for consensus. It's still possible to go through the exercise of gathering requirements and outlining solutions, an activity which has already been given the name System Analysis. Let's call it what it is, because that tells us what we can reasonably expect from it.
Wardialers are to OOB management as portscanners are to internet-connected management. ...
The same security concerns that apply to network management interfaces apply to OOB management interfaces.
These are excellent points. Given the number of responses, I don't know why you haven't been modded up already.
I've worked with all sorts of organizations who make access to their systems extra slow and tedious by requiring dialin. This is always explained as being for "security" reasons.
Um, no. All they're doing is substituting one physical layer of the network stack for another, neither of which have meaningfully secure access controls. Security, to the degree that it's addressed at all, would have to be done further up the stack. And that being the case, why again do we have to dial in?
Ah, the beauty of the man in the middle attack! The problem is, how do your contacts know they're using *your* public key? If the ISP can successfully intercept everything on all ends (and they could if they cared enough), then they replace your public key with theirs, decrypt incoming traffic using their own public key and re-encrpyt it with your public key. Total bummer.
I pointed out that this is what gave rise to digital certificates, in which your public key is signed by a certificate authority. Anyone encountering the certificate can immediately verify that it has not been tampered with. I also described how to securely transmit a bare public key to that authority so that it cannot be counterfeited at that point either.
You're absolutely right to observe that, despite all these means of verification, there has to be some ultimate thing you trust. You need something to bootstrap the rest of the process. That would be a root certificate in the case of a hierarchical public key infrastructure, though there are other approaches, such as Zimmerman's PGP, which attempt to distribute trust from the bottom up, and others based on trust metrics. In other words, some consideration also should be given to how distant that source of authority is from the particular object of interest to you.
So, while I agree that we each individually have to start with some source of information that we trust, among the various mechanisms which depend on this source, each has strengths and weaknesses. If you go for the single authority approach, say George Bush just for the sake of argument, then (a) if George Bush is compromised then so are you, and (b) George Bush is going to be overwhelmed with requests out of band for root certificates. If, on the other hand, you go for a "web of trust" approach, then (a) your verification effort increases with the number of peers, and (b) you have introduced multiple points of compromise.
What happens in practice is that we make some concessions for the sake of usability. For example, web browsers come with a set of root certificates preinstalled. Who decides this set? Not you, certainly. You can strip them all out, and then install just the root certs that you have received through some, presumed secure, channel. Yes, you could set up a one-time pad with some trusted individual in order to create this channel, but as you point out, you would have to trust that individual completely, and they would have had to trust someone else in order to get their copy of the root cert, and so on. Every such step is an injection point and a dilution of trust, and worse still, you can't determine how many steps there were between the root authority and you.
So your approach ends up delivering an informal, unknown, unquantified, unverifiable effect of trust dilution. The only way around this is to go straight to the certificate authority with your one-time pad, and for reasons of scale that ain't gonna happen. What happens instead, deplorably imperfect though it may be, is that in effect we trust the web browser. If I wanted to distribute a counterfeit root cert, I'd start by installing it into a browser distribution and set it loose on the net.
But this leads to an important observation. Besides trusting some certificate at some point, we inevitably also have to trust the software which puts that certificate to use. There is no way around it. And, if that degree of trust is equivalent, we might as well combine the two together and decide whether or not to trust the whole package. In that case, you might not be satisfied with exchanging a one-time pad with your completely trusted peer. You might want to exchange source code for a very basic web browser or other transfer agent which contains a hardcoded root cert, then use it to bootstrap a signed browser.
But if you're a purist, that's not enough either. Your underlying system might be compromised, such that whatever you try to install, it substitutes its own backdoor. Given industry p
You've been modded "funny" for this. But the point you've made is absolutely valid.
It's not as if the ISP necessarily has any malicious intent. Though, come to think of it, to judge by the quality of customer service of some of them, we might want to leave that as an open question.
But you know what? The only thing that you have to keep private is your private key. That's why you must always generate the key pair locally. Public keys are supposed to be distributed widely. There's no harm in anyone in the middle seeing it in transit. They're not learning anything that you want to be kept secret.
A counterfeit public key will not correspond with your private key, but it could cause grief for any party which encrypts sensitive information with it. This and some other related scenarios are addressed by wrapping the public key in a certificate signed by a trusted authority.
Now, what about the case where you have generated the key pair and want to get it made into a certificate? In order to do this, you have to transmit the bare public key to the certificate authority. That's okay too. You encrypt it with the public key of the authority, contained in a root certificate which by definition is trusted, meaning that you have it already.
what is to stop everyone from encrypting all their traffic?
To give a very abbreviated answer, the network effect for this has not yet taken off. There has been no technical barrier to widespread encryption for over a decade, but there are two social barriers which remain to be overcome:
Education
In order for you to use crypto, you have to know how it works. Most other technologies are not like this, in that they can just kind of operate in the background. But cryptographic communications operate between defined endpoints, and you are one of those endpoints. Understanding takes considerable effort. At minimum, people need to understand how asymmetric crypto works in both message signing and message encryption, and they also must develop some insight into what motivates key distribution, because otherwise they won't be able to make sense of the public key infrastructure in which they must participate. I think it's important enough that ultimately it will be taught as part of the standard school curriculum. But we're a long way from that at the moment.
Sequence
Message encryption is the last in a fairly involved series of steps. This delays the network effect. Participants first have to generate their cryptographic keys and then have them signed by a trusted third party. Then they have to begin signing their own messages with them. As these messages go out, a side effect is to distribute the public keys which are in turn necessary for message encryption. Finally, participants can begin to encrypt messages.
So, there's an elaborate sequence of events, each with a big activation threshold, that have to be crossed in order to trigger the network effect. Until you see a lot of cryptographically signed emails, for example, you can safely assume that there are not yet a lot of encrypted emails in circulation. And the same will be comparably true of any other encrypted protocol.
This explains why adoption has proven to be very slow. There have been many early adopters, of course, but so far evidently not enough to inspire the public at large.
The good news is that we've seen this kind of phenomenon lots of times before. The Internet itself was widely ignored for a long time, despite being completely satisfactory from a technical perspective. Something eventually kicks it into public awareness, and then, if those of us who engineer these things have done our job right, it takes off without a backwards glance.
Well, this highlights the reason why the entire linking argument is specious. As I recall, it just popped up one day out of nowhere, basically because Linus didn't want the kernel to be contaminated with proprietary device drivers. I'm sympathetic to the motive. The means, however, were never reasonable. The GPL itself says nothing about linking. It talks instead only about "incorporation".
Think about it. As soon as you start to extend the linking taboo to the general case, you find yourself on a very slippery slope. It's crazy to suggest that linking to a library leads somehow to a derived work. No, folks, that would be the basis of a little thing we call modularity. It works by means of defined interfaces, in this case through function declarations.
Not function definitions, note. If your program were to contain the body of a function licensed under the GPL, then it would be considered a derived work, since copying a body of code is the essence of incorporation. The GPL forbids incorporation. Fine, excellent. But it nowhere forbids use of an interface to call out to licensed code.
I think your criteria for "stray" are less inclusive than mine.
Perhaps I should have said "not authenticated", though to me these are computationally equivalent. That is, there is no need for a system to distinguish between malicious data and just plain random data. It should reject both.
It's hard to see how anyone with a brain could have not considered the implication of a stray signal setting off the switch actuator, potentially causing loss of life.
I own an area of land which I've thought, somewhat idly, would suit an aerial tramway for moving building materials onto the site. The first thing that crossed my mind was not was how to engineer the rigging. That's textbook stuff. No, my first concern was whether it would be possible to build a remote control that would fail safe.
And what part of "embrace and extend" does he think will be held in abeyance here? Oh, but they said they wouldn't, this time. Anyone care to bet the next release after the approved one doesn't quite roll back to Linux correctly?
I don't know what possible gain for the OLPC project could arise out of this sort of complicity, but something, surely. Why put your head in a noose, otherwise? But to my way of thinking, it just taints an otherwise inspired idea.
But I thought the best way to browse securely was have all traffic sent to your home server, encrypt it, and forward to the laptop.
But this line of reasoning makes no sense. The Internet at large is an insecure network. Whether a host connects with it directly, or over an open wireless segment, does not affect the basic property that traffic to and from the host is exposed.
The only way for two endpoints to satisfy themselves of secure communications over an insecure network is for those endpoints to establish an authenticated and encrypted session between them. For purposes of securing the network, it's not useful to secure just one segment of the network, such as you propose doing between your server and laptop, and pretend that the rest of the network doesn't matter. It does. Conversely, if you can establish endpoint security between some remote host on the network and your laptop, there is no additional value in securing any segment in between.
So Schneier is correct in the sense that having wireless open or closed doesn't change the fundamental network security equation. On the other hand, he is deliberately overlooking the security principle know as defense in depth. A properly secured host doesn't need a firewall, but firewalls are useful as an independent line of defense in case the host is not as well secured as we believe. Schneier knows this principle perfectly well, so I assume that he's being controversial simply in order to stir up debate and get people thinking.
It's not that he wants people to think that open wireless is secure, quite the converse. It's patently insecure, but then so is the Internet in general. So design your endpoing security accordigly.
Ah, but the thing is, I do know better. I'm a professional computer scientist with 30 years of experience in operating systems and user interface design. People like my contribution to the field enough to have paid me millions of dollars over the years.
Whereas, you're posting as an Anonymous Coward with no credentials at all. That's fine, it just means that we're left to judge you on the merits of your argument. And so far, you show only a knack for developing arguments which logically self-invalidate. That's not even passable as sophistry. You understand that, don't you?
The OLPC project, as originally conceived, had huge collaborative potential. Put an open platform into the hands of many, many people. Let them figure out what direction they want to take it.
Close that platform, and suddenly it makes no sense at all. It's no longer an extensible means of cultural and technological expression but just another consumer product, good for nothing more than keeping the Third World in its place, right at the bottom.
We "can" but I would rather not spend 8 hours grepping through trash
Yep. What the parent pretends not to get is that every software developer is posessed of finite cognitive bandwidth. You can expend that bandwidth on the mental bookkeeping necessary to make sense of trashy code, or you can put resources into cleaning up the code so that it is no longer a needless cognitive drain.
Furthermore, once cleaned up, the code stays cleaned up. The next developer to come along will not have to waste time making sense of bad code. Considering the stats on how much developer time goes into reading code written by others, refactoring and other forms of code cleanup is time well spent.
Of course, the code should have been well structured and readable to begin with, but even the best developers have their good days and bad days, and often good developers have to tolerate the product of mediocre developers. I just don't see the need to tolerate it more than once.
Slashdot Mirror
"Fool me once, shame on you. Fool me twice, shame on me."
Written by John Ousterhout, the guy who developed Tcl/Tk. So I guess he has a bit of an axe to grind in promotion of events versus threads, but he makes some good points.
Someone please mod this "informative."
Threading provides an excellent opportunity for programmers to shoot themselves in the foot. If requirements can be satisfied using events, use them!
Could be because it's an extreme position? Or because knowledgeable system designers don't see that it solves anything? Just a thought.
For example, critical US Department of Defense secrets have ended up in the hands of adversaries, despite extreme efforts to safeguard these secrets. And the same is equally true, of course, for other nations. Thus there is demonstrably not a condition of absolute security, even at the most secure end of the scale.
But we're talking here not about military security and state espionage but about web browser vulnerabilities. For the most part the browsers in question are running on consumer grade systems which are not professionally managed. The perception of value and risk for a consumer product is at a much lower point on the scale relative to a hardened military installation. The same security principles apply, of course, but the tradeoffs are characteristically different.
I agree with your comment that it does not help to obscure the security tradeoffs on consumer systems. That encourages misperception. But it also doesn't help to talk about security as if it were all or nothing. That encourages another misperception.
It's not the case that all information is fully exposed if it's not fully secure. The middle ground is quite acceptable for many purposes. For example, safes are rated in terms of how much time is required to break into them, not whether they are or are not absolutely secure. A safe with a higher rating is bigger, heavier, and more expensive. So there is not an absolute solution but instead a range of solutions to suit different needs.
This works because the rating of safes is easy to understand. What we need in the computer industry is a similar objective rating for system security. And as Bruce Schneier points out, this is likely to come about not because of consumer demand directly, but as a result of pressure by the insurance industry.
False certificate revocation is an obvious point of attack on certificate infrastructure, and has been ever since CRLs were proposed. Loss of encryption key is a new risk? Yes, to researchers who have been asleep since, oh, 1466 when Leon Battista Alberti developed key crypto.
It's not that we shouldn't pay attention to these risks and incorporate them into our security metrics. Of course we should. But it's not news. I hate it when people grab for attention but then have nothing to contribute.
Yep. Anything short of nicely modulated antigravity is a non-starter for me. Let's see, why is that? Because even the kinetic energy of my own body falling from my own height can be enough to cause permanent injury? Or because superheated gases sufficient for lift are being generated immediately next to me?
Each of these roles is a career path in itself. Well, not tech support, but seven years in any one of the others takes the average CS grad to somewhere around an intermediate level of professional competence.
We've all had our encounters with incompetent IT managers, so I won't even go into the variety of forms that incompetence can take. But it is a challenging position, and in my view, absolutely requires senior technical ability. You cannot lead unless you know where you're going, and few technical people will support your initiative unless they agree with your reasoning.
It's great to acquire broad work experience in each of these areas. I've made a point of doing that myself, and I have no regrets. But it takes considerably more than dabbling for a couple of years at one of these areas before you can begin to talk about it intelligently, let alone lead others.
If there's one thing that characterizes junior technical people, it's that they think they know what they're doing when in fact they have barely a clue. Those kind make the worst managers. I've managed large staffs myself, and found through experience that it's invariably the most junior, least expert, people that give the most grief.
In order to build secure systems for our own reasonable purposes. It would be really nice if I could have a system which is not hackable except by me, but is truly hackable by me. And you could have yours.
But we know this doesn't happen. It's easy to conceive of systems in which a decrease in privacy leads to a corresponding decrease in security. For example, take an existing bank system and decrease the privacy of administrative passwords. Does this change make the bank system more or less secure? Conversely, take an anonymous ballot system and decrease its security protections against exposing the choices registered by each voter. Does this increase privacy or decrease it?
If we look at fundamentals, systems are secure when the conditions of identity, ownership, and trust are defined and enforced at each point in the system. Just that. Properly specified and implemented systems will provide appropriate access to appropriate parties (the system meets functional specs), and not otherwise (the system meets security specs). People like Ed Giorgio who don't get this are simply not qualified to talk about security.
To be precise, Java is a language specification. It's typically implemented as a virtual machine, but there's no fundamental requirement to do so.
Let's consider Lisp instead for a moment, since Gosling, Steele, et al used it as a conceptual basis for Java. It has an extremely rich history. Lisp predates Java in being implemented as a virtual machine. The dialect was Interlisp.
The Xerox model 11xx AI workstations used Interlisp as the system language. Lisp device drivers and network stacks were also implemented for the MIT Lisp Machine and its commercial derivatives based on variations of MIT Lisp and later Common Lisp. Note particularly that Lisp is running in silicon on these systems. There is no virtual machine.
These systems were not a great commercial success, because they entered the market as very exotic and very expensive research workstations at exactly the same time as commodity microprocessors were experiencing exponential growth. The various Lisp systems just couldn't keep up with commodity growth effects on price/performance. There was nothing functionally lacking with them, and I can say from firsthand experience that it was a pleasure to work on their operating systems.
I'm not convinced that I would enjoy working with an operating system written entirely in Java, but there's no reason such a thing couldn't exist. If a JVM can perform acceptably on top of a foreign processor architecture, it should only perform better without the virtual machine overhead.
The reason that individuals can offer credentialed expertise in wine as a restaurant service is because they can base it on a body of knowledge which goes back some 9000 years. Yes, wines are complex, tasting is subjective. To that extent, the analogy holds. But unlike the cell phone market, the characteristics of wine, and the particular requirements of fine wine, are stable and well understood. Therefore, both the somellier and the patron gain an enduring advantage through cultivating their wine expertise over time, and the dialogue between them can be efficient and meaningful.
Cell phone capabilities and services, on the other hand, are so extremely volatile that there can be no ground for consensus. It's still possible to go through the exercise of gathering requirements and outlining solutions, an activity which has already been given the name System Analysis. Let's call it what it is, because that tells us what we can reasonably expect from it.
The same security concerns that apply to network management interfaces apply to OOB management interfaces.
These are excellent points. Given the number of responses, I don't know why you haven't been modded up already.
I've worked with all sorts of organizations who make access to their systems extra slow and tedious by requiring dialin. This is always explained as being for "security" reasons.
Um, no. All they're doing is substituting one physical layer of the network stack for another, neither of which have meaningfully secure access controls. Security, to the degree that it's addressed at all, would have to be done further up the stack. And that being the case, why again do we have to dial in?
I pointed out that this is what gave rise to digital certificates, in which your public key is signed by a certificate authority. Anyone encountering the certificate can immediately verify that it has not been tampered with. I also described how to securely transmit a bare public key to that authority so that it cannot be counterfeited at that point either.
You're absolutely right to observe that, despite all these means of verification, there has to be some ultimate thing you trust. You need something to bootstrap the rest of the process. That would be a root certificate in the case of a hierarchical public key infrastructure, though there are other approaches, such as Zimmerman's PGP, which attempt to distribute trust from the bottom up, and others based on trust metrics. In other words, some consideration also should be given to how distant that source of authority is from the particular object of interest to you.
So, while I agree that we each individually have to start with some source of information that we trust, among the various mechanisms which depend on this source, each has strengths and weaknesses. If you go for the single authority approach, say George Bush just for the sake of argument, then (a) if George Bush is compromised then so are you, and (b) George Bush is going to be overwhelmed with requests out of band for root certificates. If, on the other hand, you go for a "web of trust" approach, then (a) your verification effort increases with the number of peers, and (b) you have introduced multiple points of compromise.
What happens in practice is that we make some concessions for the sake of usability. For example, web browsers come with a set of root certificates preinstalled. Who decides this set? Not you, certainly. You can strip them all out, and then install just the root certs that you have received through some, presumed secure, channel. Yes, you could set up a one-time pad with some trusted individual in order to create this channel, but as you point out, you would have to trust that individual completely, and they would have had to trust someone else in order to get their copy of the root cert, and so on. Every such step is an injection point and a dilution of trust, and worse still, you can't determine how many steps there were between the root authority and you.
So your approach ends up delivering an informal, unknown, unquantified, unverifiable effect of trust dilution. The only way around this is to go straight to the certificate authority with your one-time pad, and for reasons of scale that ain't gonna happen. What happens instead, deplorably imperfect though it may be, is that in effect we trust the web browser. If I wanted to distribute a counterfeit root cert, I'd start by installing it into a browser distribution and set it loose on the net.
But this leads to an important observation. Besides trusting some certificate at some point, we inevitably also have to trust the software which puts that certificate to use. There is no way around it. And, if that degree of trust is equivalent, we might as well combine the two together and decide whether or not to trust the whole package. In that case, you might not be satisfied with exchanging a one-time pad with your completely trusted peer. You might want to exchange source code for a very basic web browser or other transfer agent which contains a hardcoded root cert, then use it to bootstrap a signed browser.
But if you're a purist, that's not enough either. Your underlying system might be compromised, such that whatever you try to install, it substitutes its own backdoor. Given industry p
You've been modded "funny" for this. But the point you've made is absolutely valid.
It's not as if the ISP necessarily has any malicious intent. Though, come to think of it, to judge by the quality of customer service of some of them, we might want to leave that as an open question.
But you know what? The only thing that you have to keep private is your private key. That's why you must always generate the key pair locally. Public keys are supposed to be distributed widely. There's no harm in anyone in the middle seeing it in transit. They're not learning anything that you want to be kept secret.
A counterfeit public key will not correspond with your private key, but it could cause grief for any party which encrypts sensitive information with it. This and some other related scenarios are addressed by wrapping the public key in a certificate signed by a trusted authority.
Now, what about the case where you have generated the key pair and want to get it made into a certificate? In order to do this, you have to transmit the bare public key to the certificate authority. That's okay too. You encrypt it with the public key of the authority, contained in a root certificate which by definition is trusted, meaning that you have it already.
To give a very abbreviated answer, the network effect for this has not yet taken off. There has been no technical barrier to widespread encryption for over a decade, but there are two social barriers which remain to be overcome:
-
Education
-
Sequence
So, there's an elaborate sequence of events, each with a big activation threshold, that have to be crossed in order to trigger the network effect. Until you see a lot of cryptographically signed emails, for example, you can safely assume that there are not yet a lot of encrypted emails in circulation. And the same will be comparably true of any other encrypted protocol.In order for you to use crypto, you have to know how it works. Most other technologies are not like this, in that they can just kind of operate in the background. But cryptographic communications operate between defined endpoints, and you are one of those endpoints. Understanding takes considerable effort. At minimum, people need to understand how asymmetric crypto works in both message signing and message encryption, and they also must develop some insight into what motivates key distribution, because otherwise they won't be able to make sense of the public key infrastructure in which they must participate. I think it's important enough that ultimately it will be taught as part of the standard school curriculum. But we're a long way from that at the moment.
Message encryption is the last in a fairly involved series of steps. This delays the network effect. Participants first have to generate their cryptographic keys and then have them signed by a trusted third party. Then they have to begin signing their own messages with them. As these messages go out, a side effect is to distribute the public keys which are in turn necessary for message encryption. Finally, participants can begin to encrypt messages.
This explains why adoption has proven to be very slow. There have been many early adopters, of course, but so far evidently not enough to inspire the public at large.
The good news is that we've seen this kind of phenomenon lots of times before. The Internet itself was widely ignored for a long time, despite being completely satisfactory from a technical perspective. Something eventually kicks it into public awareness, and then, if those of us who engineer these things have done our job right, it takes off without a backwards glance.
Think about it. As soon as you start to extend the linking taboo to the general case, you find yourself on a very slippery slope. It's crazy to suggest that linking to a library leads somehow to a derived work. No, folks, that would be the basis of a little thing we call modularity. It works by means of defined interfaces, in this case through function declarations.
Not function definitions, note. If your program were to contain the body of a function licensed under the GPL, then it would be considered a derived work, since copying a body of code is the essence of incorporation. The GPL forbids incorporation. Fine, excellent. But it nowhere forbids use of an interface to call out to licensed code.
Perhaps I should have said "not authenticated", though to me these are computationally equivalent. That is, there is no need for a system to distinguish between malicious data and just plain random data. It should reject both.
It's hard to see how anyone with a brain could have not considered the implication of a stray signal setting off the switch actuator, potentially causing loss of life.
I own an area of land which I've thought, somewhat idly, would suit an aerial tramway for moving building materials onto the site. The first thing that crossed my mind was not was how to engineer the rigging. That's textbook stuff. No, my first concern was whether it would be possible to build a remote control that would fail safe.
I don't know what possible gain for the OLPC project could arise out of this sort of complicity, but something, surely. Why put your head in a noose, otherwise? But to my way of thinking, it just taints an otherwise inspired idea.
But this line of reasoning makes no sense. The Internet at large is an insecure network. Whether a host connects with it directly, or over an open wireless segment, does not affect the basic property that traffic to and from the host is exposed.
The only way for two endpoints to satisfy themselves of secure communications over an insecure network is for those endpoints to establish an authenticated and encrypted session between them. For purposes of securing the network, it's not useful to secure just one segment of the network, such as you propose doing between your server and laptop, and pretend that the rest of the network doesn't matter. It does. Conversely, if you can establish endpoint security between some remote host on the network and your laptop, there is no additional value in securing any segment in between.
So Schneier is correct in the sense that having wireless open or closed doesn't change the fundamental network security equation. On the other hand, he is deliberately overlooking the security principle know as defense in depth. A properly secured host doesn't need a firewall, but firewalls are useful as an independent line of defense in case the host is not as well secured as we believe. Schneier knows this principle perfectly well, so I assume that he's being controversial simply in order to stir up debate and get people thinking.
It's not that he wants people to think that open wireless is secure, quite the converse. It's patently insecure, but then so is the Internet in general. So design your endpoing security accordigly.
Whereas, you're posting as an Anonymous Coward with no credentials at all. That's fine, it just means that we're left to judge you on the merits of your argument. And so far, you show only a knack for developing arguments which logically self-invalidate. That's not even passable as sophistry. You understand that, don't you?
A choice to drink the Kool-Aid is not much of a choice. Especially if the drinker isn't in the position to understand that it's been poisoned.
Close that platform, and suddenly it makes no sense at all. It's no longer an extensible means of cultural and technological expression but just another consumer product, good for nothing more than keeping the Third World in its place, right at the bottom.
Thanks, Microsoft, for staying in character.
Yep. What the parent pretends not to get is that every software developer is posessed of finite cognitive bandwidth. You can expend that bandwidth on the mental bookkeeping necessary to make sense of trashy code, or you can put resources into cleaning up the code so that it is no longer a needless cognitive drain.
Furthermore, once cleaned up, the code stays cleaned up. The next developer to come along will not have to waste time making sense of bad code. Considering the stats on how much developer time goes into reading code written by others, refactoring and other forms of code cleanup is time well spent.
Of course, the code should have been well structured and readable to begin with, but even the best developers have their good days and bad days, and often good developers have to tolerate the product of mediocre developers. I just don't see the need to tolerate it more than once.