Moving on from IE 6 in 2010. Google no longer supporting IE 6

I got another awesome letter from Google today I thought I should share with the world, because it means thing will be changing for the good in 2010.

Google has officially announced it will not be support IE 6 browsers on a few of their major services, such as Google Apps (letter below), YouTube and Gmail.

Dear Google Apps admin,

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser.  We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience.  We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,

The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

I feel like this movement has been long awaiting the support of a giant such as Google to back it. Microsoft has not supported or even accepted any responsibility for the IE 6 browser quite some time and it is non-sense to continue to apply hacks and work-arounds to perfectly legitimate website code to support it.

However, as website developers and owners, I also believe we should make the initiative to instruct our visitors using IE 6 that they need to change their software before we just cut them off completely. Implementing User Agent detection and displaying messages to these users on every page they view might be a good start. Offering them their choice of downloading IE 8, Firefox 3.6, Safari 4 or Google Chrome 2 would also be a great way to encourage them to upgrade.

Securing Website Forms with and without CAPTCHA

There are means to block automated or remote submission of the website forms. Having an unsecured form these days is just asking for a few hundred junk emails a week if not more. There are about 4-5 decent ways of blocking SPAM and potential “hacker” or intrusive programs from abusing our forms:

1. The most elegant in my opinion and definitely the least annoying to users, but not a completely secure or “perfect” solution is currently referred to simply as “Safer Contact Forms without Captcha”. There isn’t really anything tangible to show you a demo of, but an overview of the technology method can be reviewed here: http://15daysofjquery.com/safer-contact-forms-without-captchas/11/ or here: http://docs.jquery.com/Tutorials:Safer_Contact_Forms_Without_CAPTCHAs (i think this is the original author of this method, but they’re both the same thing)

Two downsides to this approach are:
1. Users must have cookies enabled as well as Javascript. A teeny tiny amount of visitors will not, but we can prompt them with a message.2. This security concept is based on the current methods that “bad bots” and hacker-programs use, but is in no means actually “securing” anything.
2. Number 2 because it is my second favorite option currently available: Ajax Fancy Captcha jQuery plugin. This one is cutting edge and truly is the best and most realistic way of proving someone is actually a human in todays software abilities and limitations. A live interactive demonstration of this is here: http://www.webdesignbeach.com/beachbar/ajax-fancy-captcha-jquery-plugin

Two downsides to this approach are:
1. “You don’t want to use CAPTCHA’s in general because you just know that requiring your visitors to read squiggly letters
and numbers just to send you a message is going to suppress communication – not encourage it.” – Quoted from the article
in option #1
2. This method is the least friendly to handicap visitors using screen readers, etc. This isn’t a major concern on this project, since we are not subject to be Section 508 Compliant or anything, but it’s always something we should be conscious of. You never want to dishonor the ADA…

3. Option #3 is very widely used and is actually the industry leader in CAPTCHA solutions in the open-source world. You’ve probably seen and used this at least a dozen times on various websites: http://recaptcha.net/plugins/php/

4. Option #4 is another flavor of CAPCHTA that is a little less “bloated” and has more readable characters, but is less effective than Option #3: http://www.archreality.com/jcap/. I’ve implemented this one one of our clients websites recently that you can look at: http://www.plansource.com/plansource/contact

We’re a Favorite Place on Google!

I received this (awesome) letter from Google today and thought it was cool enough to share:

Robots.txt, Robots Meta Tag, .htaccess mod_rewrite

There are three commonly supported methods for instructing/requesting internet indexing spiders/bots/robots what to scan and what to skip. Each of these methods are complimentary in usefulness to each other, but none are not equal in effect.

1. robots.txt
2. Robots Meta Tag
3. .htacess and mod_rewrite

Summary:

To really protect and enforce rules for any specific user agent that is visiting your website you will have to constantly analyze website traffic analytics, bandwidth reports and visiting IP addresses and geographic locations, known pubilc or private proxy servers, and the specific methods and tactics of EVERY unwanted program and visitor and be able to implement new means to thwart their new methods on a regular basis.

Block Unwanted Visitors by IP Address or UserAgent in Apache using mod_rewrite

Use .htaccess rules to block unwanted bots, spiders and other UserAgents that don’t fetch, or that fetch and ignore robots.txt.

Blocking visitors by IP address filtering in .htaccess file:

# deny specific IP addresses, and allow all others
order allow, deny
deny from 123.45.6.7
deny from 123.45.6.8
deny from 123.45.6.9
allow from all

Block specific UserAgent using mod_rewrite

   # Block Google Images Bot from Indexing your Copyrighted Images
   # Hopefully someday Google will publish a "supported way" of
   # Disallowing the Google Image Bot when necessary, but until then...
   RewriteEngine on
   RewriteCond %{HTTP_USER_AGENT} ^Googlebot-Image
   RewriteRule ^(.*)$ http://images.google.com/

The catch-22 with this method is that “sneaky” program developers can simply masquerade as “normal” visitors by using common web browser user agent strings. Reinforcing the fact that all three of these methods are USEFUL, but in no way a complete or secure solution even with the precise use of all three.

Also see:

1. robots.txt
2. Robots Meta Tag

Next Page »