This process was developed/implemented by HexView a few years ago (I worked for them at that time):
Whoever finds the vulnerability likely has enough knowledge to roughly estimate what it takes to fix it and test the fix. He/she supplies all details to the vendor and gives them a hard time frame, e.g.: "I will release this data to the public 30 days from now". At the same time, vulnerability alert without details to prevent/delay re-discovery may be released to the public. If the vendor fails to resolve the vulnerability in a timely manner -- too bad, you were given enough time for fixing and testing.
Before you sign up, read GrandCentral's terms and conditions. I'd suggest using Xebba instead. They are not completely free, but they specifically mention that they do not record calls and do not harvest anything from your conversations.
There is a catch-22 -- you either have compatibility , but key management is handled by the HDD, or you have security, but you need external software and BIOS integration. I bet, Fujitsu decided to go with the compatibility. In this case, the encryption key could be recoverable.
HexView published an
advisory about it back in 2006.
Moreover, this technique was already covered on/. and it looks like it inspired Mr. Kirsch so much that he decided to plagiarize it without even mentioning the source. I smell a lawsuit here.:)
Dude, get yourself a couple of beers and stop wasting your time. 90% of ghost calls you receive are VoIP. Spoofing caller ID is trivial in VoIP environment. You don't have to be a telemarketer to do it. There are services like http://www.grandcentral.com/ (where google will collects samples of your voice) or http://www.xebba.com/ where you can get free 800 or local number and call anywhere anonymously for a couple of cents per minute.
Unless you're whitelisting your calls (which comes with a risk of losing an important one), your application, whocalled.us, or anything else that relies on caller id is not going to stop telemarketers. Oh, and by the way, they have a fleet of programmers with substantially better telephony skills that yours.
All I can say - good luck with that. I did this in 1995 for CHD (coronary heart disease) patients. We analyzed 5-years of data for ~2500 patients in order to identify the best suitable treatment. It did not go very well - factor analysis revealed too many variables and although we identified several trends and patterns, they were inconsistent and unlikely suitable to be used clinically.
iDefense ask you to provide all your background information, names, addressess, telephones, photocopies of IDs, etc. Most people who can find vulnerabilities will not be willing to sacrifice their privacy. When iDefence and alike will only ask for e-mail address to paypal funds to, I'd be first in line to talk to them.
Slashdot Mirror
This process was developed/implemented by HexView a few years ago (I worked for them at that time): Whoever finds the vulnerability likely has enough knowledge to roughly estimate what it takes to fix it and test the fix. He/she supplies all details to the vendor and gives them a hard time frame, e.g.: "I will release this data to the public 30 days from now". At the same time, vulnerability alert without details to prevent/delay re-discovery may be released to the public. If the vendor fails to resolve the vulnerability in a timely manner -- too bad, you were given enough time for fixing and testing.
Before you sign up, read GrandCentral's terms and conditions. I'd suggest using Xebba instead. They are not completely free, but they specifically mention that they do not record calls and do not harvest anything from your conversations.
There is a catch-22 -- you either have compatibility , but key management is handled by the HDD, or you have security, but you need external software and BIOS integration. I bet, Fujitsu decided to go with the compatibility. In this case, the encryption key could be recoverable. HexView published an advisory about it back in 2006.
Moreover, as out ion-beam reflection tests determined, it rests on 6 elephants, not 5 as we previously thought. :) /AD
Moreover, this technique was already covered on /. and it looks like it inspired Mr. Kirsch so much that he decided to plagiarize it without even mentioning the source. I smell a lawsuit here. :)
This (or similar) bug was reported by HexView in 2005 and they also received no word from MS. http://www.hexview.com/docs/20050331-1.txt
Dude, get yourself a couple of beers and stop wasting your time. 90% of ghost calls you receive are VoIP. Spoofing caller ID is trivial in VoIP environment. You don't have to be a telemarketer to do it. There are services like http://www.grandcentral.com/ (where google will collects samples of your voice) or http://www.xebba.com/ where you can get free 800 or local number and call anywhere anonymously for a couple of cents per minute.
Unless you're whitelisting your calls (which comes with a risk of losing an important one), your application, whocalled.us, or anything else that relies on caller id is not going to stop telemarketers. Oh, and by the way, they have a fleet of programmers with substantially better telephony skills that yours.
All I can say - good luck with that. I did this in 1995 for CHD (coronary heart disease) patients. We analyzed 5-years of data for ~2500 patients in order to identify the best suitable treatment. It did not go very well - factor analysis revealed too many variables and although we identified several trends and patterns, they were inconsistent and unlikely suitable to be used clinically.
iDefense ask you to provide all your background information, names, addressess, telephones, photocopies of IDs, etc. Most people who can find vulnerabilities will not be willing to sacrifice their privacy. When iDefence and alike will only ask for e-mail address to paypal funds to, I'd be first in line to talk to them.