I submit that people who are only looking for security flaws don't have a motivation to develop a deep understanding of the software. People who are out to modify the software do.
This is a truly insightful comment. Software security isn't just a matter of verifying low-level code correctness. Though that's a step which can be usefully automated, what could possibly motivate the deeper analysis of what the software is supposed to do? To even identify the edge cases which exist at higher levels of abstraction requires an intimate knowledge of the software as implemented, its architectural intent, and the requirements which drove that solution.
Who is there in a position to develop that kind of knowledge? Typically, someone who comes along with a reason to adapt the software to new requirements, or whose taste for whatever reason runs to a different solution architecture, or who thinks that the design needs refactoring.
Of these three, proprietary software tends only to put resources into the first, whereas we know that merely adding new features typically results in reduced security when addressed in isolation. It takes a certain kind of altruism to care about the other two.
Software development is intrinsically hard. More secure development is harder. In terms of human resources, it makes sense that deep security improvements are going to come from people who are strongly motivated to know the software.
Security isn't a treatment that can be performed after the fact. It has to be an intrinsic part of the design process.
So I agree, though I'll word the claim even more strongly. People who are only looking for security flaws by definition lack the fundamental insight that security is mostly about design. Implementation is just the tip of the iceberg.
Ah yes, the "build or buy" tradeoff, and the related constellation of questions around how to approach modular system design.
I think that you and I would agree, from professional experience, that we can usually arrive at a pretty good solution for a typical, particular, set of organizational requirements. Or, if it can't be done with available resources, we can pretty confidently know when to say so.
It doesn't follow that this approach can, even in principle, be extended to solve the general problem of automating organizational processes. Even the question of what is the right degree of granularity to use when decomposing a given process into functional modules has to be answered by saying, "It depends."
Back in the eighties, I worked on a project in Sweden which attempted, and failed, to do this. Office automation suites were coming into popular use at the time, but we felt that they lacked essential modularity. For one thing, their granularity (a word processor engine, a spreadsheet engine, a database engine) was far too coarse to represent distinct business processes. For another, they weren't usefully composable. We thought that not only would a word processor, for example, be much more adaptable to particular needs if it could be composed out of reusable text editing and layout elements and so on, but that those elements would find application in many other sorts of workflow as well.
What happened? Well, I think our intuition was right, but our timing was not. Just identifying the necessary modules and their interfaces would have been a major design undertaking, and we had many implementation challenges as well. This was an era before web forms, before X widgets, before development and prototyping tools, and at the very dawn of OOP. Our resources were insufficient, and we ran out of gas.
But the experience was useful in this sense: it provided a concrete example of just how hard it is to design a modular solution able to meet office automation requirements in the general case, even if we constrain its domain to that of existing office automation products. In other words, even a pure refactoring exercise is hard if it has to satisfy the general case. That should give us some respect for the extent of the software engineering challenge in general.
And I think most people would agree that what really goes on in an organization is incomparably more complex than the elements that can be directly represented by text documents, spreadsheets, Gantt charts, and so on. We seem to be having more luck with delivering web services to perform this sort of integration, which is interesting given that the implementation granularity is actually moving down the stack toward more primitive abstractions. We're as far as ever from having a general abstract language in which to express business logic.
You can see where I'm going with this. As technology advances, we can add new features, we can standardize and commodify general components such as the user interface all we want, but what goes on behind the scenes is still highly customized, still constantly evolving, still apparently as irreducable as ever. And that's okay, because we know how to work with that.
To say that "IT" is merely the implementation of a technology in a company is not to give the IT department a fair shake.
Well said! Indeed, Nicholas Carr has run into this conspicuous difficulty on past occasions as well, but prefers to ignore it in the hope that it will go away.
But one must be very judicious about where to apply reductionistic analysis, and Carr is not judicious. IT is not some finite, static thing. If it were, then yes, likely it could be commodified, outsourced, whatever. But what exactly is IT? It's an unbounded stack of capabilities based on the computational properties of information. That's about all we can confidently say about the nature of IT.
As a computer scientist, I don't think it's meaningful to constrain the definition beyond that. Even talking about capabilities as a stack is a bit of poetic license on my part, since a stack is only one among many possible ways to structure information. I use it to convey the sense that once you've figured out how to deliver one layer of abstraction, that will in turn enable a whole new language of possibility that did not previously exist. It's intrinsically unbounded. Try outsourcing that!
Of course, way behind that leading edge is the ordinary nontrivial work of fitting the flow of commonplace information elements to the evolving structure of the organization. Perhaps this, at least, could be ousourced. But inasmuch as each organization is unique, the flow and interplay of information will be unique also. The understanding of what this means, in complete implementable detail, is not trivial to outsource. I think that's what you're getting at when you point out how the IT Department must interact with organizational culture.
In general, all of IT that can usefully be outsourced is the trailing edge, that is, those information elements which have become so commonplace and so well understood that they can be standardized and commodified. Even then, the primary value of those elements is not intrinsic, as Carr would have it, but exists to enable the next layer. For example, an organization doesn't deploy a public key infrastructure merely for the sake of cuteness. It would have to be applied in some organizationally useful way, say to establish the identity of communicating endpoints for some kind of secure transaction. And what transactions are those? The answer depends uniquely on the organization.
I don't know why either. Well, I do know why, and it comes down to a remarkably cavalier design decision by one particular software vendor.
Default Allow is fundamentally not a basis from which a system can be secured. It forces every system user to maintain perfect knowledge of a changing universe. Default Allow plus virus detection is, in the limit, equally doomed. Fred Cohen pointed out over two decades ago that virus detection is equivalent to solving the Halting Problem. Either way, it signs us up for an infinite amount of work.
Default Deny, on the other hand, certainly requires us to do some work, to consciously qualify those 30 pieces of Goodness. That requires explicit effort, but it's a finite amount of work. So why, in the face of such clear advantages, do so many people want to avoid this policy? I can only think that they resist the idea of responsibility. And that's a matter of perception, something that I hope people will eventually come to rethink.
Even better, the CBC article concludes with a reference to the Telecommunications Act, which states that "a Canadian carrier shall not control the content or influence the meaning or purpose of telecommunications carried by it for the public."
Rogers has a long history of playing as dirty as it can get away with. If the old pattern repeats as before, Canadian regulators will respond and Rogers will be forced to back down, leaving everyone -- regulators, investors, competitors, consumers -- slightly more pissed off with it than before.
The Netherlands has a strong tradition of liberal democracy based on a sense of people taking care of each other. And it has given the world some great thinkers in Computer Science as well.
Intitiatives like this one are likely to succeed here because they will be widely seen to make good sense.
There is nothing to prevent Microsoft from being part of the solution. Or it can be part of the precipitate.
It's an open question at the moment whether the movement of bits between people in chronic poverty has sufficient power to transform the conditions leading to that poverty. But inasmuch as other attempted solutions over several decades haven't really done much to change those conditions, perhaps it would be better not to be too cynical about this one. We've seen how Japan, after the war, or China and India more recently, have made quantum leaps in their economic stature by virtue of starting with a clean slate. It may well turn out that what's been holding back the Third World is nothing more than the means to organize itself and thereby release its creative potential.
Dvorak, never a man to pursue great subtlety of thought, seems to have reached only for the obvious. His point is valid, but hardly remarkable. I like yours better.
Video time code, and devices which synchronize to it, is commonplace in the broadcast industry. The time code expresses video frame rate, which is 1/60 second when interlaced. It's a useful standard in many other settings, as this precision is a good enough compromise for synchronizing many devices, without having to worry too much about time of flight. The gear is commonly available off the shelf, you can get chipsets that do it, et cetera.
The existing timecode already accounts for leap seconds, I believe, which are applied as the day rolls over. Usually nobody is looking, and those in the know, who are looking, will be reassured rather than bothered to see the seconds counter stall briefly.
It would be a bit nasty to retool everything for leap frames. When the timecode standard was developed, it would not have been computationally prudent, and to my mind it's still sort of like, who cares? As long as participating devices are in agreement about the time quantum, and the math, it doesn't matter to them. So then the question is, what's attractive to us? I personally find that a little shimmer in time at midnight is sort of charmingly magical. If it happened every 1024 seconds or something, I'd find it irritating.
Oh, but I'm forgetting the point I wanted to make. It's that, from a video broadcasting perspective, any leap adjustment smaller than frame rate is problematic. A video frame is indivisible. So, leap microseconds? Please, no.
The solution to the MITM scenario in present systems is as follows.
In X.509 certificates, the public key is signed by a mutually trusted third party. In PGP, the same thing is achieved at a peer level by ring of trust.
Earlier proposals call for a commonly trusted keystore, but that was found not to scale well. Really you need the cert to carry its own means of validation, hence the need for thir party signing.
Well, that's why there is a higher-order authentication framework within both PGP and X.509. This is necessary whenever two parties not previously known to each other need to establish identity with each other.
X.509 certificates are signed by a Certificate Authority whose identity is presumed trustworthy. PGP keys operate on a ring of trust where peers vouch for each other.
In both schemes there is necessarily a dilution of trust as you move further away from the point of contact. And there are not good metrics for this dilution. But in terms of the obvious MITM the problem has been solved for a long time now. We're looking at more nuanced issues now.
I've seen several comments already to the effect that we should know better than to trust PGP or other forms of asymmetric encryption.
These comments are misguided.
The crypto is fine. It's just been applied in an obviously flawed manner. Of course if some third party obtains your private key, your should assume that your communications are no longer secure. What part of that is hard to understand?
There way asymmetric crypto is supposed to work, you generate the key pair yourself. Then you give out the public key. You never ever give out the private key.
As an exercise, think about the following scenario. You go to a website which purports to offer some kind of secure service based on asymmetric crypto, using for example PGP keys or X.509 certificates. The site asks you to supply a bunch of identity information. It then generates a key pair for you.
What part of this scenario should you trust? The answer: no part! It's not the function of another party to generate your key pair for you. You must do this yourself. You must closely guard the private key, store it securely, never give it out, and avoid transmitting it in cleartext. Got that? Then your problems are over.
I'm getting a distinct feeling of déjà vu about this. Anyone remember the Clipper Chip? Key escrow? Same basic idea, and that proposal came out of the NSA as well. Only then the backdoor was explicit.
The crypto community spoke out strongly against it, and the proposal, despite having a great deal of political muscle behind it, did not fly very far. Another sensible reason for its failure to gain acceptance was that it would have had no chance of success on the international market. Even if domestic use could have been forced through legislation, let's say, no other nation with a clue would pick it up.
Randomness is absolutely at the heart of cryptography. So yes, to answer your question, it does matter.
If I can predict the value of a symmetric key, or the value whose two factors constitute an asymmetric key pair, I have effectively broken the encryption. Even supposing that I can't do this deterministically, but merely somewhat better than random, I'm still that much further ahead.
Sorry for the delay in replying. I was referring to a CBC radio interview with a retired police officer who was arguing in favor of something similar to harm reduction. It ran, I believe, on Friday or Saturday afternoon last week.
His main point was that the status quo enforcement regime was primarily serving to generate enormous wealth for criminals. A secondary point was that harsher enforcement is not a way to guarantee a lower rate of drug use, and this is where he referred to the amount of drug consumption per capita in the States compared to Canada.
I don't recall him citing any particular study for this, which is understandable in the context of a radio interview. But it did sound like he was referring to a body of material, not just some casual conjecture on his part. If I can find anything further about this, I'll pass it on.
Defense in depth is an important security principle, among several others which have apparently not received any treatment in the book reviewed here.
Considering that the book is cxclusively concerned with configuring proprietary network gear, that's perhaps understandable. But when the same book presumes, by its title, to offer a general treatment of end-to-end security will have badly misled its readers. This is not end-to-end security, but instead the much smaller subset which concerns how to manage network traffic.
If we genuinely want to talk about end-to-end security, we'll have to look closely at the endpoints. We have to look at them in terms of their own architectural security, as well as how they function as communicating agents. And where communication is concerned, all the stuff in the middle, generally speaking, is not trustworthy.
That's a more principled approach to what "defense in depth" means in the context of these endpoints. Sure there might be a few firewalls or encrypted tunnels along the way, but the endpoints have no means of assuring that this infrastructure is in fact secure. Should those layers fail to operate as expected, the security of the communication falls to other layers. Ultimately, the responsibility falls to the endpoints themselves.
Dealing with security in several fragmented pieces is not so great. That's because security is an emergent property of the entire system, not something which can be directly composed from elements of the system. A text which provides a treatment of security princples comprehensively would be most welcome. Let's save the "end-to-end" terminology for when we're really looking at end-to-end architectures.
You raise an important point. Canadian law, as well as Canadian expectations of civil conduct and civil rights which underly our laws, are somewhat different than American. In particular, they're often more elastic, more open to interpretation of the spirit of legislation rather than blunt enforcement. Historically, this has applied to copyright, recreational drug use, sexual conduct, and regard for privacy, among many other subjects. Not that it's necessarily better; we just approach things differently.
It seems that the RCMP has looked at the media levy, which, as you mention, exists precisely as a concession to the industry because copying of music for personal use is permitted in Canada. And it has looked at a number of serious copyright issues that do require enforcement, and it has looked at its own finite enforcement resources.
And the RCMP has decided that it makes no sense to target personal music downloads for enforcement. I recall a few years ago that a similar decision was made by the provincial courts here in BC regarding minor drug posession. Not deemed a big risk to society, not enough resources, better things to do with them.
It makes sense to me too. Canada, you'll notice, is not exactly falling apart in comparison to the United States. We actually have a lower rate of recreational drug use than the States, according to a report aired on CBC Radio yesterday, despite a much lower rate of enforcement and sentencing. And our dollar isn't doing too bad lately, either.
The debate about the relative security merits of open-source as opposed to proprietary software development has been a very long-running one
Indeed. The principle of open security was first proposed by Auguste Kerckhoffs in 1883.
Any time security depends on the secrecy of some mechanism, that security is pepetually at risk. All these millions of instances of the same vulnerable mechanism, no way to tell in general whether their security has been broken, and -- as you point out -- a certainty that the vulnerable secret cannot be contained.
In what way exactly does this remain a matter of debate?
Based on the evidence you've supplied, she's not dumb, just principled. It's entirely possible that this organization has a security policy which requires staff to act this way. That would explain why the chairman found that he couldn't just tell her to do it differently.
With that in mind, consider the possibility that you often misplace your security card as your failing. Instead of blaming someone else because they won't fix your life for you, take a little responsibility.
I know, it's a bit of a novel concept at first, but just try it on and see if life gets any better. Likely, it will, because this is one of those aspects of life over which you are actually in control. Or could be.
You cannot have a trademark just by virtue of owning a domain name.
And even supposing you could, that logic would cut both ways. It could be just as compellingly argued that "simpledog.com" is infringing on "thesimpledog.com", rather than the converse.
All words are image associations in the human brain
Where on earth did you encounter this bit of nonsense? It's commonly held that words are constructed by metaphor but the root of the metaphor need only be experiential, not necessarily visual. If it were as you claim, then blind people would be unable to construct sentences.
it isn't any hard to tell someone, hit Alt, Type H, Type A
It's not hard, but it's semantically impoverished, and it depends on a fixed keybinding scheme.
Sorry, I couldn't follow the reasoning in your last paragraph.
Not to mention how anyone is supposed to communicate such use to someone else.
It's bad enough now, having to write instructions like "First select Edit -> Preferences -> Security -> Certificates -> Manage Certificates. In the resulting Certificate Manager popup, select Authorities. Now click Import..." and so on.
Anything that forces a graphical representation also forces us to converse in terms of graphical representations. And guess what, humans don't do that very well.
It was Fred Cohen who first coined the term "virus" in 1984 and showed that determining whether or not a given program is a virus is undecidable, that is, equivalent to the Halting Problem.
Cohen saw that one implication of this result is that virus detection is an endless arms race. Viruses are free to mutate into an infinite variety of functionally equivalent forms, whereas the process of establishing their equivalence is undecidable.
We've had this result in front of us for 20 years now. It has always seemed bizarre to me that so much of our focus should therefore be on this futile exercise of closing the barn door after the horse has gone. Surely it makes more sense to design systems based on accepted security principles which reduce the opportunity for infection and contain its effects.
Slashdot Mirror
This is a truly insightful comment. Software security isn't just a matter of verifying low-level code correctness. Though that's a step which can be usefully automated, what could possibly motivate the deeper analysis of what the software is supposed to do? To even identify the edge cases which exist at higher levels of abstraction requires an intimate knowledge of the software as implemented, its architectural intent, and the requirements which drove that solution.
Who is there in a position to develop that kind of knowledge? Typically, someone who comes along with a reason to adapt the software to new requirements, or whose taste for whatever reason runs to a different solution architecture, or who thinks that the design needs refactoring.
Of these three, proprietary software tends only to put resources into the first, whereas we know that merely adding new features typically results in reduced security when addressed in isolation. It takes a certain kind of altruism to care about the other two.
Software development is intrinsically hard. More secure development is harder. In terms of human resources, it makes sense that deep security improvements are going to come from people who are strongly motivated to know the software.
Security isn't a treatment that can be performed after the fact. It has to be an intrinsic part of the design process. So I agree, though I'll word the claim even more strongly. People who are only looking for security flaws by definition lack the fundamental insight that security is mostly about design. Implementation is just the tip of the iceberg.
I think that you and I would agree, from professional experience, that we can usually arrive at a pretty good solution for a typical, particular, set of organizational requirements. Or, if it can't be done with available resources, we can pretty confidently know when to say so.
It doesn't follow that this approach can, even in principle, be extended to solve the general problem of automating organizational processes. Even the question of what is the right degree of granularity to use when decomposing a given process into functional modules has to be answered by saying, "It depends."
Back in the eighties, I worked on a project in Sweden which attempted, and failed, to do this. Office automation suites were coming into popular use at the time, but we felt that they lacked essential modularity. For one thing, their granularity (a word processor engine, a spreadsheet engine, a database engine) was far too coarse to represent distinct business processes. For another, they weren't usefully composable. We thought that not only would a word processor, for example, be much more adaptable to particular needs if it could be composed out of reusable text editing and layout elements and so on, but that those elements would find application in many other sorts of workflow as well.
What happened? Well, I think our intuition was right, but our timing was not. Just identifying the necessary modules and their interfaces would have been a major design undertaking, and we had many implementation challenges as well. This was an era before web forms, before X widgets, before development and prototyping tools, and at the very dawn of OOP. Our resources were insufficient, and we ran out of gas.
But the experience was useful in this sense: it provided a concrete example of just how hard it is to design a modular solution able to meet office automation requirements in the general case, even if we constrain its domain to that of existing office automation products. In other words, even a pure refactoring exercise is hard if it has to satisfy the general case. That should give us some respect for the extent of the software engineering challenge in general.
And I think most people would agree that what really goes on in an organization is incomparably more complex than the elements that can be directly represented by text documents, spreadsheets, Gantt charts, and so on. We seem to be having more luck with delivering web services to perform this sort of integration, which is interesting given that the implementation granularity is actually moving down the stack toward more primitive abstractions. We're as far as ever from having a general abstract language in which to express business logic.
You can see where I'm going with this. As technology advances, we can add new features, we can standardize and commodify general components such as the user interface all we want, but what goes on behind the scenes is still highly customized, still constantly evolving, still apparently as irreducable as ever. And that's okay, because we know how to work with that.
Well said! Indeed, Nicholas Carr has run into this conspicuous difficulty on past occasions as well, but prefers to ignore it in the hope that it will go away.
But one must be very judicious about where to apply reductionistic analysis, and Carr is not judicious. IT is not some finite, static thing. If it were, then yes, likely it could be commodified, outsourced, whatever. But what exactly is IT? It's an unbounded stack of capabilities based on the computational properties of information. That's about all we can confidently say about the nature of IT.
As a computer scientist, I don't think it's meaningful to constrain the definition beyond that. Even talking about capabilities as a stack is a bit of poetic license on my part, since a stack is only one among many possible ways to structure information. I use it to convey the sense that once you've figured out how to deliver one layer of abstraction, that will in turn enable a whole new language of possibility that did not previously exist. It's intrinsically unbounded. Try outsourcing that!
Of course, way behind that leading edge is the ordinary nontrivial work of fitting the flow of commonplace information elements to the evolving structure of the organization. Perhaps this, at least, could be ousourced. But inasmuch as each organization is unique, the flow and interplay of information will be unique also. The understanding of what this means, in complete implementable detail, is not trivial to outsource. I think that's what you're getting at when you point out how the IT Department must interact with organizational culture.
In general, all of IT that can usefully be outsourced is the trailing edge, that is, those information elements which have become so commonplace and so well understood that they can be standardized and commodified. Even then, the primary value of those elements is not intrinsic, as Carr would have it, but exists to enable the next layer. For example, an organization doesn't deploy a public key infrastructure merely for the sake of cuteness. It would have to be applied in some organizationally useful way, say to establish the identity of communicating endpoints for some kind of secure transaction. And what transactions are those? The answer depends uniquely on the organization.
Default Allow is fundamentally not a basis from which a system can be secured. It forces every system user to maintain perfect knowledge of a changing universe. Default Allow plus virus detection is, in the limit, equally doomed. Fred Cohen pointed out over two decades ago that virus detection is equivalent to solving the Halting Problem. Either way, it signs us up for an infinite amount of work.
Default Deny, on the other hand, certainly requires us to do some work, to consciously qualify those 30 pieces of Goodness. That requires explicit effort, but it's a finite amount of work. So why, in the face of such clear advantages, do so many people want to avoid this policy? I can only think that they resist the idea of responsibility. And that's a matter of perception, something that I hope people will eventually come to rethink.
Even better, the CBC article concludes with a reference to the Telecommunications Act, which states that "a Canadian carrier shall not control the content or influence the meaning or purpose of telecommunications carried by it for the public."
Rogers has a long history of playing as dirty as it can get away with. If the old pattern repeats as before, Canadian regulators will respond and Rogers will be forced to back down, leaving everyone -- regulators, investors, competitors, consumers -- slightly more pissed off with it than before.
Intitiatives like this one are likely to succeed here because they will be widely seen to make good sense.
There is nothing to prevent Microsoft from being part of the solution. Or it can be part of the precipitate.
It's an open question at the moment whether the movement of bits between people in chronic poverty has sufficient power to transform the conditions leading to that poverty. But inasmuch as other attempted solutions over several decades haven't really done much to change those conditions, perhaps it would be better not to be too cynical about this one. We've seen how Japan, after the war, or China and India more recently, have made quantum leaps in their economic stature by virtue of starting with a clean slate. It may well turn out that what's been holding back the Third World is nothing more than the means to organize itself and thereby release its creative potential.
Dvorak, never a man to pursue great subtlety of thought, seems to have reached only for the obvious. His point is valid, but hardly remarkable. I like yours better.
The existing timecode already accounts for leap seconds, I believe, which are applied as the day rolls over. Usually nobody is looking, and those in the know, who are looking, will be reassured rather than bothered to see the seconds counter stall briefly.
It would be a bit nasty to retool everything for leap frames. When the timecode standard was developed, it would not have been computationally prudent, and to my mind it's still sort of like, who cares? As long as participating devices are in agreement about the time quantum, and the math, it doesn't matter to them. So then the question is, what's attractive to us? I personally find that a little shimmer in time at midnight is sort of charmingly magical. If it happened every 1024 seconds or something, I'd find it irritating.
Oh, but I'm forgetting the point I wanted to make. It's that, from a video broadcasting perspective, any leap adjustment smaller than frame rate is problematic. A video frame is indivisible. So, leap microseconds? Please, no.
In X.509 certificates, the public key is signed by a mutually trusted third party. In PGP, the same thing is achieved at a peer level by ring of trust.
Earlier proposals call for a commonly trusted keystore, but that was found not to scale well. Really you need the cert to carry its own means of validation, hence the need for thir party signing.
X.509 certificates are signed by a Certificate Authority whose identity is presumed trustworthy. PGP keys operate on a ring of trust where peers vouch for each other.
In both schemes there is necessarily a dilution of trust as you move further away from the point of contact. And there are not good metrics for this dilution. But in terms of the obvious MITM the problem has been solved for a long time now. We're looking at more nuanced issues now.
These comments are misguided.
The crypto is fine. It's just been applied in an obviously flawed manner. Of course if some third party obtains your private key, your should assume that your communications are no longer secure. What part of that is hard to understand?
There way asymmetric crypto is supposed to work, you generate the key pair yourself. Then you give out the public key. You never ever give out the private key.
As an exercise, think about the following scenario. You go to a website which purports to offer some kind of secure service based on asymmetric crypto, using for example PGP keys or X.509 certificates. The site asks you to supply a bunch of identity information. It then generates a key pair for you.
What part of this scenario should you trust? The answer: no part! It's not the function of another party to generate your key pair for you. You must do this yourself. You must closely guard the private key, store it securely, never give it out, and avoid transmitting it in cleartext. Got that? Then your problems are over.
The crypto community spoke out strongly against it, and the proposal, despite having a great deal of political muscle behind it, did not fly very far. Another sensible reason for its failure to gain acceptance was that it would have had no chance of success on the international market. Even if domestic use could have been forced through legislation, let's say, no other nation with a clue would pick it up.
If I can predict the value of a symmetric key, or the value whose two factors constitute an asymmetric key pair, I have effectively broken the encryption. Even supposing that I can't do this deterministically, but merely somewhat better than random, I'm still that much further ahead.
His main point was that the status quo enforcement regime was primarily serving to generate enormous wealth for criminals. A secondary point was that harsher enforcement is not a way to guarantee a lower rate of drug use, and this is where he referred to the amount of drug consumption per capita in the States compared to Canada.
I don't recall him citing any particular study for this, which is understandable in the context of a radio interview. But it did sound like he was referring to a body of material, not just some casual conjecture on his part. If I can find anything further about this, I'll pass it on.
Considering that the book is cxclusively concerned with configuring proprietary network gear, that's perhaps understandable. But when the same book presumes, by its title, to offer a general treatment of end-to-end security will have badly misled its readers. This is not end-to-end security, but instead the much smaller subset which concerns how to manage network traffic.
If we genuinely want to talk about end-to-end security, we'll have to look closely at the endpoints. We have to look at them in terms of their own architectural security, as well as how they function as communicating agents. And where communication is concerned, all the stuff in the middle, generally speaking, is not trustworthy.
That's a more principled approach to what "defense in depth" means in the context of these endpoints. Sure there might be a few firewalls or encrypted tunnels along the way, but the endpoints have no means of assuring that this infrastructure is in fact secure. Should those layers fail to operate as expected, the security of the communication falls to other layers. Ultimately, the responsibility falls to the endpoints themselves.
Dealing with security in several fragmented pieces is not so great. That's because security is an emergent property of the entire system, not something which can be directly composed from elements of the system. A text which provides a treatment of security princples comprehensively would be most welcome. Let's save the "end-to-end" terminology for when we're really looking at end-to-end architectures.
It seems that the RCMP has looked at the media levy, which, as you mention, exists precisely as a concession to the industry because copying of music for personal use is permitted in Canada. And it has looked at a number of serious copyright issues that do require enforcement, and it has looked at its own finite enforcement resources.
And the RCMP has decided that it makes no sense to target personal music downloads for enforcement. I recall a few years ago that a similar decision was made by the provincial courts here in BC regarding minor drug posession. Not deemed a big risk to society, not enough resources, better things to do with them.
It makes sense to me too. Canada, you'll notice, is not exactly falling apart in comparison to the United States. We actually have a lower rate of recreational drug use than the States, according to a report aired on CBC Radio yesterday, despite a much lower rate of enforcement and sentencing. And our dollar isn't doing too bad lately, either.
Provincial enforcement of federal statutes? Because that's what copyright is, in Canada.
The debate about the relative security merits of open-source as opposed to proprietary software development has been a very long-running one
Indeed. The principle of open security was first proposed by Auguste Kerckhoffs in 1883.
Any time security depends on the secrecy of some mechanism, that security is pepetually at risk. All these millions of instances of the same vulnerable mechanism, no way to tell in general whether their security has been broken, and -- as you point out -- a certainty that the vulnerable secret cannot be contained.
In what way exactly does this remain a matter of debate?
With that in mind, consider the possibility that you often misplace your security card as your failing. Instead of blaming someone else because they won't fix your life for you, take a little responsibility.
I know, it's a bit of a novel concept at first, but just try it on and see if life gets any better. Likely, it will, because this is one of those aspects of life over which you are actually in control. Or could be.
And even supposing you could, that logic would cut both ways. It could be just as compellingly argued that "simpledog.com" is infringing on "thesimpledog.com", rather than the converse.
Where on earth did you encounter this bit of nonsense? It's commonly held that words are constructed by metaphor but the root of the metaphor need only be experiential, not necessarily visual. If it were as you claim, then blind people would be unable to construct sentences.
it isn't any hard to tell someone, hit Alt, Type H, Type A
It's not hard, but it's semantically impoverished, and it depends on a fixed keybinding scheme.
Sorry, I couldn't follow the reasoning in your last paragraph.
It's bad enough now, having to write instructions like "First select Edit -> Preferences -> Security -> Certificates -> Manage Certificates. In the resulting Certificate Manager popup, select Authorities. Now click Import..." and so on.
Anything that forces a graphical representation also forces us to converse in terms of graphical representations. And guess what, humans don't do that very well.
There is a limit to how far you can go with individually separated information silos such as Facebook and MySpace.
Culture of incompetence. Now that's a sweet turn of phrase.
Cohen saw that one implication of this result is that virus detection is an endless arms race. Viruses are free to mutate into an infinite variety of functionally equivalent forms, whereas the process of establishing their equivalence is undecidable.
We've had this result in front of us for 20 years now. It has always seemed bizarre to me that so much of our focus should therefore be on this futile exercise of closing the barn door after the horse has gone. Surely it makes more sense to design systems based on accepted security principles which reduce the opportunity for infection and contain its effects.