Inline Rubber bullets or Rubber bullets are non-lethal projectiles that are often fired by riot police around the world to subdue violent mobs. These bullets are also used for other purposes, like target practice and animal control. Since the early 80s, they have become an integral part of riot police gear.

Some rubber bullets are made solely from rubber, whereas others are made from plastic, wax and wood and have rubber coatings. Although such bullets are not lethal, they do cause some bodily harm. These projectiles are known to cause fractures and even profuse bleeding if aimed at a less meaty part of the body. If they are accidentally fired at the head, they can even cause death.

These bullets have become the lifeblood of riot police across the globe–especially in big cities, where an enraged mob could potentially cause millions of dollars worth of damage. Riot police are often issued rubber bullet-specific guns, but some bullets can also be fired from normal single-barrel weapons.

Apart from rubber bullets, riot police use a host of other non-lethal weapons to control big mobs. Along with their ever-reliable batons and shields, they also use water cannons, tear gas, and sandbag shooters to quell riots and other unruly mob situations.

Riot police have to walk a fine line between effective crowd control and the use of excessive force which may lead to allegations of human rights violations. However, as we saw last week in London, the reluctance of police to engage rioters and deploy these painful but effective tools can lead to total chaos. We’re pretty sure the UK police have learned a rather harsh lesson, and the next time there’s similar trouble, we’ll see the rubber bullets and water cannons out in a jiffy!

Here science & technology is both boon and Bane… an always a debate topic???

Inline Rubber bullets or Rubber bullets are non-lethal projectiles that are often fired by riot police around the world to subdue violent mobs. These bullets are also used for other purposes, like target practice and animal control. Since the early 80s, they have become an integral part of riot police gear.

Some rubber bullets are made solely from rubber, whereas others are made from plastic, wax and wood and have rubber coatings. Although such bullets are not lethal, they do cause some bodily harm. These projectiles are known to cause fractures and even profuse bleeding if aimed at a less meaty part of the body. If they are accidentally fired at the head, they can even cause death.

These bullets have become the lifeblood of riot police across the globe–especially in big cities, where an enraged mob could potentially cause millions of dollars worth of damage. Riot police are often issued rubber bullet-specific guns, but some bullets can also be fired from normal single-barrel weapons.

Apart from rubber bullets, riot police use a host of other non-lethal weapons to control big mobs. Along with their ever-reliable batons and shields, they also use water cannons, tear gas, and sandbag shooters to quell riots and other unruly mob situations.

Riot police have to walk a fine line between effective crowd control and the use of excessive force which may lead to allegations of human rights violations. However, as we saw last week in London, the reluctance of police to engage rioters and deploy these painful but effective tools can lead to total chaos. We’re pretty sure the UK police have learned a rather harsh lesson, and the next time there’s similar trouble, we’ll see the rubber bullets and water cannons out in a jiffy!

Here science & technology is both boon and Bane… an always a debate topic???

I'm getting a little tired of the business card. Every time I meet a business contact, we exchange these tiny little paper calling cards. It seems so analog, so archaic in this digital age of cellphones and tablets and e-readers. Why hasn't someone created a way to exchange contact information digitally that works just as easily as handing over a slip of cardboard?

Designer Alan Sien Wei Hshieh thinks he has. Granted, his MelonCard is a purely theoretical concept, but it's packed full of interesting ideas. Each MelonCard consists of a card-size piece of scratch-resistant glass attached to a thin plastic strip that contains all the electronics: flash memory, Bluetooth, and the battery. When you tap MelonCards together, accelerometers onboard automatically exchange digital info. My favorite feature of this concept device: "Users may also be silently notified if the person they are interacting with is someone they have met before to avoid embarrassing situations." Yeah, I think we all could have used that at some point.

Follow the Continue Reading jump for why the MelonCard will never work — and how the world should reinvent the business card for real.

The MelonCard is just a flight of photoshopped fancy and will most likely never get made. For starters, running on Bluetooth would be horribly power-hungry. And it would only work if everyone had one. But it points the way toward how contact information should be exchanged: quickly, digitally and with no trees dying whatsoever. Yes, I'm aware that there are no end to iPhone apps that do pretty much exactly what I've outlined, but if any of them were catching on I think I might have gotten someone offering to "beam me" his or her contact info at least once. So far, nada.

We need some kind of standard that's platform-agnostic and can be built into every kind of cellphone, made to "just work" automatically, and consumes very little power in the exchange. I'm not talking about texting .vcf files — still not convenient enough. Something closer to TransferJet is called for: I touch my cellphone to yours, and they both exchange info, automatically. And it has to be easy and cheap enough for everyone to use it. Any contenders?

I'm getting a little tired of the business card. Every time I meet a business contact, we exchange these tiny little paper calling cards. It seems so analog, so archaic in this digital age of cellphones and tablets and e-readers. Why hasn't someone created a way to exchange contact information digitally that works just as easily as handing over a slip of cardboard?

Designer Alan Sien Wei Hshieh thinks he has. Granted, his MelonCard is a purely theoretical concept, but it's packed full of interesting ideas. Each MelonCard consists of a card-size piece of scratch-resistant glass attached to a thin plastic strip that contains all the electronics: flash memory, Bluetooth, and the battery. When you tap MelonCards together, accelerometers onboard automatically exchange digital info. My favorite feature of this concept device: "Users may also be silently notified if the person they are interacting with is someone they have met before to avoid embarrassing situations." Yeah, I think we all could have used that at some point.

Follow the Continue Reading jump for why the MelonCard will never work — and how the world should reinvent the business card for real.

The MelonCard is just a flight of photoshopped fancy and will most likely never get made. For starters, running on Bluetooth would be horribly power-hungry. And it would only work if everyone had one. But it points the way toward how contact information should be exchanged: quickly, digitally and with no trees dying whatsoever. Yes, I'm aware that there are no end to iPhone apps that do pretty much exactly what I've outlined, but if any of them were catching on I think I might have gotten someone offering to "beam me" his or her contact info at least once. So far, nada.

We need some kind of standard that's platform-agnostic and can be built into every kind of cellphone, made to "just work" automatically, and consumes very little power in the exchange. I'm not talking about texting .vcf files — still not convenient enough. Something closer to TransferJet is called for: I touch my cellphone to yours, and they both exchange info, automatically. And it has to be easy and cheap enough for everyone to use it. Any contenders?

Missed SMB 2 vulnerability in Vista, but found it in time to fix Windows 7

Microsoft acknowledged Thursday that one of the critical network vulnerabilities it patched earlier in the week was due to a programming error on its part.

The flaw, one of 34 patched Tuesday in a massive security update, was in the code for SMB 2 (Server Message Block 2), a Microsoft-made network file- and print-sharing protocol that ships with Windows Vista, Windows 7 and Windows Server 2008.

"Look at the two array references to ValidateRoutines[] near the end," said Michael Howard, principal security program manager in Microsoft’s security engineering and communications group, referring to a code snippet he showed in a post to the Security Development Lifecycle (SDL) blog. "The array index to both is the wrong variable: pHeader->Command should be pWI->Command."

Howard, who is probably best known for co-authoring Writing Secure Code, went on to say that the error was not only in new code, but a "bug of concern."

The incorrect variable — "pHeader" instead of "pWI" — produced a vulnerability that Microsoft rated critical, its highest threat ranking. "An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights," read the MS09-050 security bulletin released Tuesday. Attackers could trigger the bug by sending a rigged SMB packet to an unpatched PC.

As he did in July when he admitted an extra "&" character in a Microsoft code library created a widespread vulnerability in most company software — and software crafted by third-party developers such as Sun, Cisco and Adobe — Howard argued that the SMB 2 mistake was virtually impossible to catch without a line-by-line review.

"There is only one current SDL requirement or recommendation that could potentially find this, and that is fuzz testing," said Howard. "The only other method that could find this kind of bug is very slow and painstaking code review. This code was peer-reviewed prior to check-in into Windows Vista; but the bug was missed. Humans are fallible, after all."

Fuzzing — subjecting software to a wide range of data input to see if, and where, it breaks — did uncover the bug "very late in the Windows 7 development process," Howard said. Although the preview versions of Windows 7 that Microsoft handed out to the public — both the beta from January 2009 and the release candidate posted in May — included the bug, Microsoft caught it in time to patch the RTM, or release to manufacturing, final code that will officially ship next Thursday.

The SMB 2 bug in question was not the one that Microsoft publicized last month in a security advisory. That vulnerability, which received attention because exploit code went public, also affected Windows 7 prior to the RTM build.

Howard also said that he thought Microsoft’s SDL process has handled the "low-hanging bugs" in the company’s code, leaving what he called "one-off bugs" that are difficult to detect using automated tools.

"The majority of the bugs I see in Windows are one-off bugs that can’t be found easily through static analysis or education, which leaves only manual code review, and for some bug classes, fuzz testing," he said. "But fuzz testing is hardly perfect."

Most analysts this week urged Windows users to put the MS09-050 patches on a high-priority list, if only because exploit code for one of the three SMB 2 vulnerabilities was public knowledge. Microsoft echoed that in its monthly deployment recommendations.

This month’s security updates, including MS09-050, can be downloaded and installed via the Microsoft Update and Windows Update services, as well as through Windows Server Update Services.

Missed SMB 2 vulnerability in Vista, but found it in time to fix Windows 7

Microsoft acknowledged Thursday that one of the critical network vulnerabilities it patched earlier in the week was due to a programming error on its part.

The flaw, one of 34 patched Tuesday in a massive security update, was in the code for SMB 2 (Server Message Block 2), a Microsoft-made network file- and print-sharing protocol that ships with Windows Vista, Windows 7 and Windows Server 2008.

"Look at the two array references to ValidateRoutines[] near the end," said Michael Howard, principal security program manager in Microsoft’s security engineering and communications group, referring to a code snippet he showed in a post to the Security Development Lifecycle (SDL) blog. "The array index to both is the wrong variable: pHeader->Command should be pWI->Command."

Howard, who is probably best known for co-authoring Writing Secure Code, went on to say that the error was not only in new code, but a "bug of concern."

The incorrect variable — "pHeader" instead of "pWI" — produced a vulnerability that Microsoft rated critical, its highest threat ranking. "An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights," read the MS09-050 security bulletin released Tuesday. Attackers could trigger the bug by sending a rigged SMB packet to an unpatched PC.

As he did in July when he admitted an extra "&" character in a Microsoft code library created a widespread vulnerability in most company software — and software crafted by third-party developers such as Sun, Cisco and Adobe — Howard argued that the SMB 2 mistake was virtually impossible to catch without a line-by-line review.

"There is only one current SDL requirement or recommendation that could potentially find this, and that is fuzz testing," said Howard. "The only other method that could find this kind of bug is very slow and painstaking code review. This code was peer-reviewed prior to check-in into Windows Vista; but the bug was missed. Humans are fallible, after all."

Fuzzing — subjecting software to a wide range of data input to see if, and where, it breaks — did uncover the bug "very late in the Windows 7 development process," Howard said. Although the preview versions of Windows 7 that Microsoft handed out to the public — both the beta from January 2009 and the release candidate posted in May — included the bug, Microsoft caught it in time to patch the RTM, or release to manufacturing, final code that will officially ship next Thursday.

The SMB 2 bug in question was not the one that Microsoft publicized last month in a security advisory. That vulnerability, which received attention because exploit code went public, also affected Windows 7 prior to the RTM build.

Howard also said that he thought Microsoft’s SDL process has handled the "low-hanging bugs" in the company’s code, leaving what he called "one-off bugs" that are difficult to detect using automated tools.

"The majority of the bugs I see in Windows are one-off bugs that can’t be found easily through static analysis or education, which leaves only manual code review, and for some bug classes, fuzz testing," he said. "But fuzz testing is hardly perfect."

Most analysts this week urged Windows users to put the MS09-050 patches on a high-priority list, if only because exploit code for one of the three SMB 2 vulnerabilities was public knowledge. Microsoft echoed that in its monthly deployment recommendations.

This month’s security updates, including MS09-050, can be downloaded and installed via the Microsoft Update and Windows Update services, as well as through Windows Server Update Services.

 Trying to figure out what’s causing a Windows STOP error (more commonly known as the Blue Screen of Death, or BSOD) can be a challenge. One likely candidate is bad hardware; if the error messages are random and the shutdowns appear unpredictably, you should suspect a faulty power supply or bad RAM.

Another common BSOD cause is a faulty device driver. Typically, you should be suspicious of any installed drivers that are not digitally signed, especially if they were written for an earlier version of Windows.

Windows XP includes a powerful troubleshooting tool called Driver Verifier (Verifier.exe). It’s a terrific way to identify flawed device drivers. It’s also a surefire way to screw up your system if you use it incorrectly. Read on for the details and important cautions.

 Driver Verifier works by testing each driver you specify at startup; if it finds a problem, it stops your computer predictably with a BSOD that accurately explains the true problem. Although this doesn’t sound like a huge improvement (your system still won’t work, after all), Driver Verifier performs a critical troubleshooting step: identifying the problem. You can then correct the problem by removing or replacing the offending driver. (If you’re satisfied that the driver really is OK despite Driver Verifier’s warning, you can turn off Driver Verifier for all drivers or for a specific driver. Any driver that Driver Verifier chokes on should be regarded with suspicion, but some legitimate drivers bend the rules without causing problems.)

Driver Verifier works at startup to thoroughly exercise each driver. It performs many of the same tests that are run by the Microsoft Windows Hardware Quality Labs as part of the certification and signing process, such as checking for the way the driver accesses memory.

Beware: If Driver Verifier finds a nonconforming driver – even one that doesn’t seem to be causing any problems – it will prevent your system from starting. If you use the advice in this article and have trouble starting your system, I won’t be able to help you. Use Driver Verifier only if you’re having problems. In other words, if it ain’t broke …

To enable Driver Verifier, click Start, Run. In the Open box, type verifier and press Enter. In the Driver Verifier Manager dialog box (shown here), select Create Standard Settings.

Click Next and select the type of drivers you want to verify. Because unsigned drivers are the most likely cause of problems, I recommend that you choose the default option: Automatically select unsigned drivers.

When you click Next, you get a list of all unsigned drivers on your system. Note that the list will contain some hardware drivers and some file-system filter drivers, such as those used by antivirus programs, CD burning software, and other low-level system utilities.

At this point you have two choices:

1. Go through the list and make a note of all drivers identified and then click Cancel. No changes are made to your system configuration; all you’ve done is gather a list of suspicious drivers, which you can then try to remove or disable manually.
2. Click Finish to complete the wizard and restart your computer. I DO NOT RECOMMEND THIS OPTION, for reasons that will become obvious with the remainder of this article. If you choose this option, don’t blame me if things get even messier than they already are.

Did you ignore my advice and choose Option #2 anyway? Fine. If your computer stops with a BSOD when you next log on, you’ve identified a problem driver. The error message includes the name of the offending driver and an error code. To resolve the problem, boot into Safe Mode (press F8 during startup) and disable or uninstall the problem driver. You’ll then want to check with the device vendor to get a working driver that you can install.

To disable Driver Verifier so that it no longer performs verification checks at startup, run Driver Verifier Manager again and select Delete Existing Settings in the initial dialog box.

Alternatively, click Start, then Run, and type verifier /reset in the Open box. (If you haven’t yet solved the driver problem, of course, you’ll be stopped at a BSOD, unable to disable Driver Verifier. In that case, boot into Safe Mode and then disable Driver Verifier.)

You can configure Driver Verifier so that it checks only certain drivers. To do that, open Driver Verifier Manager, select Create Standard Settings, click Next, and select the last option, Select driver names from a list. This option lets you exempt a particular driver from Driver Verifier’s scrutiny – such as one that Driver Verifier flags but you are certain is not the cause of your problem.

If you’re puzzled because you’re getting STOP errors (the Blue Screen of Death) and they scroll off your screen before you can read the details, here’s the solution:

 Trying to figure out what’s causing a Windows STOP error (more commonly known as the Blue Screen of Death, or BSOD) can be a challenge. One likely candidate is bad hardware; if the error messages are random and the shutdowns appear unpredictably, you should suspect a faulty power supply or bad RAM.

Another common BSOD cause is a faulty device driver. Typically, you should be suspicious of any installed drivers that are not digitally signed, especially if they were written for an earlier version of Windows.

Windows XP includes a powerful troubleshooting tool called Driver Verifier (Verifier.exe). It’s a terrific way to identify flawed device drivers. It’s also a surefire way to screw up your system if you use it incorrectly. Read on for the details and important cautions.

 Driver Verifier works by testing each driver you specify at startup; if it finds a problem, it stops your computer predictably with a BSOD that accurately explains the true problem. Although this doesn’t sound like a huge improvement (your system still won’t work, after all), Driver Verifier performs a critical troubleshooting step: identifying the problem. You can then correct the problem by removing or replacing the offending driver. (If you’re satisfied that the driver really is OK despite Driver Verifier’s warning, you can turn off Driver Verifier for all drivers or for a specific driver. Any driver that Driver Verifier chokes on should be regarded with suspicion, but some legitimate drivers bend the rules without causing problems.)

Driver Verifier works at startup to thoroughly exercise each driver. It performs many of the same tests that are run by the Microsoft Windows Hardware Quality Labs as part of the certification and signing process, such as checking for the way the driver accesses memory.

Beware: If Driver Verifier finds a nonconforming driver – even one that doesn’t seem to be causing any problems – it will prevent your system from starting. If you use the advice in this article and have trouble starting your system, I won’t be able to help you. Use Driver Verifier only if you’re having problems. In other words, if it ain’t broke …

To enable Driver Verifier, click Start, Run. In the Open box, type verifier and press Enter. In the Driver Verifier Manager dialog box (shown here), select Create Standard Settings.

Click Next and select the type of drivers you want to verify. Because unsigned drivers are the most likely cause of problems, I recommend that you choose the default option: Automatically select unsigned drivers.

When you click Next, you get a list of all unsigned drivers on your system. Note that the list will contain some hardware drivers and some file-system filter drivers, such as those used by antivirus programs, CD burning software, and other low-level system utilities.

At this point you have two choices:

1. Go through the list and make a note of all drivers identified and then click Cancel. No changes are made to your system configuration; all you’ve done is gather a list of suspicious drivers, which you can then try to remove or disable manually.
2. Click Finish to complete the wizard and restart your computer. I DO NOT RECOMMEND THIS OPTION, for reasons that will become obvious with the remainder of this article. If you choose this option, don’t blame me if things get even messier than they already are.

Did you ignore my advice and choose Option #2 anyway? Fine. If your computer stops with a BSOD when you next log on, you’ve identified a problem driver. The error message includes the name of the offending driver and an error code. To resolve the problem, boot into Safe Mode (press F8 during startup) and disable or uninstall the problem driver. You’ll then want to check with the device vendor to get a working driver that you can install.

To disable Driver Verifier so that it no longer performs verification checks at startup, run Driver Verifier Manager again and select Delete Existing Settings in the initial dialog box.

Alternatively, click Start, then Run, and type verifier /reset in the Open box. (If you haven’t yet solved the driver problem, of course, you’ll be stopped at a BSOD, unable to disable Driver Verifier. In that case, boot into Safe Mode and then disable Driver Verifier.)

You can configure Driver Verifier so that it checks only certain drivers. To do that, open Driver Verifier Manager, select Create Standard Settings, click Next, and select the last option, Select driver names from a list. This option lets you exempt a particular driver from Driver Verifier’s scrutiny – such as one that Driver Verifier flags but you are certain is not the cause of your problem.