How to detect a page request from Safari 4's Top Sites feature | Hacker News Reader

How to detect a page request from Safari 4's Top Sites feature

sunpig.com

65 pointsmattking12 comments

More importantly, Google might consider this cloaking, and come round your house in the middle of the night with a baseball bat.

No, they won't. Google's definition of cloaking is serving different results to Googlebot versus end-users.

For one thing, neither nor GoogleBot nor the remote quality raters will be sending Safari-specific headers for discovery/evaluation tasks, so they won't see the preview at all. For another, this falls into the (sort of) nebulous category of "cloaking designed to enhance the user experience", which is almost always kosher.

Similar examples: you can auto-detect someone's region/language/browser/etc and customize the page to fit their needs, and Google is pretty much OK with that as long as you treat Googlebot the same way.

This vaguely reminds me of that (was it Internet Explorer?) plugin/extension that tried to detect phishing sites by prefetching all the links on a page. There was a big uproar with admins and there was an apache rewrite rule floating around to detect the user-agent and block these requests.

I can't remember the name of this, though, so I'm having trouble searching for it. Maybe 2006 or 2007 was the time?

You're sure you're not thinking of Google's Web Accelerator? It wasn't made to prevent phishing, but to speed up browsing, but it caused the problems you describe.

http://en.wikipedia.org/wiki/Google_Web_Accelerator

I am sure I am not thinking of GWA. I want to say it was installed somewhat implicitly as part of some virus checking software that people didn't really ask for.

This was AVG antivirus link checker

Ah, that it was, that's what I was thinking of. Thanks.

http://en.wikipedia.org/wiki/AVG_(software)#Concerns

That's actually really useful info. If someone visits your site enough to be in their top sites, it's probably a sign that they like it a lot.

Back in the day when IE first implemented favicon.ico, it was common to track your logs for favicon.ico loads since they'd only be loaded when someone added your site to their Favorites. Sadly that doesn't work anymore :-(

One useful way to take advantage of this might be to just serve your site at a lower resolution if the HTTP header is defined to reduce bandwidth use. If you're using 500px wide banner images on a 1000px grid, size that down for the Safari preview but scale everything so that it's still representative of your site.

One would think that the time it would take to implement that would be far more than could ever be conceivably saved by bandwidth reductions, except for perhaps the very largest sites.

I can't wait until this becomes more popular. Then I can send this header and avoid tracking + ads without any additional software.

I think this is an awesome idea. It's like a bigger favicon that's actually useful.

Reply on news.ycombinator.com