Other things happen for a reason, too

Date:March 6, 2006 / year-entry #82
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20060306-13/?p=32043
Comments:    23
Summary:Today's theme is a quick one: Other Microsofties explain what at first appear to be puzzling decisions. Peter Torr explains why the anti-phishing filter operates on the original URL instead of a hash. Jamie Buckley from the MSN Search team explains why not every possible instant answer is offered.

Today's theme is a quick one: Other Microsofties explain what at first appear to be puzzling decisions.

Comments (23)
  1. Dr Pizza says:

    First link doesn’t work.

  2. Did Peter take the post down?

  3. I don’t know what happened to Peter… looks like everything after August 2005 vanished…

  4. "Is there a blogs.msdn.com admin blog that I could direct this to?"

    See the Suggestion Box for instructions on how to contact the people who wrote the blog server software.

  5. Adam says:


    <i>Before writing, please note, I no longer support .Text. I recommend all .Text users upgrade to Community Server which is a much more robust, stable, usable, and documented product.</i>

  6. Oops need to update the Suggestion Box blurb. blogs.msdn.com runs Community Server now. (So Scott’s still on the hook!)

  7. 8 says:

    Maybe the page has suffered from the TONT effect lol

    Still an interesting 2nd link though

  8. Microsoft isn’t in charge of this site’s operations. The site software comes from Telligent and the hosting is provided by another web hosting company.

  9. silkio says:

    It’s no loss to see a "Peter Torr" post disappear, he is a complete fool. The world is a smarter place with it gone.

  10. Dave says:

    Raymond, perhaps you could point out to someone who pays the Telligent bills that they are making Microsoft and its technology look bad.

    Silkio, I have followed Peter Torr’s blog and Usenet postings for years and learned a lot from them. Even now when I’m searching for scripting information I often come across his earlier work, and it’s still useful.

  11. Adam says:

    Don’t know about that, but the way the error page does a redirect, losing the URL you were originally going to is *really* annoying.

    Needlessly breaking the reload button – not clever.

    (Raymond, I realise that this isn’t your fault, and not something you can do anything about, but it keeps happening and I feel like I need to mention it *somewhere*. Is there a blogs.msdn.com admin blog that I could direct this to?)

    The behaviour is especially annoying for transient errors (which I get one of every couple of days ago from b.m.c) which should be fixable by hitting reload.

    Instead, I have to close the tab with the error in it, find the tab that I loaded the link from, find the link that didn’t open, and re-select it. If it was an article from a page with a lot of interesting links, such as the b.m.c homepage, then I have to read the whole page again, and look for a link that looks interesting, but which I’ve not yet read, but isn’t in the set of tabs which I’ve not got to yet (which I’ve also not read yet).

    If I’ve closed the source tab down already (which is normal – I often read one page, opening all interesting links in background tabs as I go, and when I get to the end of the page, close that tab and start reading the next tab, etc…) then it can get *more* frustrating as I don’t necessarily know which page the page I now can’t read was linked *from*, making it completely impossible to find.


    Load b.m.c homepage. Open interesting-sounding articles in background tabs. Close b.m.c homepage.

    Read first interesting article from b.m.c by, say, LarryOsterman. Open interesting links in background tabs. Close Larry Tab.

    Read second interesting article from b.m.c – this one. Open interesting-sounding articles linked to in background tabs. Finish article + close tab.

    Read next article, etc… At some point, I finish reading articles linked to from b.m.c home, and start reading articles linked to by articles linked to by b.m.c home.

    Come across broken page. It was obviously interesting, otherwise I wouldn’t have linked to it. But now I have no idea what page it was, or where I got to it from.


    *smash* *smash* *smash*

  12. Cheong says:

    For the subject of Jamie Buckley’s link, I think tags like "stock:play" will do.

    Just like if I want to search in Micorosft’s websites, I place a "site:microsoft.com" tag after the search phrase.

  13. Cheong says:

    And for Peter Torr’s blog:

    Now I begin to think how people would have abused URL shortening services like tinyurl.com for phishing.

    They could have used automated script to get a new URL to every email they send!

  14. Dave says:

    Okay, this thread has wondered hopelessly off topic so I’ll continue the trend.

    How can a Microsoft blog site be dysfunctional for hours and not get fixed? If things happen for a reason, what is the reason for an extended outage? The page reports that the appropriate authorities have been notified yet it’s still broken.

    In an earlier entry, Peter Torr mentions that his blog got slashdotted. MSDN’s ASP.NET blog software can’t handle a good slashdotting? I run a database-heavy Classic-ASP site that has been slashdotted several times and usually I don’t notice anything until looking at the traffic logs the next day.

    Is it unfair to judge a company’s own technology by the success *they* have in using it?

  15. If TinyURL starts becoming a phishing tool then they (TinyURL) would need to do something about it.

  16. Cesar Eduardo Barros says:

    This link seems to work: http://blogs.msdn.com/452453.aspx

    (it can be found at one of the comments to the post itself)

  17. Cesar Eduardo Barros says:

    (sorry, ignore the link I just posted, it went to a different story)

  18. BryanK says:

    Eric: that’s true, come to think of it.  Assuming Microsoft makes it work that way; I hope it’s obvious that that’s the Right Way to do it.

    There’s still the problem of the average phishing site being up for only 2.X days, though (as one of the commenters on the Google cache version of ptorr’s post said).  It’s going to be terribly difficult to make this have any real impact, when on average the site will be gone before anyone at Microsoft has a chance to look at it.  (Plus if you use this feature, you’re betting that Microsoft never discontinues the URL-checking team.  That bet doesn’t sound like a good one to me, but maybe that’s just me.  OTOH, I remember what happened not too long after IE6 was released…  how many years has it been now?)

    I still think that some kind of AI applied to the content of the site would be a much better filter than manually checking URLs (for the same reason Bayesian filtering works better for spam than both hashing the message and blacklisting lists of source IPs).

  19. I never knew my posts were not available… I need to start posting again, anyway. Thanks for the (indirect) heads-up!

    BryanK: We have heuristics as well, but they are not fool-proof

    Dave: Thanks; glad to be of service :)

    Silkio: Ha ha! I am not dead!

  20. BryanK says:

    Cheong — they can still use TinyURL (or equivalent) for phishing, even with the IE7 "filter".

    The structure of a TinyURL link is:


    (where the xxxxxx depends on the target URL only).  If you give TinyURL a whole host of target URLs (one for each email, containing either unique query-string variables, or unique path components, or whatever), and send out the emails with the TinyURL link instead of the real link, *there’s nothing IE7 can filter on*.

    Microsoft had better not block all TinyURL URLs, unless they enjoy being prosecuted.  (But the DNS name is the only common part of the phishing URLs.)  And if they block any individual TinyURL URL(s), that will only help the one person that reported the URL to them, not anyone else.

    Blacklisting is the WRONG solution to the phishing problem.  Content filtering (grab the target page, follow any redirects, and process it with something like a Bayesian filter) is better; making it unprofitable for the phishers (e.g. by filtering out phishing emails for the users, and not even letting them see them) is best.

    (Yes, I know, I should tell the IE people that.  But do you really think they’ll listen?  I very much doubt it.)

  21. Eric says:

    "If you give TinyURL a whole host of target URLs (one for each email, containing either unique query-string variables, or unique path components, or whatever), and send out the emails with the TinyURL link instead of the real link, *there’s nothing IE7 can filter on*."

    Sure there is. TinyURL just issues an HTTP redirect — which the browser handles. I presume IE7 will be checking the URL for a redirect, in which case it would catch the "real" phishing URL.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index