Google will inform webmasters about their vulnerable software

As announced earlier Google will soon start to inform webmasters if they’re running out-of-date or vulnerable software. All webmasters registered with the Google Webmaster Tools will soon get notifications in case of using outdated software. Google is trying to achieve this by parsing the HTML code of the website, especially the generator meta tag. Quoting the Google Webmaster Central Blog:

One of the ways we identify sites to notify is by parsing source code of web pages that we crawl. For example, WordPress and other CMS applications include a generator meta tag that specifies the version number. This has proven to be tremendously helpful in our efforts to notify webmasters. So if you’re a software developer, and would like us to help you notify your users about newer versions of your software, a great way to start would be to include a generator meta tag that tells the version number of your software. If you’re a plugin or a widget developer, including a version number in the source you provide to your users is a great way to help too.

If you’re using (open-source) software that is writing a generator meta tag including its name and version into the HTML code, then you’re likely to get notifications by Google if this piece of code is outdated. I think this is a good thing and it won’t cost Google that much computing power as they are already parsing the source code of the site anyway. On the other hand i am not fond of software that is giving away too much information about itself. I am still a fan of security by obfuscation – as long as this is not the only line of defense.

Posted in my beloved code, security & privacy, world wide webtech | Leave a comment

Checklist: the 20 most important steps for a successful relaunch including domain transfer

You want to relaunch your site and / or move it to a new domain name? This posting tells you which points to follow during that process. It has been originally published by the T3N Magazine in German. I have translated it to English and am publishing it here with permission by the original author.

Productivity: Wrapping up the First Stage of a Special Project
Creative Commons License photo credit: orcmid

Domains transfers are bad. Many of you may know the post “Cool URIs don’t change” by the W3C. The article comes to the following conclusion:

Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.

So if you’re planning to serve your site over the next 2000 years ;) you should consider the following basics and list of 20 advices. If you follow them then your relaunch including a domain transfer should come up roses.

General advices for a technical relaunch project:

  • First identify which features shall be changed during the relaunch. Implement only the absolute neccessary change requests.
  • Document the internal testing phase in a system that is available to all team members (for instance backpack, wiki or bugtracker) -> avoid bugreports via E-Mail, to prevent duplicate records of bugs.
  • No relaunch without a testsystem that is identical to the livesystem!
  • First migrate/relaunch the testsystem and record all the steps taken, to have a plan for the migration of the livesystem later.
  • Discuss bugs that reveal during the migration of the testsystem with your team, then fix them, test again and document your doings in the plan.
  • During the migration of the livesystem, take the website off the web. Otherwise you may have to cope with data inconsistency.
  • Plan the switch / downtime (time of migration) for nightly hours (so that less users will recognize the downtime). If you have to switch in the daytime then use the downtime as PR- or marketingevent and announce some messages or even special activities while the action lasts.
  • Keep an eye on your errorlogs after the relaunch. Additionally keep in mind that you may need some extra time for fixing bugs that occur on the livesystem after the relaunch.

Domaintransfer checklist:

  1. Register the new domain.
  2. Verify your new domain in the Google Webmaster Tools. Insert your new sitemap (after the relaunch) there.
  3. Change the configuration of web statistics / tracking software like Piwik, Mint or Google Analytis to use the new domain.
  4. Generate new domain related JavaScript codes for AdSense, AdScale and other partner- or advertisingnetworks.
  5. Change zones and codes of your own AdServers (when applicable) to your new domain.
  6. Change domain-related extensions or plugins of your Content Management System (CMS).
  7. Don’t redirect internal links to your own resources but change the whole domain / code structure. (Hint by the translator: redirects are known to be bad for the performance and overall user experience of your website)
  8. Use HTTP status code 301 redirections to migrate well-known URLs of your old domain to the new one.
  9. Change headers and / or bodies of E-Mail generated by scripts (server statistics, order confirmations, newsletters etc.) to use the new domain.
  10. Change E-Mail accounts and footers of your company’s employees.
  11. Reconfigure your Feedburner account to use the new domain.
  12. Notify Google of the domain transfer at least two weeks in advance!
  13. Create a new News Sitemaps for Google News.
  14. Set up new company related documents like stamps, business cards, media kits, notepapers etc. to refer to the new domain.
  15. Create a list with backlinks to your website. Then contact bloggers, webmasters, partner, journalists and friends to adapt the backlinks to your new domain.
  16. Change backlinks from Wikipedia and other wiki systems yourself.
  17. Instruct all employess of your company to change to their social networking profiles to reflect the new domain. A few examples likely to be forgotten: Facebook, Twitter, LinkedIn, Xing, MyOnID, Gravatar, Delicious, Mento, Flickr, Digg and so on.
  18. Keep your old domain for at least six months and support the redirections (see rule 8).
  19. Search for broken Links and fix them with tools like Xenu or the Broken Link Checker.
  20. Check 404 (”Not found”) and other errors of Googles crawling process via Google Webmaster Tools daily. Fix them as soon as possible.

Did we forget something? Please comment this article and i’ll happily add your suggestions to the list.

Posted in management issues, world wide webtech | Tagged , , , , , , , | Leave a comment

The author on Twitter

Twitter
Creative Commons License photo credit: respres

Yes, i must confess, i am on Twitter. And i have several accounts. All in all there are three of them.

  1. the main account: @stottiblog
  2. one non-public account with a cool name not to mention here ;)
  3. ultimately i microblog (in cooperation) as @maschinenraum – this is the official account of the Aperto Technical Unit. The Aperto AG itself tweets as @aperto.

I invite you to follow me at @stottiblog. My publication frequency is much higher there as it is here. But i guess that’s what microblogging services such as Twitter are for. For more information about you may read this page: about.

Posted in foo bar blah | Tagged , , | Leave a comment

Amazon limits the bandwith of EC2 instances

Jonathan of Peritor Consulting just informed the world that there is in fact a bandwith limit in Amazon’s Elastic Compute Cloud (EC2) instances. In his case – using a small instance – a limit of 35 MB/s takes place. The folks of Peritor benchmarked it by hitting it with several EC2 instances and ‘normal’ servers located in other data centers. As we just had an interesting discourse on Twitter, Jonathan revealed that the bandwith must be related to the instane type you rent at Amazon’s. In XL instances there is a bandwith limit of about 70 MB/S, says Jonathan.

Posted in cloud computing | Tagged | 1 Comment

New Wordpress password hasher tool

This time just a quick post as I am in a hurry. Ever wondered how to change your Wordpress password in case you have forgotten it? In early versions Wordpress used the MD5 hashing algorithm to “encrypt” the passwords of a user. Nowadays Wordpress uses the Portable PHP password hashing framework (PHPASS) instead of MD5 hashing since version 2.5 (see this ticket) – so you cannot simply MD5 hash a new password and enter the digest into the database anymore. You have to encode it using the framework mentioned above.

Today i have implemented the PHPASS framework and turned it into a mainframe8 tool called the Wordpress password hasher. Use it to convert your new password into a “encrypted” hash and insert it into the wp_users table of the wordpress database. I will write a detailed howto later.

Posted in hands off! this is my stuff, security & privacy | Tagged , , , , | 9 Comments
Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Germany
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Germany.