The problem is that in addition to reading headers, the core service has to launch processes and assign arbitrary security access levels to them. It needs to be a system level service to do this. So, the functionality necessary to decide where to route the request must be in the core, this includes reading the requested resource from the header. It has worked very well for IIS 6 as it has had very few security exploits.
You have several solutions already. COM+ makes it realllllllly easy to call a specific function and have that function be in a seperate process or on a different computer. IIS can host a remoted component and do all the dirty work for the developer. WCF also has a few channels that take care of all of the hard stuff.
Services that perform a simple task might be safe to run as LocalSystem. IIS is a good example. The core IIS functionality like listening on the network, reading HTTP headers, routing requests to the correct sub-process, run as LocalSystem. Anything content related like reading a file or running a server side script are launched in a seperate process from IIS as a specific user.
If you see someone running a database server or an email server as LocalSystem, then they should be "talked to", this is bad practice on a Windows system just as it is on a *nix system.
For an honest programmer, it can be done in minutes with ten lines of code.
The biggest challenge to writing a service is authenticating the client. To make it really easy, let an existing component do that for you. Just create a C# component that will be invoked via remoting and is hosted in IIS, or create a COM+ Serviced Component. Both can be created in seconds simply by inheriting from the correct class in.Net. Then write the reboot functionality, which is one Windows API call.
The message pump is simply carries two arbitrary 32-bit payloads. If one of those happens to be a callback, so be it. The message pump is not is charge of stopping the kernel component from calling the code that the callback references, the Windows memory model does that. Since Windows 95 and since the conception of Windows NT, the kernel component would have to specifically map memory from the application's address space to call it, this couldn't be used as a code injection vector.
That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account. How exactly are *nix'es very, very specific about least priveliges? Admins are taught this, major packages in big distributions follow this rule. But, *nix'es don't enforce it, they only suggest it in the documentation. Any user that runs a personal *nix desktop that they installed themselves is not going to do it right. UAC was Microsoft's attempt to enforce good behaviors for people who don't know any better. Of course it was only partially successful because it is impossible to force people not to compromise their own systems.
In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group. Everyone isn't an account that can be compromised, it's a group and it has very few permissions. You forgot LocalService, Guest, and any other account that may be created for this purpose. There is no reason why a Windows system can't run each service as a dedicated account with the minimum permission to do the job it needs to do, and it is not Microsoft's fault if someone runs a service as LocalSystem.
If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root. That's only if it runs as LocalSystem or Administrator. If someone is stupid enough to run services as those accounts, then they get what they deserve. How would that be any different from running a daemon as root in Linux?
I've always maintained that a good unix guy can do anything on windows with a bit of training, but a windows guy will generally be completely out of his element in unix. So, a good unix admin will make a good Windows admin and a poor Windows admin will make a poor unix admin. A good Windows admin will also be able to do anything on unix with a bit of training (or googleing if we're talking Linux).
good admin = good admin
bad admin = bad admin
What an earth-shattering revelation... but if this isn't what you are saying then it actually bodes even better for Windows. If I was supposed to read in an implicit "good Windows admin" that was completely out of his element in unix, then all the statement boils down to is -- "Windows is easy, unix is hard". Just in case it actually needs to be said, easy is good and hard is bad.
Unescaped stored procedure calls are just as vulnerable to SQL injection as raw SQL. It's the call that gets hacked, not the procedure itself, and the call is just SQL.
Also, most people who use nothing but stored procedures usually settle on a convention for CRUDing a table. Usually something like having four or more procedures named something like Customer_ins, Customer_del, Customer_upd, and a maybe bunch of variants of Customer_get. These are as easy to hack via SQL injection as not using stored procedures at all.
Now, if you have a very well thought out and planned business layer of stored procedures with well-designed permissions, then you are ahead of the game and you expose nothing more than your app's functionality to SQL injection. But the cost is that you have to write every line of business code in Transact-SQL, which is one of the worst programming languages on earth. You might as well write it in COBOL.
The simpler solution is to have a data access layer that does parameter escaping for you. Then you are safe from SQL injection and can use any language you want on top of it. You can even use stored procedures as much or as little as you like. Personally I prefer to use multi-statement table-valued functions any time I can instead of stored procedures because you can join them and slap where clauses on them, you they are written exactly as stored procedures are. They also have a few extra performance optimization benefits due to the restriction of only allowing deterministic operations in UDFs while stored procedures are allowed to be non-deterministic. The server has to run each unique call to a stored procedure because stored procedures are no guaranteed to return the same results call after call even if the same parameters are passed in. User defined function calls can be short-circuited after the first call with the same set of parameters since they are guaranteed to always return the same results.
For data modifications I like to use triggers to enforce advanced security rules where possible. Sure they incur a performance cost in cases where a transaction is rolled back, but that should be very rare. The biggest advantage to me is that I am left with a design that is very compatible with every tool out there. Many tools are not stored procedure friendly, but they all are table friendly.
I've written lots of image manipulation code in VB.Net. I wrote a 3of9 bar code recognizer and an app that overlays barcodes on a TIFF in VB.Net. It was fast enough to keep up with a $50,000 scanner.
System.Runtime.InteropServices.Marshal is your friend.
An IP is no more an identity than a phone number is. Though phone numbers aren't identities, people get arrested all the time for calling bomb threats to schools and airports. Sometimes the guilty are caught, sometimes they get away.
No one with a technical background ever claimed that an IP or MAC was traceable to a computer. I remember configuring NetWare IPX clients in 1994 and being able to configure an arbitrary MAC address. I've been working with NAT forever and NAT breaks the IP to client relationship.
An IP address was never designed to be a user identity. Heck, when IP addresses were conceived, the idea of one person having a whole computer to themselves was still on the horizon. Just because you want it to work that way doesn't mean everyone else should change their practices to make it so.
If you want to push for a global authentication scheme to make people on the Internet accountable, fine go do that. But don't pretend that IP addresses are that scheme. It would be far too easy to frame someone if IP addresses become admissible as identity in court.
Standardization of passwords is just a work-around (and a dangerous one). The real problem is the appalling lack of single sign on. There are tons of commercial and free implementations of LDAP and other Directories, and a lot of major applications support them. However, it is very difficult to convince developers of small project to get on board and it is very difficult to convince admins and architects the importance of single sign on. With a decent sso system, you wouldn't have to make your passwords match, you would only have one password.
There is actually a huge flaw in the whole use-the-same-password-everywhere mentality. If some compromises the cheesey blog that you use, they get the password to your online bank accounts. If someone sniffs the password from an unencrypted packet to an Intranet site, they have your network logon.
You can't take care of security at the infrastructure level. Insecure products can be built on a secure infrastructure. Commercial software will continue to force users to run with elevated permissions. New document formats and communications channels will provide new places for malware to hide. Infrastructure cannot police end-to-end secure tunnels.
Unless everyone participates in security, the system is not secure. As we learned years ago, a password can be purchased for a candy bar. Millions of AOL email accounts will be sold for a few hundred thousand dollars by a low end tech with the permissions to do so.
I have been troubled for years at the tendency for organizations to have a "security department". As soon as you take security off your developer's plates, they immediately start writing un-securable software. Same goes for administrators, if they buy security instead of doing it, they are going to cause problems.
I did the same with my MythTV front end. I bought an adapter and a cheap 8GB CF from newegg. Mine boots reasonably fast (about the same as my other front end with an old 120GB drive), but it took about 20 hours to install Fedora Core 8 and run a software update. Every once in a while it freezes on live TV playback, and I think it is some sort of delay writing to the flash drive. My other front end has no such problems. The one with the CF has better specs than the one with the hard drive - much faster processor, more memory, better video card.
My motorcycle has a flat torque curve from 4500 rpm to almost 10000 rpm. By any definition of the word torque, I have a lot of it.
By a qualitative definition where torque is a quality where an engine has "oomph" in a large portion or its rpm range, I have over 80% of peak torque available in 75% of the powerband. I ride a freakin' stump puller.
By a quantitative definition, my bike makes 125 ft-lbs of peak torque. Both for a 1.4 liter engine and for a 500 pound vehicle that is a heck of lot of torque. 6th gear tops out at 195mph, but I can drive around in 6th at 55mph and still pass cars with very quickly without shifting. Magazine tests list my bike with a 2.4 second 60mph to 80mph time in 6th gear when stock. Mine isn't stock any more, stock was 97 ft-lbs of torque.
I can do 0 to 60 in 2.7 seconds and 1/4 mile in 9.8 seconds at 150mph. I can also get 45mpg if I drive nice and well over 50mpg if I really try.
I have a nine year old motorcycle with a 1.4 liter engine that makes a measured 200 rear-wheel HP, naturally aspirated. That works out to close to 240HP at the crank. The bike has 20,000 miles of real driving on it and it still runs like new. The 100HP-per-liter that the S2000 makes isn't very impressive. Motorcycles hit 100HP-per-liter in the 60s, maybe sooner. I know my old 1985 RZ350 made over that, my 1973 YZ250 also tops 100HP-per-liter.
I agree. New York is one of those states where each County has a different tax rate, and they seem to change every five years or so. I can't imagine how a non-New York retailer is going to pay their New York sales tax bill. If five or six other states start doing this, it will be very difficult for small businisses to sell on the Internet.
You're mixing events. You learned from the targeted learning that you did after the test, not from the test itself. It's incorrect to say that you learned anything from the test other than what your strengths and weaknesses are.
This started from the parent of my original reply making this statement...
...but maybe the point of this exercise wasn't *just* about scaring people, but about trying to educate them in such a way that they remember the lesson? So, it could have a longer term positive impact that you credit it.
That poster was being speculative about the potential future actions the Army may take. This test will not have the positive impact from the quote, even if a future independent action might. It is no more correct to attribute that impact to this test as it would be to claim that this test cured cancer. The presentation of the results might be about scaring people and the follow-up actions that come from this might be used to educate people. However, neither of these courses of action could even be considered until after the tests have been collected, scored, and analyzed. Therefore, there could not have been a single cohesive plan to both test and then scare the test takers with the results of the test. The point of this exercise was simply to assess whether there is a real problem. No more, no less.
Ummmm.... This was a test, not a lesson. A good test is designed to evaluate something, not to educate or to scare. Now, the Army knows at what rate people can be scammed. This data will either be used to judge the effectiveness of their previous training (if there has been any), or as a baseline to judge effectiveness of future training. You cannot teach during a test without destroying the statistical validity of the results.
I believe leopard has the (currently unused) capability to do this built in as well.
Windows has had this capability since 2000 through group policy. One of the restrictions is to allow a specific whitelist of software to run, specified as file hashes. The Microsoft.Net framework has the ability to restrict software by publisher signature.
A general purpose operating system can't get by with forcing all software to be signed by the OS vendor. However, the iPhone may succeed with this model because it is a phone and people won't have the expectation of general purpose usability. Comparing this feature with desktop OS feature is an apples to oranges comparison.
It won't reduce actual "business domain" bugs, but it can drastically reduce blatent programmer screwups like forgetting to deallocate memory or using memory after it has been deallocated. It turns out that most of the security vulnerabilities in the wild aren't cases where someone forgot to enforce a rule, but they simply screwed up coding the thing.
As for your comment about performance -- Not all managed implementations of everything are slower than native implementations. Read the article to see that they did manage to make some features of Singularity faster than current operating systems. Speed wasn't even one of their design goals and they still got decent results.
Twenty years from now, no operating systems will allow arbirtary code to load and run without that code first describing what kind of interactions it is going to want to have with the outside world. Microsft simply wants to test the waters and see what the challenges will be when that day comes.
The problem as actually worse than you describe. Even if everyone was paying perfect attention and driving according to your rules (which I agree with), the traffic jam wave effect would still happen. The problem is that cars are 15 to 20 feet long and they don't compress when the car slows. So, if you are driving a comfortable distance behind someone and the whole roadway slows to 1/2 the speed it was travelling at, you will now be following too closely. This is because a "comfortable distance" involves a time factor and a non-time factor. The comfortable distance is longer with higher speeds and it is measured from your front bumper to the next car's back bumper. When stopped, a comfortable distance is about 5 to 10 feet. So, {Comfortable Distance} = 5/(1+{speed}) + ({speed} * {braking confidence factor}). {Roadspace needed for one car} = {Length of car} + {Comfortable Distance}
Do the math and you'll see that if an entire roadway is forced to stop fairly quickly, the 20th or so car back would actually have to back up to remain a comfortable distance behind the car in front of him. We now have a space deficit. The cars behind will remain stopped until the space deficit is paid by a space surplus from someone who was lagging behind, or until it gets back to a place in the road where the traffic isn't space constrained (no traffic jam).
The same math also shows that when traffic start moving again, the cars up front that are able to accelerate rapidly will end up temporarily in a new traffic jam. Each car get virtually larger because the {Roadspace needed for one car} value keeps getting bigger as the cars speeds up. Being second feels like following a car whose front end is going 60mph, but the back end is going 58mph. Then you go 58mph, but the car behind you sees the "free space" in front of him moving forward at 56mph. As the cars settle out at 85mph(this is the 405 after all), the space they occupy stabilizes and gaps in the roadway form due to the car behind you not quite catching up to you. The wasted space is felt as wasted time by those still in the parking lot behind you.
Bravo.
Every time I'm confronted with a "common sense" solution to an age-old problem, I always go through a thought process like the one in the parent. Common sense falls into two categories; ideas that are so blinding obvious and true that we all accept them, and ideas that sound right, but are actually totally wrong. The first category doesn't provoke much discussion, so we don't hear these ideas often after childhood.
What this means is that if you are discussing a topic that has been known for a long time, but never solved, then the common sense approach is always wrong. Trust me, someone has already tried the common sense approach and failed. If they hadn't failed, then we wouldn't be discussing the problem as adults. The war on drugs is a great example. Common sense says that if we punish addicts severely enough, they'll stop. Every society has tried it and it never works in the long term.
The "why are we here" problem is has been around as long as conciousness. Whatever your gut feeling is, you are probably wrong. Birds fly because the air is filled with countless tiny things that you can't see. The sky is blue because blue light refracts at a sharper angle than red light. Salt is made out of one part explosive metal and one part deadly gas. We are here because... well we don't know. Whatever the right answer is, it won't make sense for a long long time after it is proven correct. If you have some theory formulated, and it makes sense but cannot be proven, you are wrong. All of the naive theories about why the sky is blue, why birds fly, and what stuff is really made of were all wrong before a lot of good scientific work was done to get the answers. School kids need to spend years thinking about these things to be able to wrap their minds around the truth.
I don't care if you do or don't know what you are doing. I don't care if there are reasons for these things. Until you can put the sort of oversight into these programs that it takes to earn the public trust, stop expanding the invasion of privacy of Americans -- even the criminals.
Drop the "brotherhood" attitude and start treating us regular people like we deserve your respect and we'll let you do more. As long as law enforcement or intelligence allows their own to commit even the smallest crimes against the citizenry without jumping all over them, you are not wanted. You are here to protect me, not to protect each other. Show me you are on my side by putting the corrupt 1% of you in jail and I'll change my mind.
I don't want you. I don't want your help. I don't like you.
BTW, you are not my parents, you are my security guards. You have been stealing from my fridge and taking the car for joy rides (not all of you, but the food is gone and there is a dent in the fender). Please, don't be surprised when you don't get a Christmas card.
Slashdot Mirror
The problem is that in addition to reading headers, the core service has to launch processes and assign arbitrary security access levels to them. It needs to be a system level service to do this. So, the functionality necessary to decide where to route the request must be in the core, this includes reading the requested resource from the header. It has worked very well for IIS 6 as it has had very few security exploits.
You have several solutions already. COM+ makes it realllllllly easy to call a specific function and have that function be in a seperate process or on a different computer. IIS can host a remoted component and do all the dirty work for the developer. WCF also has a few channels that take care of all of the hard stuff.
Services that perform a simple task might be safe to run as LocalSystem. IIS is a good example. The core IIS functionality like listening on the network, reading HTTP headers, routing requests to the correct sub-process, run as LocalSystem. Anything content related like reading a file or running a server side script are launched in a seperate process from IIS as a specific user.
If you see someone running a database server or an email server as LocalSystem, then they should be "talked to", this is bad practice on a Windows system just as it is on a *nix system.
For an honest programmer, it can be done in minutes with ten lines of code.
.Net. Then write the reboot functionality, which is one Windows API call.
The biggest challenge to writing a service is authenticating the client. To make it really easy, let an existing component do that for you. Just create a C# component that will be invoked via remoting and is hosted in IIS, or create a COM+ Serviced Component. Both can be created in seconds simply by inheriting from the correct class in
That's probably why *nix'es are very, very specific about separation of concerns and granting the least possible permissions to a limited service account. How exactly are *nix'es very, very specific about least priveliges? Admins are taught this, major packages in big distributions follow this rule. But, *nix'es don't enforce it, they only suggest it in the documentation. Any user that runs a personal *nix desktop that they installed themselves is not going to do it right. UAC was Microsoft's attempt to enforce good behaviors for people who don't know any better. Of course it was only partially successful because it is impossible to force people not to compromise their own systems. In Windows, you've only got about 3 accounts, Local System, Network Service, and Everyone group. Everyone isn't an account that can be compromised, it's a group and it has very few permissions. You forgot LocalService, Guest, and any other account that may be created for this purpose. There is no reason why a Windows system can't run each service as a dedicated account with the minimum permission to do the job it needs to do, and it is not Microsoft's fault if someone runs a service as LocalSystem. If a single service gets owned, it's running rogue at the same level of permissions, system wide, as root. That's only if it runs as LocalSystem or Administrator. If someone is stupid enough to run services as those accounts, then they get what they deserve. How would that be any different from running a daemon as root in Linux?
good admin = good admin
bad admin = bad admin
What an earth-shattering revelation... but if this isn't what you are saying then it actually bodes even better for Windows. If I was supposed to read in an implicit "good Windows admin" that was completely out of his element in unix, then all the statement boils down to is -- "Windows is easy, unix is hard". Just in case it actually needs to be said, easy is good and hard is bad.
Unescaped stored procedure calls are just as vulnerable to SQL injection as raw SQL. It's the call that gets hacked, not the procedure itself, and the call is just SQL.
Also, most people who use nothing but stored procedures usually settle on a convention for CRUDing a table. Usually something like having four or more procedures named something like Customer_ins, Customer_del, Customer_upd, and a maybe bunch of variants of Customer_get. These are as easy to hack via SQL injection as not using stored procedures at all.
Now, if you have a very well thought out and planned business layer of stored procedures with well-designed permissions, then you are ahead of the game and you expose nothing more than your app's functionality to SQL injection. But the cost is that you have to write every line of business code in Transact-SQL, which is one of the worst programming languages on earth. You might as well write it in COBOL.
The simpler solution is to have a data access layer that does parameter escaping for you. Then you are safe from SQL injection and can use any language you want on top of it. You can even use stored procedures as much or as little as you like. Personally I prefer to use multi-statement table-valued functions any time I can instead of stored procedures because you can join them and slap where clauses on them, you they are written exactly as stored procedures are. They also have a few extra performance optimization benefits due to the restriction of only allowing deterministic operations in UDFs while stored procedures are allowed to be non-deterministic. The server has to run each unique call to a stored procedure because stored procedures are no guaranteed to return the same results call after call even if the same parameters are passed in. User defined function calls can be short-circuited after the first call with the same set of parameters since they are guaranteed to always return the same results.
For data modifications I like to use triggers to enforce advanced security rules where possible. Sure they incur a performance cost in cases where a transaction is rolled back, but that should be very rare. The biggest advantage to me is that I am left with a design that is very compatible with every tool out there. Many tools are not stored procedure friendly, but they all are table friendly.
I've written lots of image manipulation code in VB.Net. I wrote a 3of9 bar code recognizer and an app that overlays barcodes on a TIFF in VB.Net. It was fast enough to keep up with a $50,000 scanner.
System.Runtime.InteropServices.Marshal is your friend.
An IP is no more an identity than a phone number is. Though phone numbers aren't identities, people get arrested all the time for calling bomb threats to schools and airports. Sometimes the guilty are caught, sometimes they get away.
No one with a technical background ever claimed that an IP or MAC was traceable to a computer. I remember configuring NetWare IPX clients in 1994 and being able to configure an arbitrary MAC address. I've been working with NAT forever and NAT breaks the IP to client relationship.
An IP address was never designed to be a user identity. Heck, when IP addresses were conceived, the idea of one person having a whole computer to themselves was still on the horizon. Just because you want it to work that way doesn't mean everyone else should change their practices to make it so.
If you want to push for a global authentication scheme to make people on the Internet accountable, fine go do that. But don't pretend that IP addresses are that scheme. It would be far too easy to frame someone if IP addresses become admissible as identity in court.
Standardization of passwords is just a work-around (and a dangerous one). The real problem is the appalling lack of single sign on. There are tons of commercial and free implementations of LDAP and other Directories, and a lot of major applications support them. However, it is very difficult to convince developers of small project to get on board and it is very difficult to convince admins and architects the importance of single sign on. With a decent sso system, you wouldn't have to make your passwords match, you would only have one password.
There is actually a huge flaw in the whole use-the-same-password-everywhere mentality. If some compromises the cheesey blog that you use, they get the password to your online bank accounts. If someone sniffs the password from an unencrypted packet to an Intranet site, they have your network logon.
You can't take care of security at the infrastructure level. Insecure products can be built on a secure infrastructure. Commercial software will continue to force users to run with elevated permissions. New document formats and communications channels will provide new places for malware to hide. Infrastructure cannot police end-to-end secure tunnels.
Unless everyone participates in security, the system is not secure. As we learned years ago, a password can be purchased for a candy bar. Millions of AOL email accounts will be sold for a few hundred thousand dollars by a low end tech with the permissions to do so.
I have been troubled for years at the tendency for organizations to have a "security department". As soon as you take security off your developer's plates, they immediately start writing un-securable software. Same goes for administrators, if they buy security instead of doing it, they are going to cause problems.
I did the same with my MythTV front end. I bought an adapter and a cheap 8GB CF from newegg. Mine boots reasonably fast (about the same as my other front end with an old 120GB drive), but it took about 20 hours to install Fedora Core 8 and run a software update. Every once in a while it freezes on live TV playback, and I think it is some sort of delay writing to the flash drive. My other front end has no such problems. The one with the CF has better specs than the one with the hard drive - much faster processor, more memory, better video card.
My motorcycle has a flat torque curve from 4500 rpm to almost 10000 rpm. By any definition of the word torque, I have a lot of it.
By a qualitative definition where torque is a quality where an engine has "oomph" in a large portion or its rpm range, I have over 80% of peak torque available in 75% of the powerband. I ride a freakin' stump puller.
By a quantitative definition, my bike makes 125 ft-lbs of peak torque. Both for a 1.4 liter engine and for a 500 pound vehicle that is a heck of lot of torque. 6th gear tops out at 195mph, but I can drive around in 6th at 55mph and still pass cars with very quickly without shifting. Magazine tests list my bike with a 2.4 second 60mph to 80mph time in 6th gear when stock. Mine isn't stock any more, stock was 97 ft-lbs of torque.
I can do 0 to 60 in 2.7 seconds and 1/4 mile in 9.8 seconds at 150mph. I can also get 45mpg if I drive nice and well over 50mpg if I really try.
I have a nine year old motorcycle with a 1.4 liter engine that makes a measured 200 rear-wheel HP, naturally aspirated. That works out to close to 240HP at the crank. The bike has 20,000 miles of real driving on it and it still runs like new. The 100HP-per-liter that the S2000 makes isn't very impressive. Motorcycles hit 100HP-per-liter in the 60s, maybe sooner. I know my old 1985 RZ350 made over that, my 1973 YZ250 also tops 100HP-per-liter.
I agree. New York is one of those states where each County has a different tax rate, and they seem to change every five years or so. I can't imagine how a non-New York retailer is going to pay their New York sales tax bill. If five or six other states start doing this, it will be very difficult for small businisses to sell on the Internet.
This started from the parent of my original reply making this statement...
...but maybe the point of this exercise wasn't *just* about scaring people, but about trying to educate them in such a way that they remember the lesson? So, it could have a longer term positive impact that you credit it.That poster was being speculative about the potential future actions the Army may take. This test will not have the positive impact from the quote, even if a future independent action might. It is no more correct to attribute that impact to this test as it would be to claim that this test cured cancer. The presentation of the results might be about scaring people and the follow-up actions that come from this might be used to educate people. However, neither of these courses of action could even be considered until after the tests have been collected, scored, and analyzed. Therefore, there could not have been a single cohesive plan to both test and then scare the test takers with the results of the test. The point of this exercise was simply to assess whether there is a real problem. No more, no less.
Actually it reads: "This Product May Contain up to 10% Ethanol by volume". The sticker is not useful in determining the actual content.
Ummmm.... This was a test, not a lesson. A good test is designed to evaluate something, not to educate or to scare. Now, the Army knows at what rate people can be scammed. This data will either be used to judge the effectiveness of their previous training (if there has been any), or as a baseline to judge effectiveness of future training. You cannot teach during a test without destroying the statistical validity of the results.
MD5 or SHA1. See http://technet.microsoft.com/en-us/library/bb457006.aspx#EMAA for more details.
Windows has had this capability since 2000 through group policy. One of the restrictions is to allow a specific whitelist of software to run, specified as file hashes. The Microsoft
A general purpose operating system can't get by with forcing all software to be signed by the OS vendor. However, the iPhone may succeed with this model because it is a phone and people won't have the expectation of general purpose usability. Comparing this feature with desktop OS feature is an apples to oranges comparison.
It won't reduce actual "business domain" bugs, but it can drastically reduce blatent programmer screwups like forgetting to deallocate memory or using memory after it has been deallocated. It turns out that most of the security vulnerabilities in the wild aren't cases where someone forgot to enforce a rule, but they simply screwed up coding the thing.
As for your comment about performance -- Not all managed implementations of everything are slower than native implementations. Read the article to see that they did manage to make some features of Singularity faster than current operating systems. Speed wasn't even one of their design goals and they still got decent results.
Twenty years from now, no operating systems will allow arbirtary code to load and run without that code first describing what kind of interactions it is going to want to have with the outside world. Microsft simply wants to test the waters and see what the challenges will be when that day comes.
The problem as actually worse than you describe. Even if everyone was paying perfect attention and driving according to your rules (which I agree with), the traffic jam wave effect would still happen. The problem is that cars are 15 to 20 feet long and they don't compress when the car slows. So, if you are driving a comfortable distance behind someone and the whole roadway slows to 1/2 the speed it was travelling at, you will now be following too closely. This is because a "comfortable distance" involves a time factor and a non-time factor. The comfortable distance is longer with higher speeds and it is measured from your front bumper to the next car's back bumper. When stopped, a comfortable distance is about 5 to 10 feet. So, {Comfortable Distance} = 5/(1+{speed}) + ({speed} * {braking confidence factor}). {Roadspace needed for one car} = {Length of car} + {Comfortable Distance}
Do the math and you'll see that if an entire roadway is forced to stop fairly quickly, the 20th or so car back would actually have to back up to remain a comfortable distance behind the car in front of him. We now have a space deficit. The cars behind will remain stopped until the space deficit is paid by a space surplus from someone who was lagging behind, or until it gets back to a place in the road where the traffic isn't space constrained (no traffic jam).
The same math also shows that when traffic start moving again, the cars up front that are able to accelerate rapidly will end up temporarily in a new traffic jam. Each car get virtually larger because the {Roadspace needed for one car} value keeps getting bigger as the cars speeds up. Being second feels like following a car whose front end is going 60mph, but the back end is going 58mph. Then you go 58mph, but the car behind you sees the "free space" in front of him moving forward at 56mph. As the cars settle out at 85mph(this is the 405 after all), the space they occupy stabilizes and gaps in the roadway form due to the car behind you not quite catching up to you. The wasted space is felt as wasted time by those still in the parking lot behind you.
Bravo. Every time I'm confronted with a "common sense" solution to an age-old problem, I always go through a thought process like the one in the parent. Common sense falls into two categories; ideas that are so blinding obvious and true that we all accept them, and ideas that sound right, but are actually totally wrong. The first category doesn't provoke much discussion, so we don't hear these ideas often after childhood.
What this means is that if you are discussing a topic that has been known for a long time, but never solved, then the common sense approach is always wrong. Trust me, someone has already tried the common sense approach and failed. If they hadn't failed, then we wouldn't be discussing the problem as adults. The war on drugs is a great example. Common sense says that if we punish addicts severely enough, they'll stop. Every society has tried it and it never works in the long term.
The "why are we here" problem is has been around as long as conciousness. Whatever your gut feeling is, you are probably wrong. Birds fly because the air is filled with countless tiny things that you can't see. The sky is blue because blue light refracts at a sharper angle than red light. Salt is made out of one part explosive metal and one part deadly gas. We are here because... well we don't know. Whatever the right answer is, it won't make sense for a long long time after it is proven correct. If you have some theory formulated, and it makes sense but cannot be proven, you are wrong. All of the naive theories about why the sky is blue, why birds fly, and what stuff is really made of were all wrong before a lot of good scientific work was done to get the answers. School kids need to spend years thinking about these things to be able to wrap their minds around the truth.
I don't care if you do or don't know what you are doing. I don't care if there are reasons for these things. Until you can put the sort of oversight into these programs that it takes to earn the public trust, stop expanding the invasion of privacy of Americans -- even the criminals.
Drop the "brotherhood" attitude and start treating us regular people like we deserve your respect and we'll let you do more. As long as law enforcement or intelligence allows their own to commit even the smallest crimes against the citizenry without jumping all over them, you are not wanted. You are here to protect me, not to protect each other. Show me you are on my side by putting the corrupt 1% of you in jail and I'll change my mind.
I don't want you. I don't want your help. I don't like you.
BTW, you are not my parents, you are my security guards. You have been stealing from my fridge and taking the car for joy rides (not all of you, but the food is gone and there is a dent in the fender). Please, don't be surprised when you don't get a Christmas card.
Even better, just install a second thermostat. Hook the A/C up to yours and don't hook anything up to theirs.