The temptation to quit…

Great post from GoDaddy.com’s Bob Parsons on startup lessons he’s learned:

The Temptation to Quit… Parking Cars for a Living

Advertisements

How Not To Deface a Phishing Site

My job developing anti-phishing software is an almost constant source of amusement. Clueless phishers provide the most enjoyment, but sometimes we see clueless vigilantes.

DefaceHere’s a screenshot of a PayPal spoof that looks like its been defaced by a vigilante or sysadmin. Most defacers will warn users and disable the phishing site so it can’t hurt anyone. In this case, the defacer just posted a warning (at the top, and also gives a phone number to call in case anyone wants to help catch the phisher) but then he/she leaves the site intact, so it can still swipe user credentials. That’s like finding a hole in road that someone could fall into and only putting up a warning sign – fill in the hole with dirt too!

So here’s defacing-a-phishing-site law #1: when defacing a phishing site, make sure you break it so no one can get hurt.

Microsoft Responds to IE7 Tabs Post

Bruce Morgan, dev manager for the IE tabbed browsing team, commented on my original post on IE7 tabs – thanks Bruce! His comment provides more depth into why MS chose the each-tab-gets-its-own-toolbars route. In short – appcompat weight heaviest in making the decision, and 3rd party toolbars will indeed require extra UI space. Just so no one misses it (buried at the bottom of the comments of the previous post), here’s the comment:

Adam, I want to explain more about why we chose the thread-per-tab, toolbar instance-per-tab approach we did for IE7.

Adam and I know each other a little bit. For other readers – I’m the dev manager for the IE feature team that owns tabbed browsing in IE7.

We researched several other approaches, and we ultimately preferred the multiple thread, toolbar-per-tab as the right balance of appcompat and stability vs. memory use. Remember that we’re retrofitting multiple tabs into a browser that wasn’t designed that way, and we want it to work out-of-the-box with 3rd party toolbars that weren’t designed to work with tabs.

Our testing showed that if we went with a single thread for all tabs in a window, we would encounter many more UI stalls and jerkiness – too many things both in our code and common 3rd party code block on various things like network activity. So the foreground tab scrolling would stall for a moment, or the whole frame would hang for several seconds while a background tab loaded some docobject, and the like. Not good.

We looked at other approaches for implementing toolbars that weren’t instance-per-tab, but they all had much bigger appcompat issues. Ultimately we felt we needed this approach for the best possible appcompat. Even so, some toolbars won’t work with IE7 and will need to be fixed. But we hope the fixes will be minor.

We certainly didn’t do it this way to save time. Back when we were deciding the implementation, the thread-per-tab approach was estimated to be significantly more expensive than any other approach we considered.

Obviously third party toolbars that handle many top level windows well will work well with IE7’s tabs, and ones that don’t handle lots of windows won’t handle lots of tabs any better.

As for UI space, yes, third party toolbars are currently located below the tabs and can’t be moved above them. Another tradeoff.

Phishing through Google

As a follow up to Phishing eBay through Doubleclick, here’s an example of a Union Planters spoof linked through Google.

The URL bounces through Google (who could probably tell us how many users have clicked it) and lands on the spoof site:

This isn’t quite as dangerous as the eBay/Doubleclick redirects mentioned above, but Google’s redirecting could make it easier for someone to phish Google adwords accounts in the future.

Printing the Beta Ruby on Rails Book

Railsbook I was one of the over 1000 people who bought the beta version of the new Agile Web Development with Rails book by Dave Thomas and David Heinemeier Hansson. I bought the combo pack, which means I got PDF of the beta version now and I’ll get a print version when its ships in July.

I’ve been developing web apps for almost 10 years (WinCGI, Cold Fusion back in the DBML days, ASP, ASP.NET, PHP, etc), and Rails is easily the most intriguing and exciting technology I’ve come across in a long time. The Rails framework takes away much of the repetitive drudgery you often run into in web app development. The learning curve doesn’t seem too (though I’m still in the Ruby-is-a weird-looking-language stage) and the Rails book should help in that area too.

I didn’t want to read a 500+ page book on the computer though, and also didn’t want to burn out my laser printer, so I used Kinkos Online Ordering system. Its slick – you upload the PDF to them and pick up your print copy a couple of hours later at your local store. I wish all my books could be spiral bound!