We are migrating away from Way2Call boxes at my workplace. I was going to suggest this for a home setup but you beat me to it. However, when I took over my job, we were using Way2Call devices through TeleTools. The API for the Way2Call is fairly simple and I solved a lot of reliability problems by scrapping TeleTools and using the Way2Call API from the app. I wouldn't recommend TeleTools to anyone unless they specifically wanted to make an application that is hardware independent.
We are currently moving to Nortel CCT and will soon be moving some people into a call center with an existing Cisco VOIP infrastructure. I don't know about Cisco, but Nortel's sample software a horrible. The API is callback based and the sample app from Nortel breaks every threading rule that has ever existed. They call it the "Reference Client" and pretend that it is the embodiment of "doing it right". I am actually starting to miss the Way2Call boxes.
You're defending the wrong point. I never said that students shouldn't learn to write viruses because it's evil or dangerous. I said students shouldn't learn to write viruses because it is a poor way to learn information security. I really don't care if they are now "a threat" because of taking this class. The last person I'd be scared of is a student who decided to take a class on virus writing. The success stories in that industry are all self-starters. However, the 14 class hours and countless hours spent on homework and projects have been 100% wasted. The students now have an appreciation for how easy it is to be the attacker... big deal. If they didn't already read that and believe it, they are going to fail at information security. If every little point has to be driven home with 50 hours of practice, then they have heads made out of rocks.
What is the expected takeaway from this class? Are the students supposed to hand threat model all systems and test their defenses with home-made viruses? Any half-baked defense scheme will stand up to an attack crafted by the defender. Just look at Kryptonite bicycle locks -- years of research and development defeated by a BIC pen. The lesson is that nothing is even reasonably secure until it has been exposed to many thousands of attack attempts by many thousands of deviant minds. This class will only serve to delude some of the students into thinking they are penetration testing when they are actually just randomly poking at their defenses.
So, police training should involve mugging practice and fire-fighter training should involve learning how to set fires. Now, I'm aware of the fact that in order to practice fighting fires, there has to be an actual fire to fight and someone has to set it. But, somehow I just don't see a five week training session at the fire department on the various ways to set different fires and how not to get caught.
Learning how to write viruses is largely a waste of time in an information security course. Yesterday's techniques will be antiquated tomorrow, why learn them next week? I know of information security programs in the wild right now that have the students run the old "ping of death" attack that only works on unpatched 1998 vintage systems. I've always felt that in a security course, the students should study past successful attacks and try to learn what techniques could have foiled the attack that wouldn't have required any knowledge unavailable to the attackee before the attack. Concentrating on the specifics of the attack instead of the specifics of the defense is not productive.
Although the methods you mention are good practice, they can be used to illustrate how insane the original question is. I know of several software packages that will pass every one of your tests and are still horribly insecure. Your test methods really only validate that the app doesn't cause the OS to become less secure than it was before the app was installed and that the software isn't actively trying to spy on you. Most real-world exploits start with an escalation of privilege vulnerability somewhere. Common examples would be old versions of IIS that installed samples that dropped your pants for you, old versions of MS Word that had macro problems, or any web browser three years after it is released. Certifying that software is secure is impossible. Certifying that software doesn't make a system with a known risk level worse is doable, and that is what you guys do.
Another good example of insecure software that would make it through your audit is a piece of software that we ran at my former workplace that has an SQL injection vulnerability that can be exploited through telnet. The port that is open is supposed to be open, so you would be fine with it as the purpose of the software is to allow handheld scanners to do inventory. The scanners connect to the software through this port. Since the scanners only have a barcode scanner and a simple keyboard, exploit seems unlikely. But, a carefully formed barcode can inject malicious code. How would you test for this?
The compiler I just wrote actually does something quite similar - cleanup code goes in a block at the end and when you issue a return statement it sets a local variable and jumps to the start of the box.
So you invented "finally". I'm not trying to pick on you, just pointing out that this is very useful and used in several popular languages. This turns out to be a good example of what I read elsewhere in this thread that what is good practice in one language might not be relevant in another. Java and C# both support a finally section of the try block which does exactly what you just described at the block level instead of at the function level. So, if cleanup is the justification for the "one return" rule, then it is truely useless and inappropriate in C#.
It is perfectly reasonable that the TOS has been violated by doing this. That would be a contract violation that would entitle Blizzard to actual damages, but no statutory damages. But as far as I know, a TOS has never been able to narrow down the types of derivitive works you can create under copyright law. This ruling seems to imply that as long as my next CD comes with a statement saying that I cannot copy the music to my iPod, I lose all of my fair use rights.
By transforming a contract violation into a copyright violation, this ruling crosses the line and will have serious unintended consequences. What's next, a EULA that grants the software company my indentured servitude?
You do know that since the beginning, Visual Studio used the free compilers that come with the framework, right? Also, for the past three years, the whole build process has been under the control of msbuild.exe, a framework component, not the development environment. Add a splash of NANT and you can pull the source files from CVS, SVN, or VSS.
On a side note, I'm all for not forcing tools. But, I worked with a developer that used a different text editor from everyone else. I didn't have a problem with it being "different", but he had it set to beautify all code it loaded. I nearly had to kill him. Any code Steve looked at always failed to merge properly.
The devil is in the details. Just standardizing on a toolset won't necessarily solve your problems, and not standardizing won't necessarily cause any problems. In my opinion, standardizing a toolset is pretty far down the priority list, maybe just above setting variable naming conventions and just below setting a standardized chair height.
Charge the woman for the crime she committed. Please don't charge her for a crime that I committed twice yesterday while downloading a copy of a text editor. This is the first step down the slippery slope towards prosecuting all those with the wrong political opinions.
Al Capone was prosecuted for a form of tax evasion that is a secondary effect of living a life of crime, and a crime that 95% of law abiding people don't commit. This woman is not being prosecuted for being a criminal, she is being prosecuted for lying on a trivial form at a website that few take seriously.
... consider this: when you use a resource I have made freely available, you're not denying me access to it. Even better... I set up my router in range of your router on the same channel, but I secure mine and you secure yours. We both use the Internet service that we each pay for. It turns out that my using my ISP actually deprives you of some availability of your service, yet I broke no laws. How about if one of us buy a repeater and it turns out that it repeats both of our signals to both of our respective routers? It seems that legally I'm stealing from you, yet there is no way other than lead wallpaper for me to not steal. Any law that is this confusing to apply to reasonable scenarios is obviously a horrible law.
So you agree with me. I never suggested that there was an absolute framework for "power". The summary is written in such a way that a casual reader who takes it at face value may come away believing that NVIDIA has invented some killer technology that is going to wipe Intel off the map. The truth is that the article linked from the summary refers to a group of people who found that NVIDIA GPUs happened to match their processing needs much better than the current crop of typical desktop/server processors.
Personally, I'm surprised as to why there hasn't been more development behind the FPGA: are they just expensive? Coding that close to the metal is really expensive. It is usually easier to throw servers at the problem.
I think the GP (and myself) were objecting to the use of the fairly general word "power" and the use of this one problem as a "power benchmark". While it is obviously true that 8GPUs is as fast as 300 C2Ds for this problem, this system isn't as fast as a supercomputer for most problems. All this does is point out that the recent trend of building supercomputers out of inexpensive general purpose CPUs may not be a good idea for all applications.
We've got hundreds of IT openings nationwide that we are having trouble filling. I have been interviewing people for six months and have only found one qualified candidate for two programmer positions so far. We have a labor shortage here, not a job shortage. BTW, this is the Buffalo, NY area.
In my opinion creating systems that restrict the use of media beyond the limits of fair use is the equivalent of stealing that "extra profit" from hundreds of millions of people. It is often called "extortion".
What life-threatening consequenses could it have to justify allowing media companies to create an artificial monopoly in an arena where their distribution services are no longer required? So they stop making movies, big deal. People have shown for thousands of years that they will create entertainment even in the absence of profits.
BTW, piracy is also a word mis-used to give the illusion of a more serious offense. Downloading has been running wild for 10 years. Using the most extreme estimates, the movie and music industries have only lost 10 percent of their revenue. I think this proves that "intellectual property rights infringement", on a personal scale, isn't causing businesses to collapse.
Another way to refute your argument is to point out that merely causing "a loss of profit" isn't against the law. Japanese car companies caused American car companies to lose a lot of profit of the past thirty years. Digital film technologies are financially killing Kodak.
Have you looked up the word "take". I don't think downloading a movie from bittorrent quite qualifies as "taking" in the classical sense. It counts in a world where you feel entitled to compensation and you don't get it. That entitlement is not a natural law and not even necessary for society to operate. It was added to the laws of most countries to encourage the development of industries that entertain the people.
Finally, I need to address "...if you haven't payed for it, you should do without!". So, if your spouse goes to a cooking class, should you be able to enjoy the food he or she cooks without paying for the class? If your neighbor hires a band that you like for a birthday party, are you obligated to slip money under the fence? You act like this is a black and white issue.
First person anecdotes are pretty useless for this topic. Many people who have dropped acid will testify in front of the Supreme Court that it enhanced their perception. Only a well controlled, well designed double-blind test is acceptable in this context.
It penalizes the big guys instead of the small guys, that's why it hasn't taken off. Also, no one seems to want to promote any solution that doesn't put somebody in control of something.
That means that if you veer off the fast lane... Do you realize that most of the roads in the USA don't have a fast lane? There are millions of miles of one-lane-each-way, 22 foot wide roads. They have no sidewalks and barely any shoulder. One front yard is twenty five feet from the neighbor across the 55 mile per hour street's front yard. Adding a "central reservation" would involve changing the entire of the landscape of the country and require taking ten feet from tens of millions of people's front yards. Also, there is a driveway every 200 feet or so on these roads, so how would you go home if you live on the left side of the road?
We love to drive. We love it so much that it is the 6th leading cause of preventable death and we don't care. We give pretty much everyone a license and it is almost impossible to take it away. We hold driving so central to our lives that our official ID is issued by the Department of Motor Vehicles -- even if you don't drive. Most of the US is set up in such a way that if you don't have a car, you can't buy food or get to work. You guys introduced driving at a sensible pace to an already functioning society. We couldn't use 80% of our country until cars became available to regular people. When that day came, we built roads as fast as we could. Sure, we screwed a few things up, but they were all in the name of "getting things done".
I directly attacked the comment that Tasers keep cops safe. That point cannot be debated on its own, because you can only keep cops safe by placing restrictions on the freedom of others. It has to be a balancing act, and therefore, the discussion has to be broadened. I brought up the "code of silence" issue because I do not support giving any more power to cops until they establish some system of responsibility that is palatable to me.
Static electricity only delivers a small amount of current because the power source is exhausted almost immediately. Technically, it delivers a high-current shock initially, then as the source voltage drop, so does the current. It still maintains V=IR. This has no relationship to how a Taser works as a Taser maintains the same output characteristics (victim twitching and screaming) as long as the button is held down.
This has little to do with the subject of my post, which was that current flow was the determining factor in how damaging/painful an electrical shock is. But for a fixed purely resistive load, current flow is directly proportional to voltage. So, the terms "source voltage" and "current flow" are interchangable. I realize that the body isn't purely resistive and that no power source is an ideal voltage source as they all have some internal resistance. But, it still isn't possible to externally will an extra three orders of magnitude into the current flow without raising the voltage measured at the output of the Taser.
Trying to assign the damage of an electrical shock to either voltage or current is like trying to decide if a fall victim was killed by their kenetic energy when they hit the ground or by the excessive height of the fall. They are simply two ways of saying the same thing.
I have to disagree. From my experience working in the electrical and electronics fields for over 30 years, you can have 50,000 volts across your body, but if the current flowing is only a couple of microamps, you'll barely feel anything. However, increase the current to 5-10 milliamps or more, and you'll get quite a jolt. So, you have discovered a device that can change some other factor of a power source so that it is always 50,000 volts, but it sometimes delivers 2 microamps and sometimes delivers 5 millamps over the same load? You should publish your work as the rest of the electronics community is unaware of this capability. You'll be famous.
So, the point of law enforcement is to keep cops safe? You could use that logic to justify the implanting of tazer like devices in every human at birth. Or maybe we should all walk around pre-cuffed with RFID tags so we could be put in jail more easily. Everyone except the cops, of course. I'm sure none of this will ever be used inappropriately.
The general public isn't lashing back at cops simply because they have a new power over the rest of us and it has killed a few of us. The public is lashing back because of a perceived or real lack of internal control of officers. The public believes that the police are acting as if they are above us. The police are validating that perception by stonewalling every attempt to get any officer in trouble for actions they actually committed. See the original atricle for an example of the law enforcement industry trying to whitewash one of these incidents instead of taking responsibility.
I remember a newspaper story where I found out that the Buffalo, NY police refused to be required to wear seat belts when on duty. Their argument was, "We are well trained drivers and we deserve to make our own determination of whether a seat belt would endanger or protect our lives." However, if they pull over a race car driver for not wearing a seat belt, they fall back to "Seat belts save lives, we are only giving you this ticket for your own good. It's the law, suck it up." This was also the first written public admission I have ever seen of "laws apply to you, not us".
Just buy everything with PayPal and have it shipped to yourself as a gift from a fictitious address outside of New York. If they solve this, then any non-New York resident could tax-bomb any New York resident by gift shipping all of their stuff to their own houses using a New York address as the giver.
So, it's bad design to prevent a low privileged account from escalating to a high privileged one? Good security design dictates that a process shouldn't be able to spawn processes with more privileges than itself. Any other behavior would be a potential escalation of privileges weakness. Therefore, the root process of IIS which sometimes needs to spawn high privileged processes, would need high privileges.
If you don't believe that IIS 6 has had a very good security record, then you are beyond help. Secunia list 5 vulnerabilities ever detected for IIS 6, none of them condsidered Extremely Critical and none remain unpatched. Apache 2.0 has 35 vulnerabilities, 11% still unpatched. This isn't confirmation that IIS is more secure than Apache, but it does make a very good case.
That's the misconception 99% of programmers have. When they say "stored procedures prevent SQL injection", they really mean "stored procedures called with parameterized commands prevent SQL injection." The stored procedure part of the process is actually irrelevant. That's like coming to the conclusion that white cars hold more cargo becuase your new white car holds more cargo that your previous black car. Color plays no part in cargo space and stored procedures play no role in SQL injection prevention.
I only stress this because a lot of people who know what they are doing say it wrong, but do it right. The junior programmers that listen to them hear what they say and run around the world thinking that stored procedures prevent SQL injection and then write applications that call stored procedured by concatenating strings.
Yes, T-SQL kinda blows. But it gets the job done.:) The same goes for COBOL. Heck, you could use that argument to convert all of your code to Whitespace ( http://en.wikipedia.org/wiki/Whitespace_(programming_language) ).
but unless you provide the validation tool, its still your fault - you the language designer I'll bet 90% of the coding errors were done by developers who said "I hate those Visual Studio wizards Microsoft has for data access. I can do it better myself." Sure, the wizards aren't the best way to build an application, but at least they prevent SQL injection. I meet these people every day... they think they know a lot about programming, but really they are people with 20 years of experience just barely making applications work and developing more and more bad practices every day.
It's fine to reject the tools you are given. But if you reject them, at least have a better plan. ASP.Net has easy to use form validation tools, easy to use SQL injection preventing GUI data access tools, and easy to use base classes that prevent SQL injection. The people who made these problems avoided using about twenty tools at their disposal for avoiding this class of bug. This is certainly not Microsoft's fault.
Who said Unix doesn't do it right? I'll wait while you look up LogonUser...
And What does IE6 have to do with IIS 6???
Your argument against how IIS 6 is designed boils down to "Unix does it right and Internet Explorer sucks!!". How does that in any way show that IIS 6 is designed poorly from a security perspective?
Slashdot Mirror
We are migrating away from Way2Call boxes at my workplace. I was going to suggest this for a home setup but you beat me to it. However, when I took over my job, we were using Way2Call devices through TeleTools. The API for the Way2Call is fairly simple and I solved a lot of reliability problems by scrapping TeleTools and using the Way2Call API from the app. I wouldn't recommend TeleTools to anyone unless they specifically wanted to make an application that is hardware independent.
We are currently moving to Nortel CCT and will soon be moving some people into a call center with an existing Cisco VOIP infrastructure. I don't know about Cisco, but Nortel's sample software a horrible. The API is callback based and the sample app from Nortel breaks every threading rule that has ever existed. They call it the "Reference Client" and pretend that it is the embodiment of "doing it right". I am actually starting to miss the Way2Call boxes.
You're defending the wrong point. I never said that students shouldn't learn to write viruses because it's evil or dangerous. I said students shouldn't learn to write viruses because it is a poor way to learn information security. I really don't care if they are now "a threat" because of taking this class. The last person I'd be scared of is a student who decided to take a class on virus writing. The success stories in that industry are all self-starters. However, the 14 class hours and countless hours spent on homework and projects have been 100% wasted. The students now have an appreciation for how easy it is to be the attacker... big deal. If they didn't already read that and believe it, they are going to fail at information security. If every little point has to be driven home with 50 hours of practice, then they have heads made out of rocks.
What is the expected takeaway from this class? Are the students supposed to hand threat model all systems and test their defenses with home-made viruses? Any half-baked defense scheme will stand up to an attack crafted by the defender. Just look at Kryptonite bicycle locks -- years of research and development defeated by a BIC pen. The lesson is that nothing is even reasonably secure until it has been exposed to many thousands of attack attempts by many thousands of deviant minds. This class will only serve to delude some of the students into thinking they are penetration testing when they are actually just randomly poking at their defenses.
So, police training should involve mugging practice and fire-fighter training should involve learning how to set fires. Now, I'm aware of the fact that in order to practice fighting fires, there has to be an actual fire to fight and someone has to set it. But, somehow I just don't see a five week training session at the fire department on the various ways to set different fires and how not to get caught.
Learning how to write viruses is largely a waste of time in an information security course. Yesterday's techniques will be antiquated tomorrow, why learn them next week? I know of information security programs in the wild right now that have the students run the old "ping of death" attack that only works on unpatched 1998 vintage systems. I've always felt that in a security course, the students should study past successful attacks and try to learn what techniques could have foiled the attack that wouldn't have required any knowledge unavailable to the attackee before the attack. Concentrating on the specifics of the attack instead of the specifics of the defense is not productive.
Although the methods you mention are good practice, they can be used to illustrate how insane the original question is. I know of several software packages that will pass every one of your tests and are still horribly insecure. Your test methods really only validate that the app doesn't cause the OS to become less secure than it was before the app was installed and that the software isn't actively trying to spy on you. Most real-world exploits start with an escalation of privilege vulnerability somewhere. Common examples would be old versions of IIS that installed samples that dropped your pants for you, old versions of MS Word that had macro problems, or any web browser three years after it is released. Certifying that software is secure is impossible. Certifying that software doesn't make a system with a known risk level worse is doable, and that is what you guys do.
Another good example of insecure software that would make it through your audit is a piece of software that we ran at my former workplace that has an SQL injection vulnerability that can be exploited through telnet. The port that is open is supposed to be open, so you would be fine with it as the purpose of the software is to allow handheld scanners to do inventory. The scanners connect to the software through this port. Since the scanners only have a barcode scanner and a simple keyboard, exploit seems unlikely. But, a carefully formed barcode can inject malicious code. How would you test for this?
The compiler I just wrote actually does something quite similar - cleanup code goes in a block at the end and when you issue a return statement it sets a local variable and jumps to the start of the box.
So you invented "finally". I'm not trying to pick on you, just pointing out that this is very useful and used in several popular languages. This turns out to be a good example of what I read elsewhere in this thread that what is good practice in one language might not be relevant in another. Java and C# both support a finally section of the try block which does exactly what you just described at the block level instead of at the function level. So, if cleanup is the justification for the "one return" rule, then it is truely useless and inappropriate in C#.
It is perfectly reasonable that the TOS has been violated by doing this. That would be a contract violation that would entitle Blizzard to actual damages, but no statutory damages. But as far as I know, a TOS has never been able to narrow down the types of derivitive works you can create under copyright law. This ruling seems to imply that as long as my next CD comes with a statement saying that I cannot copy the music to my iPod, I lose all of my fair use rights.
By transforming a contract violation into a copyright violation, this ruling crosses the line and will have serious unintended consequences. What's next, a EULA that grants the software company my indentured servitude?
You do know that since the beginning, Visual Studio used the free compilers that come with the framework, right? Also, for the past three years, the whole build process has been under the control of msbuild.exe, a framework component, not the development environment. Add a splash of NANT and you can pull the source files from CVS, SVN, or VSS.
On a side note, I'm all for not forcing tools. But, I worked with a developer that used a different text editor from everyone else. I didn't have a problem with it being "different", but he had it set to beautify all code it loaded. I nearly had to kill him. Any code Steve looked at always failed to merge properly.
The devil is in the details. Just standardizing on a toolset won't necessarily solve your problems, and not standardizing won't necessarily cause any problems. In my opinion, standardizing a toolset is pretty far down the priority list, maybe just above setting variable naming conventions and just below setting a standardized chair height.
Charge the woman for the crime she committed. Please don't charge her for a crime that I committed twice yesterday while downloading a copy of a text editor. This is the first step down the slippery slope towards prosecuting all those with the wrong political opinions.
Al Capone was prosecuted for a form of tax evasion that is a secondary effect of living a life of crime, and a crime that 95% of law abiding people don't commit. This woman is not being prosecuted for being a criminal, she is being prosecuted for lying on a trivial form at a website that few take seriously.
... consider this: when you use a resource I have made freely available, you're not denying me access to it. Even better... I set up my router in range of your router on the same channel, but I secure mine and you secure yours. We both use the Internet service that we each pay for. It turns out that my using my ISP actually deprives you of some availability of your service, yet I broke no laws. How about if one of us buy a repeater and it turns out that it repeats both of our signals to both of our respective routers? It seems that legally I'm stealing from you, yet there is no way other than lead wallpaper for me to not steal. Any law that is this confusing to apply to reasonable scenarios is obviously a horrible law.Personally, I'm surprised as to why there hasn't been more development behind the FPGA: are they just expensive? Coding that close to the metal is really expensive. It is usually easier to throw servers at the problem.
I think the GP (and myself) were objecting to the use of the fairly general word "power" and the use of this one problem as a "power benchmark". While it is obviously true that 8GPUs is as fast as 300 C2Ds for this problem, this system isn't as fast as a supercomputer for most problems. All this does is point out that the recent trend of building supercomputers out of inexpensive general purpose CPUs may not be a good idea for all applications.
We've got hundreds of IT openings nationwide that we are having trouble filling. I have been interviewing people for six months and have only found one qualified candidate for two programmer positions so far. We have a labor shortage here, not a job shortage. BTW, this is the Buffalo, NY area.
In my opinion creating systems that restrict the use of media beyond the limits of fair use is the equivalent of stealing that "extra profit" from hundreds of millions of people. It is often called "extortion".
What life-threatening consequenses could it have to justify allowing media companies to create an artificial monopoly in an arena where their distribution services are no longer required? So they stop making movies, big deal. People have shown for thousands of years that they will create entertainment even in the absence of profits.
BTW, piracy is also a word mis-used to give the illusion of a more serious offense. Downloading has been running wild for 10 years. Using the most extreme estimates, the movie and music industries have only lost 10 percent of their revenue. I think this proves that "intellectual property rights infringement", on a personal scale, isn't causing businesses to collapse.
Another way to refute your argument is to point out that merely causing "a loss of profit" isn't against the law. Japanese car companies caused American car companies to lose a lot of profit of the past thirty years. Digital film technologies are financially killing Kodak.
Have you looked up the word "take". I don't think downloading a movie from bittorrent quite qualifies as "taking" in the classical sense. It counts in a world where you feel entitled to compensation and you don't get it. That entitlement is not a natural law and not even necessary for society to operate. It was added to the laws of most countries to encourage the development of industries that entertain the people.
Finally, I need to address "...if you haven't payed for it, you should do without!". So, if your spouse goes to a cooking class, should you be able to enjoy the food he or she cooks without paying for the class? If your neighbor hires a band that you like for a birthday party, are you obligated to slip money under the fence? You act like this is a black and white issue.
First person anecdotes are pretty useless for this topic. Many people who have dropped acid will testify in front of the Supreme Court that it enhanced their perception. Only a well controlled, well designed double-blind test is acceptable in this context.
HashCash http://www.hashcash.org/
It penalizes the big guys instead of the small guys, that's why it hasn't taken off. Also, no one seems to want to promote any solution that doesn't put somebody in control of something.
We love to drive. We love it so much that it is the 6th leading cause of preventable death and we don't care. We give pretty much everyone a license and it is almost impossible to take it away. We hold driving so central to our lives that our official ID is issued by the Department of Motor Vehicles -- even if you don't drive. Most of the US is set up in such a way that if you don't have a car, you can't buy food or get to work. You guys introduced driving at a sensible pace to an already functioning society. We couldn't use 80% of our country until cars became available to regular people. When that day came, we built roads as fast as we could. Sure, we screwed a few things up, but they were all in the name of "getting things done".
I directly attacked the comment that Tasers keep cops safe. That point cannot be debated on its own, because you can only keep cops safe by placing restrictions on the freedom of others. It has to be a balancing act, and therefore, the discussion has to be broadened. I brought up the "code of silence" issue because I do not support giving any more power to cops until they establish some system of responsibility that is palatable to me.
This has little to do with the subject of my post, which was that current flow was the determining factor in how damaging/painful an electrical shock is. But for a fixed purely resistive load, current flow is directly proportional to voltage. So, the terms "source voltage" and "current flow" are interchangable. I realize that the body isn't purely resistive and that no power source is an ideal voltage source as they all have some internal resistance. But, it still isn't possible to externally will an extra three orders of magnitude into the current flow without raising the voltage measured at the output of the Taser.
Trying to assign the damage of an electrical shock to either voltage or current is like trying to decide if a fall victim was killed by their kenetic energy when they hit the ground or by the excessive height of the fall. They are simply two ways of saying the same thing.
So, the point of law enforcement is to keep cops safe? You could use that logic to justify the implanting of tazer like devices in every human at birth. Or maybe we should all walk around pre-cuffed with RFID tags so we could be put in jail more easily. Everyone except the cops, of course. I'm sure none of this will ever be used inappropriately.
The general public isn't lashing back at cops simply because they have a new power over the rest of us and it has killed a few of us. The public is lashing back because of a perceived or real lack of internal control of officers. The public believes that the police are acting as if they are above us. The police are validating that perception by stonewalling every attempt to get any officer in trouble for actions they actually committed. See the original atricle for an example of the law enforcement industry trying to whitewash one of these incidents instead of taking responsibility.
I remember a newspaper story where I found out that the Buffalo, NY police refused to be required to wear seat belts when on duty. Their argument was, "We are well trained drivers and we deserve to make our own determination of whether a seat belt would endanger or protect our lives." However, if they pull over a race car driver for not wearing a seat belt, they fall back to "Seat belts save lives, we are only giving you this ticket for your own good. It's the law, suck it up." This was also the first written public admission I have ever seen of "laws apply to you, not us".
Just buy everything with PayPal and have it shipped to yourself as a gift from a fictitious address outside of New York. If they solve this, then any non-New York resident could tax-bomb any New York resident by gift shipping all of their stuff to their own houses using a New York address as the giver.
So, it's bad design to prevent a low privileged account from escalating to a high privileged one? Good security design dictates that a process shouldn't be able to spawn processes with more privileges than itself. Any other behavior would be a potential escalation of privileges weakness. Therefore, the root process of IIS which sometimes needs to spawn high privileged processes, would need high privileges.
If you don't believe that IIS 6 has had a very good security record, then you are beyond help. Secunia list 5 vulnerabilities ever detected for IIS 6, none of them condsidered Extremely Critical and none remain unpatched. Apache 2.0 has 35 vulnerabilities, 11% still unpatched. This isn't confirmation that IIS is more secure than Apache, but it does make a very good case.
I only stress this because a lot of people who know what they are doing say it wrong, but do it right. The junior programmers that listen to them hear what they say and run around the world thinking that stored procedures prevent SQL injection and then write applications that call stored procedured by concatenating strings.
Yes, T-SQL kinda blows. But it gets the job done.
It's fine to reject the tools you are given. But if you reject them, at least have a better plan. ASP.Net has easy to use form validation tools, easy to use SQL injection preventing GUI data access tools, and easy to use base classes that prevent SQL injection. The people who made these problems avoided using about twenty tools at their disposal for avoiding this class of bug. This is certainly not Microsoft's fault.
Who said Unix doesn't do it right? I'll wait while you look up LogonUser...
And What does IE6 have to do with IIS 6???
Your argument against how IIS 6 is designed boils down to "Unix does it right and Internet Explorer sucks!!". How does that in any way show that IIS 6 is designed poorly from a security perspective?