The book has already had its few months in paper-only format, and is available to download (along with a number of other books in the series) at
InformIT
This is a really interesting development, and best of luck to these guys. But this quote from the article: "The engine burned for 40 seconds, zipping to Mach 2, or two times the speed of sound, according to a source that witnessed the test flight high above Mojave, California skies." is a little wierd. An unnamed source, who is just credited as a "witness" doesn't sound like the right person to make these sorts of claims.
This is why I maintain a Rhapsody subscription at the same time as buying a bunch of music from iTunes. I can listen to streaming music with my Rhapsody subscription, which saves me at least one poor album purchase every month, and then only buy the albums that are actually worth it.
I subscribe to Liverpool Football Club's liverpoolfc.tv service that provides live streaming audio of all of Liverpool's football (soccer) matches. Based on "user complaints", they switched to Windows Media streaming audio feeds from Real Audio for the first time this weekend. If user comments are any indication, this was a complete failure. Admittedly this was the first major test, but the performance was extremely poor, the audio cut out frequently and the quality of the feed was much poorer than I'm used to.
I hate the Real bundle-of-everything-I-don't-want-with-the-one-thi ng-I-do software packaging as much as the next person, but I think its well worth it for the superior experience you now get with it. And the improvements since Real 6.0 with its leak-buckets-of-memory-and-crash-Windows issues is significant.
Maybe its a difference in the way our corporate VPN infrastructure works. But we associate our VPN client with a personal firewall, so that when you're VPN-ed in, ALL data flows the VPN to the corporate network before getting out to the internet. So your POP3 password is securely transmitted (over the IPSec tunnel) to the inside, and then goes out from there. Similarly web broswing goes inside, then through our corporate proxy server and then outside.
But if thats not the case with your implementation, then I agree that VPN alone is not a solution for HotSpots and the like. What really bothers me is when companies try to use these new security protocols for in-building wireless. In those cases, the VPN should be the right answer.
One of the most common methods of protecting a WLAN, that I think is ignored by most people and this text, is not protecting it much at all, but restricting the use so that its unusable for anyone other than an authorized user.
You turn on WAP or MAC-Address filtering to make it inconvinient to attach (though since both of these are vulnerable, this is not enough security in itself). Then you only allow access from the WLAN to your corporate VPN servers. Most machines (laptops) that make use of this will already be equipped for corporate VPN access, and so you rely on the security of your VPN in an unsecured (or relatively unsecure) network. Why are we working on all sorts of new standards when a simple combination of available standards will do just as well? Its not like using Radius auth (via SecureID or password) to your VPN is any harder for the user than any of the other suggestions coming out. Truthfully, its easier for IT since you don't have to build new security infrastructure, and you don't have to retrain users.
What he's trying to claim, rightly or wrongly is that we don't need to be worried about vulnerabilities. Not because they don't exist, but because by the time the people exploit them find them, there is already a patch available.
What he's ignoring is that Microsoft doesn't find the vulnerabilities. They're generally found by consultants at security firms, or other white hats. But it doesn't make me feel particularly secure to know that if eEye (that found the ASN.1 vulnerability) had fired an employee who harboured a grudge in August, that employee would have known the vulnerability and been able to exploit virtually every Windows machine accessible. They're relying on the people who find these vulnerabilities being "kind" enough to supress their details until a patch is available, even as they're taking months on occasion to create the patch.
Actually, they're pretty damn close.
"Donate money to my reelection campaign and I'll give you government subsidies, federal contracts and favorable laws" doesn't sound much better than "Donate money to my Cayman Islands bank account and I'll give you a federal contract, tax break, and friendly laws".
Actually, I prefer the bribery approach. At least then its under the table, and not quite (almost, but not quite) as blatant.
One thing I look for is a mature API - I want to know that if you upgrade your tools, I don't have to choose between an old unsupported version or a complete rewrite. It means putting a lot of thought into future directions when you write your initial API. It will of course change when you add more stuff in the future, but if I see something that completely changes its APIs between two minor releases, chances are I'll find something else.
Slashdot Mirror
The 5450. The 5550 was the update of that device with WM2003.
The book has already had its few months in paper-only format, and is available to download (along with a number of other books in the series) at InformIT
This is a really interesting development, and best of luck to these guys. But this quote from the article: "The engine burned for 40 seconds, zipping to Mach 2, or two times the speed of sound, according to a source that witnessed the test flight high above Mojave, California skies." is a little wierd. An unnamed source, who is just credited as a "witness" doesn't sound like the right person to make these sorts of claims.
This is why I maintain a Rhapsody subscription at the same time as buying a bunch of music from iTunes. I can listen to streaming music with my Rhapsody subscription, which saves me at least one poor album purchase every month, and then only buy the albums that are actually worth it.
I subscribe to Liverpool Football Club's liverpoolfc.tv service that provides live streaming audio of all of Liverpool's football (soccer) matches. Based on "user complaints", they switched to Windows Media streaming audio feeds from Real Audio for the first time this weekend. If user comments are any indication, this was a complete failure. Admittedly this was the first major test, but the performance was extremely poor, the audio cut out frequently and the quality of the feed was much poorer than I'm used to.i ng-I-do software packaging as much as the next person, but I think its well worth it for the superior experience you now get with it. And the improvements since Real 6.0 with its leak-buckets-of-memory-and-crash-Windows issues is significant.
I hate the Real bundle-of-everything-I-don't-want-with-the-one-th
Maybe its a difference in the way our corporate VPN infrastructure works. But we associate our VPN client with a personal firewall, so that when you're VPN-ed in, ALL data flows the VPN to the corporate network before getting out to the internet. So your POP3 password is securely transmitted (over the IPSec tunnel) to the inside, and then goes out from there. Similarly web broswing goes inside, then through our corporate proxy server and then outside. But if thats not the case with your implementation, then I agree that VPN alone is not a solution for HotSpots and the like. What really bothers me is when companies try to use these new security protocols for in-building wireless. In those cases, the VPN should be the right answer.
One of the most common methods of protecting a WLAN, that I think is ignored by most people and this text, is not protecting it much at all, but restricting the use so that its unusable for anyone other than an authorized user. You turn on WAP or MAC-Address filtering to make it inconvinient to attach (though since both of these are vulnerable, this is not enough security in itself). Then you only allow access from the WLAN to your corporate VPN servers. Most machines (laptops) that make use of this will already be equipped for corporate VPN access, and so you rely on the security of your VPN in an unsecured (or relatively unsecure) network. Why are we working on all sorts of new standards when a simple combination of available standards will do just as well? Its not like using Radius auth (via SecureID or password) to your VPN is any harder for the user than any of the other suggestions coming out. Truthfully, its easier for IT since you don't have to build new security infrastructure, and you don't have to retrain users.
What he's trying to claim, rightly or wrongly is that we don't need to be worried about vulnerabilities. Not because they don't exist, but because by the time the people exploit them find them, there is already a patch available.
What he's ignoring is that Microsoft doesn't find the vulnerabilities. They're generally found by consultants at security firms, or other white hats. But it doesn't make me feel particularly secure to know that if eEye (that found the ASN.1 vulnerability) had fired an employee who harboured a grudge in August, that employee would have known the vulnerability and been able to exploit virtually every Windows machine accessible. They're relying on the people who find these vulnerabilities being "kind" enough to supress their details until a patch is available, even as they're taking months on occasion to create the patch.
Actually, they're pretty damn close. "Donate money to my reelection campaign and I'll give you government subsidies, federal contracts and favorable laws" doesn't sound much better than "Donate money to my Cayman Islands bank account and I'll give you a federal contract, tax break, and friendly laws". Actually, I prefer the bribery approach. At least then its under the table, and not quite (almost, but not quite) as blatant.
Jackass.
One thing I look for is a mature API - I want to know that if you upgrade your tools, I don't have to choose between an old unsupported version or a complete rewrite. It means putting a lot of thought into future directions when you write your initial API. It will of course change when you add more stuff in the future, but if I see something that completely changes its APIs between two minor releases, chances are I'll find something else.