There are two fundamental ways to fail as a CA. There must be exactly one party in effective possession of the private key of the root cert. If the number of parties becomes less than or more than one, fail.
Mistakes happen, of course, and certificate infrastructures can be enormously complex. But if you're going to do any kind of risk mitigation, the absolutely most basic place to start would be with these two scenarios.
We have this in Canada also. I've been paying a surcharge on data backup media for years just in case some of the data might be copyrighted.
Canada is now under pressure from the recording industry, which was responsible for advocating the present arrangement, to revoke it in place of greatly increased restrictions on copying freedom. I say that's really too bad, but you're late to your own party. I've paid my share.
Even supposing we had complete freedom to do so, it would be hard to formalize a clear division between patentable and non-patentable algorithms. I agree with you, and respectfully dispute with Knuth, that some algorithms qualify as inventions. On the other hand, some algorithms arise in such a direct consequence of fundamental mathematical properties that they qualify only as discoveries. And then there's the hazy middle ground.
It's true that, by construction, and given infinite time, it's possible to enumerate all possible algorithms. In that sense, all algorithms naturally exist and can only be discovered. But this sort of reduction makes itself absurd. It's sort of like how Maxwell's Daemon was resolved in thermodynamics: the act itself of selection might not require work, but figuring out which item to select most definitely does.
Only a tiny subset of algorithms are useful. Who would want a cryptographic algorithm that occasionally yields plaintext? So I'm afraid we have to fall back on the "obviousness" test.
To claim that this caused no bias is a disgrace on the Swedish judicial system.
I absolutely agree. There is no more basic principle of justice than impartiality. To act otherwise is the sheerest arrogance.
This incident is reminiscent of the Vasa. Here again, an authority has gone out of its way to look foolish, and has succeeded so magnificently, at such a pivotal point in the evolution of technology, that I think Swedish children will be learning about in school for centuries to come.
Could be anything in those conduits. Fiber maybe. But certainly not cool air.
I also had to laugh at the caption that went with the pretty array of blue network cable and red connectors: "Data centers run enormously scaled software applications with millions of users." Well good. That's why we're looking at a patch panel then?
I don't know what it's like in the States, but here in Canada nothing prevents you from earning a P.Eng if you meet the qualifications. Some employers require this if you are to perform software engineering. Other employers want to see a degree in Computer Science.
So I kind of don't see your point. You want a particular professional organization to create a new accrediation and for some licensing body to recognize it? Well go ahead, talk to them. There's no point in coming to me about it, as I'm not part of that system. I have a hard enough time just convincing ordinary people that computer science is not the same as computer programming.
Okay, as the person who wrote the first implementation of my university's longstanding Accepable Use Policy, let me ask a fundamental question:
In what manner are student's personal systems permitted to access the Central Michigan University network that is different from how a hundred million ISP customers access the Internet?
If there is no difference, then the university doesn't have a better case for control over theses personal systems than any ISP does. Yes, in order to fairly deliver the network service to its customers, the ISP or the university may control bandwidth or cap usage or perform other kinds of traffic shaping. Yes, it may monitor traffic for this purpose. There is no reasonable expectation of privacy when exposing such traffic on the network. There is also no reasonable expectation for these personal systems to be trusted. An appropriate policy would grant access to the network under these terms. Many universities do this, and treat this part of the network in every respect as an extension of the Internet. This is an effective policy.
If on the other hand these personal systems are being granted some degree of trust or privilege merely by virtue of their presence on the university network, then we clearly see a misdesigned network and a corresponding misapplication of policy. There are parts of any organizational network that people don't get to just plug random equipment into. So don't sell access to these networks to the student population. Duh. If a research group wants to attach its supercomputer cluster to the Teragrid infrastructure, for example, it should be subject to a restrictive usage policy. That's the kind of scenario that most universities, including mine, envisioned when we drafted our usage policy. The same for an outside consultant who needs connectivity to the administrative servers in order to perform software integration. But this sort of policy would be completely inappropriate for a student who is simply getting an Internet connection through university facilities.
So how about the following proposal for the university to consider? How about you don't give every student a bomb and you don't then require them to submit to random strip searches because of the increased security risk that you brought upon yourself? It's easy to avoid the whole problem in the first place.
Except that the field and practice of architecture over the past few decades has lost a great deal of respect. Far from being a requirement for licensed architects have an undergraduate background in materials science or engineering, or any working experience in the construction industry or related trades, many architects hold themselves distinctly apart from these communities of expertise.
Partly that's just due to the way our modern world encourages career specialization. Partly it seems to be the culture which is drawn to the fields of architecture and design and which treats them foremost as a forum for artistic expression and social artifact, only very secondarily as disciplines requiring technical rigor.
So it's true that not every schmuck can operate as a licensed architect. Not every schmuck has the ability and drive to earn a degree in computer science or engineering either, especially not in a graduate program. That would be a fair equivalent for comparison in your example.
The vast majority of people who write code professionally are more the equivalent of construction workers. Sure they're schmucks. So what. Nobody would confuse them with computer scientists or software engineers, or architects for that matter. If they've got a certificate from some technical college then they're more like skilled tradespeople, but again there should be no confusion between their ability to apply industry knowledge and what computer scientists, software engineers, and architects do, which is to advance that knowledge.
And I'm no longer even so sure that architects do as much advancing of human knowledge as they used to. A further irony is that those construction workers have an experience of the field that most architects utterly lack. Even though "any schmuck" can nail a wall plate together, you don't often see architects getting their hands so dirty. A computer scientist or software engineer who writes code, on the other hand, is completely typical. So it may be a "schmuck" activity but I think it tends to make them more competent professionals.
It's quite easy for a third party to manufacture compatible parts for an automobile. There's a huge and thriving industry based on exactly that premise.
Not so for proprietary software. Many vendors go to significant lengths, both legally and technically, to prevent this. Microsoft is a good example.
So when Microsoft says "we will no longer support this product" it's not like there is someone else who can take over that support. It's abuse of a monopoly position that has been deliberately engineered. Not cool.
And if you don't like the default key bindings, you can define your own.
And if you don't like the existing functionality, you can extend it.
So it's not just that flipping between files is trivial in Emacs. That's true, but it's only scratching the surface. You could, if you wanted, use one key to flip between files of a certain type, and another for another type. Those could be within a given window or across a set of windows, or across a set of displays for that matter. Whatever works most efficiently for you.
I'm amazed at how persistently Microsoft doesn't get it.
Look, here's how it works. The operating system protects processes from interfering with each other. This has been industry practice since the 1960's. The same concept extends to protecting users from each other and system resources from unprivileged access. The principle is called privilege containment.
I appreciate that Microsoft has not, historically, seen fit to consider privilege containment when designing its operating systems. After all, it takes more programming effort, and a longer development cycle might cut into market share. Plus, as Bill Gates once explained to me, users didn't specifically ask for it. But on the other hand, it's very hard to build security into an insecure system, especially one whose functioning still relies on crazy stuff like executable content.
So blame the victim. Encourage vendors to develop executable content, and encourage users to click on it. Make it everyone else's fault that the system doesn't itself provide the necessary protections. And just to underscore the abdication of responsibility, pop up lots and lots of confirmation windows so that there is no (legal) question that it was the user who made the choice. Remember, guns don't kill people, which is why it's okay to leave them firearms around ready to be discharged.
In a saner, more conventional world, what processes do within their own address space is their own business. To think otherwise is to misunderstand the Halting Problem. We can certainly develop programming environments which do their own memory management, and that's great. Before Java there was Lisp. It's not a new idea. And it's a very useful idea, as far as it goes.
Maybe we should ban C, is that the new idea? Who needs memcpy except someone who needs to do their own memory management? Indeed, someone who needs the freedom to program at a lower level than Java or Lisp, perhaps someone who is implementing an environment like Java or Lisp, extending PHP or Tcl/Tk, writing a protocol layer or a device driver or an embedded system, or doing any kind of fundamental operating system development.
So rather than providing reasonable privilege containment so that those people can get on with their work, we'll just forbid the practice entirely. Or maybe we should just have lots and lots more popups? "Are you SURE that you want to use memcpy here?"
Absolutely agree. If you've got a TDR, it doesn't hurt to check the commercial patch cables during installation, either. Depending on manufacturer, we find about one cable in 20 is defective.
When you have a TDR, it's also quite reasonable to cut and crimp your own cables, particularly when you're running cable in conduit or in other installations where changes are infrequent and exact length matters. The closer you get to the core of your network, the more it matters to get this stuff right. Don't rely on link stats from your switches and routers to verify that your cables are good. Well yes, of course you should monitor the link stats, but test the cables too.
When people talk about the prohibitive time required to build and test their own cables, do they remember all the other time spent during a cable installation? Labelling the cables, logging the device connections, updating the port descriptions on the connected devices: all these activities consume significant time. Buying premade cable is an effective, inexpensive, reliable way to reduce that time, but it won't reduce to zero. Most of the time, it's the right decision, but occasionally it makes great sense to build your own cables.
On the subject of thinking, it seems ironic that the proposed law punishes people for doing exactly that.
Look, I understand the desire on the part of society for criminals to be dumb. One way to achieve that would be to eliminate all the smart people. Oh, and we'd better make sure to avoid teaching all those courses in Computer Science too, because then people would learn about proxies and stuff.
It's okay if you're happy enough where you are. It sounds like you're used to a certain level of pain. Everyone's experience is unique.
For me, the math happens to run the other way. Here at work I'm forced to use Windows. I've been doing systems work for more than thirty years now, but fortunately it's almost never involved Microsoft products. The kinds of work I do have been in areas where Microsoft doesn't go, so it hasn't even been an option. When I switch to Windows it's endless irritation. Slow performance most of all, but everything, just everything is a little bit below par. My Linux systems are running on older hardware, never a problem, and easily eight or ten times more responsive.
So stay with Windows if you think it's faster and does what you need. After all, it's a free choice. Nobody is forcing you.
Sure, trot out the obligatory teflon-coated car analogy.:-)
I like your point regarding inversion of causality. It's a nice way of addressing the reoccurring claims that Windows is attacked not because it's conveniently vulnerable to attack but because it's ubiquitous. Well, hey, water is a ubiquitous source of hydrogen so by the same logic I would expect to see the energy industry all over it. No? Oh dear, now I'm really confused.
In Canada we're that much closer geographically to the US than is Europe, and certainly we have a lot in common. From the European perspective it can be genuinely hard to tell Americans and Canadians apart.
We pretty much speak the same language, listen to the same music and laugh at the same jokes, but let me tell you, we are two really different cultures when compared at close range. Attitudes toward sexuality, religion, recreational drugs, health care, human rights, military intervention, capital punishment, gender, ethnicity, food, guns, political ideology, and lots more are worlds apart. Whatever the subject, the American reflex seems to go straight to the extreme position and duke it out with whoever disagrees. The Canadian reflex is more like, oh, that's interesting.
I'm not saying that official weirdness doesn't also go down in Canada (the Robert Dziekanski incident comes immediately to mind), but somehow it doesn't seem to achieve the same consistent degree of insanity. I think that might be because it's usually possible in this country for a person to say "Oops, sorry," and seek in good faith to put their mistake right. People make mistakes, after all. It's nice to have some humility about that. When someone official does that in the States, it seems they have no recourse except to carry on with increasing bravado, which just makes them look like bullies. Which I guess in fact they are.
So, here's some free advice. Never be afraid to exercise common sense, even if it means apologizing for your lapses of common sense. And also, someone who is a bully does not deserve your admiration. Period. Even if doing so makes them rich and famous and successful. There are higher things to value.
Most consumers have heard about, you mean. Conspicuously absent are the operating systems which computer scientists most often talk about, Multics and BSD Unix in particular, but there are several other noteworthy examples, especially as we get into realtime systems.
MIT has an excellent track record for these sorts of initiatives, going all the way back to the MIT Press, and more recently its open courseware. This does not take into account the numerous events involving individual faculty who have initiated a project or taken a principled stand of one kind or another along the same lines in an atmosphere of support within the MIT culture.
As I see the situation, these initiatives are partly driven by a deep commitment to the ideals of academic freedom, but they are noteworthy in being pragmatic exercises as well. That's the test of merit where ideals are concerned, to see what happens when you implement them in real life. It's an engineering mindset, and my God, it works remarkably well.
Slashdot Mirror
There are two fundamental ways to fail as a CA. There must be exactly one party in effective possession of the private key of the root cert. If the number of parties becomes less than or more than one, fail.
Mistakes happen, of course, and certificate infrastructures can be enormously complex. But if you're going to do any kind of risk mitigation, the absolutely most basic place to start would be with these two scenarios.
Thank you for restating one of my minor points and placing it in a particularly American context.
We have this in Canada also. I've been paying a surcharge on data backup media for years just in case some of the data might be copyrighted.
Canada is now under pressure from the recording industry, which was responsible for advocating the present arrangement, to revoke it in place of greatly increased restrictions on copying freedom. I say that's really too bad, but you're late to your own party. I've paid my share.
Even supposing we had complete freedom to do so, it would be hard to formalize a clear division between patentable and non-patentable algorithms. I agree with you, and respectfully dispute with Knuth, that some algorithms qualify as inventions. On the other hand, some algorithms arise in such a direct consequence of fundamental mathematical properties that they qualify only as discoveries. And then there's the hazy middle ground.
It's true that, by construction, and given infinite time, it's possible to enumerate all possible algorithms. In that sense, all algorithms naturally exist and can only be discovered. But this sort of reduction makes itself absurd. It's sort of like how Maxwell's Daemon was resolved in thermodynamics: the act itself of selection might not require work, but figuring out which item to select most definitely does.
Only a tiny subset of algorithms are useful. Who would want a cryptographic algorithm that occasionally yields plaintext? So I'm afraid we have to fall back on the "obviousness" test.
Cover both bases. Why not? I have. I'm 53 and it just keeps on getting more interesting that way.
Cheers.
To claim that this caused no bias is a disgrace on the Swedish judicial system.
I absolutely agree. There is no more basic principle of justice than impartiality. To act otherwise is the sheerest arrogance.
This incident is reminiscent of the Vasa. Here again, an authority has gone out of its way to look foolish, and has succeeded so magnificently, at such a pivotal point in the evolution of technology, that I think Swedish children will be learning about in school for centuries to come.
Could be anything in those conduits. Fiber maybe. But certainly not cool air.
I also had to laugh at the caption that went with the pretty array of blue network cable and red connectors: "Data centers run enormously scaled software applications with millions of users." Well good. That's why we're looking at a patch panel then?
But that's a brilliant analysis of Microsoft culture. To insiders, it's axiomatic that "what's good for us" == "what's good".
I don't know what it's like in the States, but here in Canada nothing prevents you from earning a P.Eng if you meet the qualifications. Some employers require this if you are to perform software engineering. Other employers want to see a degree in Computer Science.
So I kind of don't see your point. You want a particular professional organization to create a new accrediation and for some licensing body to recognize it? Well go ahead, talk to them. There's no point in coming to me about it, as I'm not part of that system. I have a hard enough time just convincing ordinary people that computer science is not the same as computer programming.
If there is no difference, then the university doesn't have a better case for control over theses personal systems than any ISP does. Yes, in order to fairly deliver the network service to its customers, the ISP or the university may control bandwidth or cap usage or perform other kinds of traffic shaping. Yes, it may monitor traffic for this purpose. There is no reasonable expectation of privacy when exposing such traffic on the network. There is also no reasonable expectation for these personal systems to be trusted. An appropriate policy would grant access to the network under these terms. Many universities do this, and treat this part of the network in every respect as an extension of the Internet. This is an effective policy.
If on the other hand these personal systems are being granted some degree of trust or privilege merely by virtue of their presence on the university network, then we clearly see a misdesigned network and a corresponding misapplication of policy. There are parts of any organizational network that people don't get to just plug random equipment into. So don't sell access to these networks to the student population. Duh. If a research group wants to attach its supercomputer cluster to the Teragrid infrastructure, for example, it should be subject to a restrictive usage policy. That's the kind of scenario that most universities, including mine, envisioned when we drafted our usage policy. The same for an outside consultant who needs connectivity to the administrative servers in order to perform software integration. But this sort of policy would be completely inappropriate for a student who is simply getting an Internet connection through university facilities.
So how about the following proposal for the university to consider? How about you don't give every student a bomb and you don't then require them to submit to random strip searches because of the increased security risk that you brought upon yourself? It's easy to avoid the whole problem in the first place.
Except that the field and practice of architecture over the past few decades has lost a great deal of respect. Far from being a requirement for licensed architects have an undergraduate background in materials science or engineering, or any working experience in the construction industry or related trades, many architects hold themselves distinctly apart from these communities of expertise.
Partly that's just due to the way our modern world encourages career specialization. Partly it seems to be the culture which is drawn to the fields of architecture and design and which treats them foremost as a forum for artistic expression and social artifact, only very secondarily as disciplines requiring technical rigor.
So it's true that not every schmuck can operate as a licensed architect. Not every schmuck has the ability and drive to earn a degree in computer science or engineering either, especially not in a graduate program. That would be a fair equivalent for comparison in your example.
The vast majority of people who write code professionally are more the equivalent of construction workers. Sure they're schmucks. So what. Nobody would confuse them with computer scientists or software engineers, or architects for that matter. If they've got a certificate from some technical college then they're more like skilled tradespeople, but again there should be no confusion between their ability to apply industry knowledge and what computer scientists, software engineers, and architects do, which is to advance that knowledge.
And I'm no longer even so sure that architects do as much advancing of human knowledge as they used to. A further irony is that those construction workers have an experience of the field that most architects utterly lack. Even though "any schmuck" can nail a wall plate together, you don't often see architects getting their hands so dirty. A computer scientist or software engineer who writes code, on the other hand, is completely typical. So it may be a "schmuck" activity but I think it tends to make them more competent professionals.
You make a really good point.
It's quite easy for a third party to manufacture compatible parts for an automobile. There's a huge and thriving industry based on exactly that premise.
Not so for proprietary software. Many vendors go to significant lengths, both legally and technically, to prevent this. Microsoft is a good example.
So when Microsoft says "we will no longer support this product" it's not like there is someone else who can take over that support. It's abuse of a monopoly position that has been deliberately engineered. Not cool.
And if you don't like the default key bindings, you can define your own. And if you don't like the existing functionality, you can extend it. So it's not just that flipping between files is trivial in Emacs. That's true, but it's only scratching the surface. You could, if you wanted, use one key to flip between files of a certain type, and another for another type. Those could be within a given window or across a set of windows, or across a set of displays for that matter. Whatever works most efficiently for you.
I'm amazed at how persistently Microsoft doesn't get it.
Look, here's how it works. The operating system protects processes from interfering with each other. This has been industry practice since the 1960's. The same concept extends to protecting users from each other and system resources from unprivileged access. The principle is called privilege containment.
I appreciate that Microsoft has not, historically, seen fit to consider privilege containment when designing its operating systems. After all, it takes more programming effort, and a longer development cycle might cut into market share. Plus, as Bill Gates once explained to me, users didn't specifically ask for it. But on the other hand, it's very hard to build security into an insecure system, especially one whose functioning still relies on crazy stuff like executable content.
So blame the victim. Encourage vendors to develop executable content, and encourage users to click on it. Make it everyone else's fault that the system doesn't itself provide the necessary protections. And just to underscore the abdication of responsibility, pop up lots and lots of confirmation windows so that there is no (legal) question that it was the user who made the choice. Remember, guns don't kill people, which is why it's okay to leave them firearms around ready to be discharged.
In a saner, more conventional world, what processes do within their own address space is their own business. To think otherwise is to misunderstand the Halting Problem. We can certainly develop programming environments which do their own memory management, and that's great. Before Java there was Lisp. It's not a new idea. And it's a very useful idea, as far as it goes.
Maybe we should ban C, is that the new idea? Who needs memcpy except someone who needs to do their own memory management? Indeed, someone who needs the freedom to program at a lower level than Java or Lisp, perhaps someone who is implementing an environment like Java or Lisp, extending PHP or Tcl/Tk, writing a protocol layer or a device driver or an embedded system, or doing any kind of fundamental operating system development.
So rather than providing reasonable privilege containment so that those people can get on with their work, we'll just forbid the practice entirely. Or maybe we should just have lots and lots more popups? "Are you SURE that you want to use memcpy here?"
Absolutely agree. If you've got a TDR, it doesn't hurt to check the commercial patch cables during installation, either. Depending on manufacturer, we find about one cable in 20 is defective.
When you have a TDR, it's also quite reasonable to cut and crimp your own cables, particularly when you're running cable in conduit or in other installations where changes are infrequent and exact length matters. The closer you get to the core of your network, the more it matters to get this stuff right. Don't rely on link stats from your switches and routers to verify that your cables are good. Well yes, of course you should monitor the link stats, but test the cables too.
When people talk about the prohibitive time required to build and test their own cables, do they remember all the other time spent during a cable installation? Labelling the cables, logging the device connections, updating the port descriptions on the connected devices: all these activities consume significant time. Buying premade cable is an effective, inexpensive, reliable way to reduce that time, but it won't reduce to zero. Most of the time, it's the right decision, but occasionally it makes great sense to build your own cables.
On the subject of thinking, it seems ironic that the proposed law punishes people for doing exactly that.
Look, I understand the desire on the part of society for criminals to be dumb. One way to achieve that would be to eliminate all the smart people. Oh, and we'd better make sure to avoid teaching all those courses in Computer Science too, because then people would learn about proxies and stuff.
It's okay if you're happy enough where you are. It sounds like you're used to a certain level of pain. Everyone's experience is unique.
For me, the math happens to run the other way. Here at work I'm forced to use Windows. I've been doing systems work for more than thirty years now, but fortunately it's almost never involved Microsoft products. The kinds of work I do have been in areas where Microsoft doesn't go, so it hasn't even been an option. When I switch to Windows it's endless irritation. Slow performance most of all, but everything, just everything is a little bit below par. My Linux systems are running on older hardware, never a problem, and easily eight or ten times more responsive.
So stay with Windows if you think it's faster and does what you need. After all, it's a free choice. Nobody is forcing you.
Sure, trot out the obligatory teflon-coated car analogy. :-)
I like your point regarding inversion of causality. It's a nice way of addressing the reoccurring claims that Windows is attacked not because it's conveniently vulnerable to attack but because it's ubiquitous. Well, hey, water is a ubiquitous source of hydrogen so by the same logic I would expect to see the energy industry all over it. No? Oh dear, now I'm really confused.
In Canada we're that much closer geographically to the US than is Europe, and certainly we have a lot in common. From the European perspective it can be genuinely hard to tell Americans and Canadians apart.
We pretty much speak the same language, listen to the same music and laugh at the same jokes, but let me tell you, we are two really different cultures when compared at close range. Attitudes toward sexuality, religion, recreational drugs, health care, human rights, military intervention, capital punishment, gender, ethnicity, food, guns, political ideology, and lots more are worlds apart. Whatever the subject, the American reflex seems to go straight to the extreme position and duke it out with whoever disagrees. The Canadian reflex is more like, oh, that's interesting.
I'm not saying that official weirdness doesn't also go down in Canada (the Robert Dziekanski incident comes immediately to mind), but somehow it doesn't seem to achieve the same consistent degree of insanity. I think that might be because it's usually possible in this country for a person to say "Oops, sorry," and seek in good faith to put their mistake right. People make mistakes, after all. It's nice to have some humility about that. When someone official does that in the States, it seems they have no recourse except to carry on with increasing bravado, which just makes them look like bullies. Which I guess in fact they are.
So, here's some free advice. Never be afraid to exercise common sense, even if it means apologizing for your lapses of common sense. And also, someone who is a bully does not deserve your admiration. Period. Even if doing so makes them rich and famous and successful. There are higher things to value.
Agreed. Add Tenex and Genera while we're talking about advanced systems, the kind favored by computer scientists.
Um, X Windows is a server.
Most consumers have heard about, you mean. Conspicuously absent are the operating systems which computer scientists most often talk about, Multics and BSD Unix in particular, but there are several other noteworthy examples, especially as we get into realtime systems.
MIT has an excellent track record for these sorts of initiatives, going all the way back to the MIT Press, and more recently its open courseware. This does not take into account the numerous events involving individual faculty who have initiated a project or taken a principled stand of one kind or another along the same lines in an atmosphere of support within the MIT culture.
As I see the situation, these initiatives are partly driven by a deep commitment to the ideals of academic freedom, but they are noteworthy in being pragmatic exercises as well. That's the test of merit where ideals are concerned, to see what happens when you implement them in real life. It's an engineering mindset, and my God, it works remarkably well.
Yeah, it's like, it's like, the best of both worlds.