An important thing to note about the Phishing Filter check is that the information sent to Microsoft is limited to just the web address of the web site. Information associated with the web site address that could contain personal or sensitive information such as search terms you may have entered is removed before the address information is sent to Microsoft.
Another important point to remember is that the URL is transmitted using SSL (Secure Socket Layer) encryption. This is the same encryption used by banks, financial institutions and other organizations to protect their users’ data.
I wanted to test this myself so I setup a packet capturing application and submitted this blog using a URL that contained extra bits of potentially important, private information at the end of the URL.
But as is stated in the quote above, the entire transaction takes place over SSL. So all I could see was my machine talking with 18.104.22.168 which is one of many IPs owned by Microsoft.
If I could decipher the transaction I suspect that what I would see is a url like:
is submitted to Microsoft as:
but I can’t be certain. Is this a problem? In most cases, probably not. What might worry me is that if the full URL (sans CGI query string and username/password) might still contain information. For example, how does Microsoft know where the URL ends and the query string begins? Usually you can go by the question mark (?) if there is one. But there’s also the ability to use forward slashes to separate URL and query string. So something like:
http://weblog.bridgew.edu/ruthsarian/post/username/password/id/ might be itnerpreted as a full URL and not a URL up to the “ruthsarian” part where everything after that is the query string.
And it wouldn’t be an intentional bug on MS’s part, it’s just that some web applications intentionally try to obfuscate the query string from the path to the requested page. But it’s over SSL, so only you and Microsoft would know what got through, if anything.
Still, I’ll be keeping my phishing filter off.