Even if you could pull it off technically, and I'd be very interested if you did, considering that the most insecure browser out there, is also the most commonly used. Ditto for OS. If all you're concerned about is client image(which from the tone seems to be the case), then you could simply exclude MSIE, by rejecting it's UserAgent, or checking with JS for document.all, or window.ActiveXObject, or some other MSIE specific object - sorry I'm not a JS programmer. On 6/21/05, Chris W. Parker <cparker@xxxxxxxxxxxx> wrote: > bruce <mailto:bedouglas@xxxxxxxxxxxxx> > on Tuesday, June 21, 2005 1:38 PM said: > > > what you state is true at the extreme... but in the case of an client > > app, i could already extract information about the various apps that > > make up the client.. ie if, as in the case of IE, I was able to get > > information from the IE browser about various dlls that make up the > > browser. if these pieces of information correclt match what msoft > > would state should be there, then i could assume that the app was/is > > legitimate. > > Ok sure. But what you're not considering is that a malicious program > could STILL intercept the request for identification from the server and > send whatever information it wanted to, ultimately fooling your > identification system. Your server could never know the difference. > There's no way you, on the server end, could tell whether or not it was > a malicious program answering your questions or a legitimate program > answering your questions. > > (This question is not supposed to be rude or sarcastic.) Have you ever > heard of a rootkit? Consider the way a rootkit works in this situation. > A rootkit hides itself from the user and the system so much so that it > is undetectable while the OS (and itself) are loaded. The way to detect > a rootkit is by scanning the system during a regular boot and then > scanning the system again before the OS has had the chance to load the > rootkit into memory. If there is a difference between the two scans, > you're likely infected. > > In fact a rootkit can take it one step further by knowing that a scan is > being performed and return false information to the scanner so that when > the next scan is performed (before the rootkit is loaded) it'll look as > if nothing is going wrong. > > Now how do you expect to determine that remotely? > > > you're correct in stating that the existing methods don't permit this > > kind of transactions to occur. however, i'm of the believe that over > > time, they will. > > I don't doubt that. But irregardless of this you're still not in the > position to determine whether or not the information you are receiving > is accurate. Ultimately you will have to trust that the information you > are receiving is accurate and valid. The methods by which your server is > fooled will increase along with the methods for accurately reporting the > client's configuration is increased. > > > and here's why. while you may not give a damm, there will be a > > growing chorus of people who'll want to know that the > > developers/sites are doing everything they can to ensure the safety > > of the entire transaction. in fact, i'm willing to bet that somehting > > like what i've been discussing will be delivered, and promoted as a > > security/selling point... > > I don't doubt this either. People will continue to blame everyone but > themself until they are blue in the face. If people really want change > they should put pressure on the manufacturer not the people providing > services. I.e. People should stop buying Windows and move to another OS > (until it's time to move away from that OS as well) until Microsoft gets > it's act together. MS would have put out Windows 2020 a year ago if all > of a sudden all their customers stopped purchasing their products. > They'd get the picture for sure. All of MS's efforts would be put into > making their product rock solid and not in adding feature after feature. > > > Respectfully, > Chris. > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
