| Date: | March 6, 2006 / year-entry #82 |
| Tags: | other |
| 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)
Comments are closed. |
First link doesn’t work.
Did Peter take the post down?
I don’t know what happened to Peter… looks like everything after August 2005 vanished…
"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.
Hmmmm……
<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>
Oops need to update the Suggestion Box blurb. blogs.msdn.com runs Community Server now. (So Scott’s still on the hook!)
Maybe the page has suffered from the TONT effect lol
Still an interesting 2nd link though
I found the first article: http://blogs.msdn.com/ptorr/archive/2005/09/12/464376.aspx
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.
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.
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.
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.
Example:
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.
*gaah!*
*smash* *smash* *smash*
Hurray for Google Cache: http://64.233.179.104/search?q=cache:6icWtDXO9tYJ:blogs.msdn.com/ptorr/archive/2005/09/12/464376.aspx&hl=en&gl=au&ct=clnk&cd=1
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.
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!
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?
If TinyURL starts becoming a phishing tool then they (TinyURL) would need to do something about it.
This link seems to work: http://blogs.msdn.com/452453.aspx
(it can be found at one of the comments to the post itself)
(sorry, ignore the link I just posted, it went to a different story)
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).
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!
Cheong — they can still use TinyURL (or equivalent) for phishing, even with the IE7 "filter".
The structure of a TinyURL link is:
http://tinyurl.com/xxxxxx
(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.)
"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.