Blogger Blogs Being Hijacked By Instagram Gadgets

We're seeing a noticeable amount of noise today, from blog owners reporting that their blogs appear to be susceptible to antivirus detection - and others reporting that their readers are complaining of mysterious misdirection, when viewing their blogs.

My blog is struggling to fully load, and hangs saying "Waiting for platotv . com" and "Waiting for directagain . net"

and

I'm getting warnings from Avast when I try to view my blog!

Upon examination of the blogs affected, we see a large number which contain the "I'm An Instagram Addict!", or similar, gadget. Most blog owners who admit to having an Instagram gadget have reported relief, having removed the gadget in question. We're still looking, to see where these dodgy gadgets are coming from.

---

(Update 2012/10/08): We are now seeing suggestions from various people, representing themselves as employees of "BadgePLZ", suggesting that the problems with their code has been fixed.

---

If your blog is generating antivirus alerts - or if your readers report misdirection - you may wish to remove any Instagram accessories, recently installed. You may wish to clear cache and restart the browser, after removal. You may need direct access to various dashboard wizards, in some extreme cases.

Right now, the majority of the problems reported seem to involve an "IFrame", targeting "badgeplz . com".

<iframe src='http : // badgeplz . com / instagram / ?u=mun_mun90&t=c&bgclr=f2f2f2&brclr=cccccc&px=1&py=5&pb=5&brds=5&incls=n&svc=instagram&pbclr=ffffff&sze=75' allowtransparency='true' frameborder='0' scrolling='no' style='border:none; overflow:hidden; width:118px; height: 482px'></iframe>

We're currently unsure whether this is an intentional hijacking, or simply bad coding. Until the owners of "badgeplz . com" state their intentions, we'll simply advise you to remove this gadget, if you have added it to your blog.

As usual, I'll caution you against indiscriminate installation of third party gadgets, in general.

>> Top

You Do Have To Add A Second "CNAME"

We're seeing evidence of confusion, in Blogger Help Forums, from blog owners who read the out of date instructions, about using "Buy a domain".

We see considerable confusion, where people using that feature insist that they don't have to add a "CNAME". In other cases, people using the Blogger / GoDaddy DNS Configuration wizard will think that the second "CNAME" is being added for them.

---

(Update 2013/09): The second "CNAME" won't be required, in all cases. If you don't see instructions for adding a second "CNAME", focus your efforts on getting the domain working, with righteous base DNS addresses,

---

Right now, everybody has to add their own domain ownership verification token - aka the second "CNAME".

We're hoping that the (currently offline) "Buy a domain" wizard will automatically add the domain ownership verification - just as it adds the other DNS addresses - but we'll see that, when we see it. The Blogger / GoDaddy wizard should, likewise, take care of this, on your behalf - but right now, it doesn't. The bottom line? If you go to the Publishing wizard, and see

Error 12

or a variant, after typing the domain URL into "Advanced settings", better get busy.

What not all blog owners realise is that the new "CNAME" must be just that. Blogger is not being arbitrary, or pedantic, in requiring precision.

• It must be a "CNAME". A "TXT" will not work.
• The "Name" value must be specified precisely as supplied (Plus or minus the trailing period!).
• The "Destination" value must be specified precisely as supplied (Plus or minus the trailing period!).

You cannot fly by the seat of your pants, and try what seems like it might work, as a "substitute". Webmaster Tools provides a blog ownership verification process - which may, or may not help.

If the registrar for your domain does not allow the addition of this "CNAME", you will need to setup a third party DNS host for your domain. You do have to add this second "CNAME" - even if this may conflict with older Blogger Help instructions.

>> Top

The New "CNAME" Needs To Be Added, And Used, Promptly

One oddity, observed by a few blog owners, is that even after adding the "CNAME" to verify domain ownership, not every blog owner is able to see theirs successfully verified.

I added both "CNAME"s - and I'm still getting "Error 12" when I try to publish.

There are several "common sense" rules, that not everybody observes.

1. The new "CNAME" can't use the example values.
2. The new "CNAME" has to be a "CNAME". Don't let your registrar add a "TXT" instead.
3. The new "CNAME" has to be specific to the URL in question. Enter your published URL precisely, into "Advanced settings".
4. The new "CNAME" has to be added with attention to domain manager address entry convention.

Even with these rules observed, there are still a small handful of unsuccessful blog owners, seeing "Error 12" - or "Error 32".

One of the possible reasons for these last few hold outs, I believe, relates to timing.

Let's consider the "CNAME" setup process.

1. Get the "Name" / "Label" / "Host" and "Destination" / "Target" / "Points To" values, for your unique blog / domain.
2. Add the new "CNAME" to your domain.
3. Publish the blog to the domain URL.

In the "settings instructions" document, How do I use a custom domain name for my blog?, we are instructed to

wait about an hour for your DNS settings to activate

In various other instructions, you will typically see

Wait for up to a day, for settings to be updated

or similar miscellaneous waiting instructions.

Besides the waiting factor, there's a "negative waiting" factor. Several blog owners have observed that the "Name" / "Label" / "Host" and "Destination" / "Target" / "Points To" values, for their unique blog / domain, seems to change, from day to day. This tells me that the ownership verification "certificate" (which is what the "Name" / "Label" / "Host" and "Destination" / "Target" / "Points To" values provide), like most security certificates, has a limited use period.

If you get the certificate in Step #1 above, you have to use the certificate in Step #3 reasonably promptly after doing so. If the certificate for your domain expires within a 24 hour period, then you have, at most, 24 hours between Steps #1 and #3. In other words, you get 24 hours to re publish your domain - after you add the new "CNAME" - and that's including the period that you

wait about an hour for your DNS settings to activate

It's alternatively possible that the expiry is based on an arbitrary time of day - not 24 hours after being issued.

Whatever the nature of the expiry (absolute and arbitrary - or relative to time of issuance) the existence of an expiry time is normal, for a well designed security certificate. By giving the certificate a temporary lifetime, it becomes less useful to would be hijackers and similar miscreants.

So, you may not really benefit from waiting a day to re publish your domain - unless you like seeing "Error 12" (possibly "Error 32"), repeatedly, when you try to publish. Personally, I would wait an hour at the most, after Step #2, before trying Step #3. I would then retry Step #3 hourly, until successful. If you have more patience than I, fine.

>> Top

What Is This New "CNAME", Anyway?

Ever since Blogger finally restored the custom domain publishing feature, blog owners have been asking about the addition to the domain setup process - the new "CNAME".

Do I really need this? My old blogs don't have it, and they are fine.

and

My registrar won't let me add a second "CNAME" - they allow one "CNAME" / domain (my "www").

and

My registrar won't allow long addresses, such as what you have for "Destination" / "Target" / "Points To".

And we are learning that this requirement is going to be a problem for blog owners using some registrars, who can't provide this "CNAME" in their customers domains.

In technical terms, the new "CNAME" is an ownership certificate, provided in a one way encryption.

If you have WiFi in your home (likely) - and are using encryption (hopefully), you have a similar one way encrypted certificate - the WPA / WPA2 key / passphrase. For an allegorical (easy to read) discussion about certificate encryption, see Designing an Authentication System.

Only the blog / domain owner know the values and can install the certificate.

Only you, the blog owner (and anybody who you trust, on your behalf), are able to install the certificate for your domain, into your domain DNS addresses. Only you have access to both

• The Blogger dashboard Publishing wizard.
• The zone editor wizard provided by the registrar.

This helps Blogger help you keep your domain under your control - as long as you pay the yearly registration fee for your domain.

The certificate contains 3 unique values.

The domain ownership certificate has 3 keys.

1. A private key, which Blogger appears to change regularly (some say daily) - and one which they control.
2. The BlogSpot URL.
3. The domain URL (entered in "Advanced settings").

It has two significant values.

1. "Name" / "Label" / "Host". This is now known as the "short token".
2. "Destination" / "Target" / "Points To". This is now known as the "long token".

Note the three labels used to identify each "value" - which reflect the diversity of the registrars which may provide DNS hosting for our domains (when they are able to fulfill our specific needs). When you look at the Domain Manager wizard for your domain, you may see any of the three (possibly, others) used - as there is no authoritative label for these two DNS address components.

Compare the two "CNAME"s, in structure and value.

Let's look at the two "CNAME"s, together, so you can compare the similar structure. Note the need to get the syntax, which can vary by registrar, absolutely correct.

This is the first "CNAME" - the "www" alias DNS address. This "CNAME" is identical for all Blogger blogs, using the asymmetrical DNS address convention.

1. "Name" / "Label" / "Host". www
2. "Destination" / "Target" / "Points To". ghs.google.com

This is the second "CNAME" - the domain ownership certificate. This "CNAME" will vary, for each different domain. Here we see the original example (which has since changed).

1. The "short token". vptre6sub6jm
2. The "long token". gv-g47p6dir6kfenz.dv.googlehosted.com

See the final period, at the end of the "Destination" / "Target" / "Points To" address, below? It's not in the example, above. Be very careful here, some registrar's will automatically insert the "." for you - and if you insert it also, you'll have a problem. Other registrars will need you to add it - and if omitted, you'll have a problem. Regardless, its presence, in the final product, is essential.

gv-g47p6dir6kfenz.dv.googlehosted.com.

You can verify specific certificate values.

If you know the value for the short token, you can Dig and extract the long token - when the second "CNAME" is properly setup.

Once you provide the above examples to the Domain Manager, the following two DNS addresses are generated and added to the domain server. The "3600" represents the TTL, a setting provided by the registrar. The "IN" is part of the Dig log extract syntax.

www.mydomain.com. 3600 IN CNAME ghs.google.com.

and

vptre6sub6jm.mydomain.com. 3600 IN CNAME gv-g47p6dir6kfenz.dv.googlehosted.com.

Both "CNAME"s point to specific Google servers. The second "CNAME" is only slightly obscure. Both "CNAME"s are essential (when required - but only when required).

1. The first lets you, and your readers, view your blog.
2. The second lets Google verify that you own the domain, and you should be allowed to publish your blog to the domain URL.

Nobody but you, the blog owner, will ever know the values of the tokens. Nobody but you, the domain owner, can install that "CNAME" into the domain DNS addresses. If DNS resolution of the short token address points back to the right Google server, then you, the owner of the blog, and the owner of the domain are verified as the same person. And the ownership certificate is "decrypted", using DNS name resolution.

• Short token. vptre6sub6jm
• Long token. gv-g47p6dir6kfenz.dv.googlehosted.com

Some certificate values are temporary.

Since the private Blogger key changes regularly, if anybody learns what tokens you used, in the short 3 step domain verification process, the values will have likely changed, and their time will have been wasted. Your blog and domain remain your blog and domain.

So, do the necessary. Blogger provides instructions, specific for 7 known registrars - and a general purpose instruction for others, in Google Help: Create a CNAME record for my custom domain. If their instructions conflict too much with your reality, try setting up third party DNS hosting.

1. Get the short token and long token values, for your unique blog / domain.
2. Add the new "CNAME" to your domain.
3. Publish the blog to the domain URL.

That's it (subject to observed timing issues). You are now done with the domain ownership verification process, and with these encrypted values. Start planning the migration - this will happen faster than you think. And it is your responsibility, to get this done.

Custom Domain Setup Now Lacks The "Buy a Domain" Wizard

As we sift through the wreckage of the blogs damaged by the recent Blogger custom domain security issue, we note a significant omission. The "Buy a Domain For Your Blog" wizard is conspicuous in its absence.

When I click on the Settings - Publishing options, I don't even have the option to check availability or purchase a domain name. Where is the "Buy a domain" display?

Right now, it appears that "Buy a domain" was sacrificed, so that the general custom domain publishing feature could be restored more promptly (though not promptly enough, for many blog owners). There are several tasks that must be completed by "Buy a domain", which are complex - and the necessary coding simply could not be completed by Tuesday of this week. I saw one message of hope.

We will be restoring the ability to purchase a custom domain from Blogger soon.

We'll simply have to have faith, that they are working on this feature as we lament its current absence - and that its absence is brief..

In the mean time, some wanta be domain owners have found a domain purchase wizard provided by Google Apps - though that's not "Buy a domain". Google Apps has two different wizards providing domain purchase options, each with a widely different address and Top Level Domain menus.

---

(Update 2012/10/09): "Buy a domain for your blog" is once again part of the Publishing wizard.

---

>> Top

The New GUI Is Here

Several people are reporting seeing the New Blogger GUI in their dashboard - even when they did not intentionally upgrade. Possibly, this was forced by the necessary Custom Domain Authentication Feature, which is now operational - on the New GUI only.

I am expecting my Blogger account to change, soon. Let's see if I get a "Your blog post published successfully!" display. So far, I am in Virginia - though I am thinking of a procedural workaround for that shortcoming. I realise that everybody won't have a workaround for their dislikes - though we have to be contemplative, and accept the changes.

If you wish to make your feelings known, please post in the latest Problem Rollup: V4 I do not like the New Blogger Interface because ...

>> Top

Custom Domain Publishing Is Back - And With A New Detail

After a very stressful week, Blogger Engineering has restored the custom domain publishing option.

Last week we encountered an issue that could affect Blogger users in the process of configuring a custom domain, during the verification of ownership of domains between the provider and Blogger. Blogs with previously configured custom domains were not affected.

With the reason for disabling custom domain publishing being security, Blogger Engineering has added a step in the publishing process, to add a random token as a "CNAME", and verify your right to publish to your domain, from Blogger. You get the random token from the "settings instructions" document, "How do I use a custom domain name for my blog?".

See the URL of this (hypothetical) settings instructions document?

http://www.blogger.com/custom-domain-instructions.g?cnameVerificationToken=VPTRE6SUB6JM+gv-G47P6DIR6KFENZUFIFYWSQJJPDYFZK4SQMUUIUFLYLCQD4OIGDFA.domainverify.googlehosted.com.&domain=www.hotspotshield.com

This is an example. If you're registering a domain other than "www.hotspotshield.com", you're going to have a different token - which should be a function of the BlogSpot and domain URLs. You'll also note another case sensitivity issue - "www.hotspotshield.com" and "www.HotSpotShield.com" will produce completely different tokens.
Now, it's an out of date example.

http://www.blogger.com/custom-domain-instructions.g?cnameVerificationToken=GKBPLXBRMT5M+gv-H5FFOYEKYNXE46EE4A3PLAK6HCDIELS27KQUR5OBKHFKXRKMCTDA.domainverify.googlehosted.com.&domain=www.hotspotshield.com

That's what you get, for "www.hotspotshield.com", today. We'll check again, tomorrow. Also, we need to know when "today" ends.

If you buy a domain using "Buy a domain" after today, Google Apps should setup the domain for you - including the second "CNAME". If you bought the domain directly from a registrar, you're going to have to click on "settings instructions", and get the token for your domain. Note that a "CNAME" is required - a "TXT" won't provide the same verification. Also note the various registrar entry conventions, which will affect your use of their domain manager forms.

We are learning a lot of details about the domain verification process, some of which were known in custom domain setup in general - and which are absolutely critical to the process. You will want to read the [FAQ] Why is my domain still in "12" / "404" State?, to get all of the details. The FAQ has been updated several times, so re read it often..

This will, hopefully, provide a solution for the Abandoned Domains problem, and allow everybody to publish to their domain, regardless of whether the domain was previously used for Blogger / Google custom domain publishing by another blog.

On the other hand, if you purchased your domain using "Buy a domain", and you ever need to recycle the publishing settings, you're probably going to have to add this new "CNAME" to your domain, before you can re publish. This will possibly include everybody who purchased their domain, before the Publishing option was disabled - if the domain is not operational right now - and possibly, blog owners who need to un delete a domain published blog.

>> Top

Blogger Blogs Showing "Possible Blogger Terms of Service Violations" Notice

Last week, we saw a fairly large number of reports from blog owners, reporting that their blogs had been apparently classified as spam hosts - but with a new symptom.

Possible Blogger Terms of Service Violations

This blog is currently under review due to possible Blogger Terms of Service violations.

If you're a regular reader of this blog and are confident that the content is appropriate, feel free to click "Proceed" to proceed to the blog. We apologize for the inconvenience.

If you're an author of this blog, please follow the instructions on your dashboard for removing this warning page.

When the problem was forwarded to Blogger Support, they identified a recent change in the spam classifier as a cause - and suggested that they could review and reverse all such false classifications, en masse.

Later that same day, Blogger Support declared that the problem was resolved.

We've been seeing intermittent reports of this problem, recurring, since the latter declaration. We're handling them on an individual basis, starting from reports in Blogger Help: Something Is Broken.

If your blog shows this symptom, please start a new topic in Something Is Broken. - and indicate the "Possible Blogger Terms of Service Violations" in the Question title / Subject. We'll do our best to expedite resolution of your problem. Please be accurate, brief, and complete - and as always, state the URL of the blog.

>> Top

Enabling Blogger, If You Now Have An ISP Provided Email Account, That Uses Google Apps Based GMail

We're seeing problem reports from some confused blog owners, who are apparently customers of ISPs who have made the switch, from using a private email infrastructure, to using GMail based email (administered using Google Apps).

When I try to sign in I get this message.

Blogger has not been enabled by the administrator of the domain

How do I administer my blog?

We've known, for a while, that having a Blogger account based on a Google Apps provided GMail account may not be a good long term strategy - particularly if the Apps account is based on a domain which you own, and the domain was purchased to host one of your blogs.

Possibly considering the latter scenario, Blogger / Google now requires that you enable the Blogger service, for any new Google Apps controlled domain - if you wish to use email addresses in that domain to host Blogger accounts. This is a safety measure, helping to prevent you from having a Blogger account that you can't control - or can't recover access when you forget the password.

All of that is fine - when you control the domain that you wish to use to host your Blogger account. But what if you don't control the domain? What if you previously setup a Blogger account based on an email domain owned by your ISP (employer, school, what have you ...) - then later the domain administrator decides to upgrade the domain, to use GMail based email? What happens to your Blogger account?

Short of convincing the domain administrators for your ISP (school, employer) that you have a genuine and urgent need to have a Blogger account, based on an email address that they provide, you're going to need a new email address - provided by someone other than Google, or your ISP (school, employer).

Start by setting up an email account in some third party web service - maybe "Yahoo.com". Then, you have two possibilities. If you're reading this article just before your ISP makes the switch, and you can still use your Blogger account, transfer control of your blog(s) to a new Blogger account that's based on your new email address.

If you just discovered the change by your ISP - maybe because you now see the bad news

Blogger has not been enabled by the administrator of the domain

you are going to have to recover control of your blog, based upon access to your ISP's email account - and setup a new Blogger account based on your new non ISP based email account.

1. Generate a new account recovery email message.
2. Setup a new email account, outside your current email service.
3. Clear cache, cookies, and sessions.
4. Restart the browser.
5. Login to your current email service, find, and open the email message.
6. Click on the link in the email message.
7. Setup a new Blogger account, based on the new email address.

Whatever you do when setting up your new Blogger account, please make sure to verify the email address - and setup recovery options, carefully.

>> Top

New Custom Domains Are Broken

Many owners of Blogger blogs - and most owners of Blogger blogs published to non BlogSpot URLs - know the sad truth.

Mapping a blogspot domain to a custom domain is currently disabled.

It's been this way, for several long days.

If you are the owner of a Blogger blog, currently published to a non BlogSpot URL, you have probably seen the problem, when trying to view your blog - even after setting up righteous DNS addresses, and having published the blog to the domain.

404. That’s an error.

The requested URL / was not found on this server. That’s all we know.

Today, we see reports that publishing to the domain is simply not an option.

In my settings, under "Publishing", it shows both addresses and below says

Maintenance in progress - Domain switching disabled.

Blogger Engineering has stated that this problem applies only to new custom domains - though if you have a mature domain, which you try to republish, you'll likely see the same problem. Some hackers have claimed "responsibility", stating that the problem is related to their abuse of GoDaddy, and their DNS service. However, we note that blogs published using both eNom, GoDaddy, and various third party DNS services are being reported with this problem. Right now, this blog, on this domain, is up.

The "404" error is nothing new - we have been seeing it, and we've been diagnosing the symptoms, for many years. However, previously we could generally diagnose, and advise the blog owner, how to resolve the problem.

Now, we can only advise that there is a problem - and that you will know, when we know, when the problem is due to be fixed. And that will probably be 10 - 15 minutes after Blogger updates the latest Known Issues article.

---

(Update 2012/09/17): Blogger Support informs us that the Blogger Engineering team is acutely aware of the issue and is working around the clock to get a fix in place for Blogger users.

we are well aware that is a frustrating situation for everyone involved.

---

>> Top

How Not To Make Your Blog Private

Blog owners have been asking, for years, how to protect their blogs against viewing by undesired or unknown readers.

How do I password protect my blog?

When told that Blogger password protection involves membership invitations, accepted using a Blogger Google account, some would be private blog owners decline the suggestion.

That's too complicated for my readers! Can't I just give everybody a password?

But Blogger does not use common passwords.

Some blog owners, who are technically astute, find add on template code, provided by third parties - which demands a password, in a popup window, to continue. This is where their problems start.

The addition of third party supplied JavaScript code, to our blogs, has always been a dodgy process.

With third party JavaScript code used to provide password protection against unknown readers, this is even more hazardous to your blog. From time to time, we have a blog owner who installed password protection code in his blog template - and subsequently found his blog locked.

I received email saying that my blog has been removed, and has been marked as spam. The email is as follows:

Your blog has been reviewed and confirmed as in violation of our Terms of Service for: MALICIOUS_JAVASCRIPT. In accordance to these terms, we've removed the blog and the URL is no longer accessible.

Can you please review and unlock my blog?

But the story does not end there. Subsequent review of the blog was denied, by Blogger Support.

Your password prompt is not dismissable - and forces users to close their entire browser session, as the Cancel button does nothing. This is malicious behavior, and prevents anyone one on our team from even reviewing your blog content.

This leaves the blog owner with a deleted / locked blog, and no chance of getting the blog back.

Besides the potential threat above, which becomes actual only after spam classification detects the add-on code as malicious, any security expert will recognise two reasons why this solution is worthless.

1. JavaScript code can be blocked, by any reader with a well implemented security policy.
2. If not blocked, anybody can view source code and find the "password" right there, in plain sight.

This "solution" is therefore worthless for two reasons.

1. It is risky.
2. It does not work.

Why risk loss of your blog, for a risky solution that does not work? There's only one way to protect your blog from unknown readers.

1. Send each would be blog reader a membership invitation, using the Permissions wizard.
2. Instruct each reader to open and accept the invitation, using any preferred Blogger account.

Don't script your blog, and risk deletion - and incidental damage.

Attempting To Remove Old FTP Published Blogs From Blogger Account Corrupts The BlogList

Recently, we've seen a few reports from unhappy blog owners who used to publish blogs using FTP, who tried to delete the FTP published blogs from their Blogger account, and now can't access their dashboard bloglist - or even login to their Blogger accounts successfully.

I recently tried to delete an old FTP published blog from our account, I hit the "delete blog" button, and I get error code bX-dm6o9e. When I try to access my dashboard, I get the same error.

The option to publish a Blogger blog to remote, non Google hosted, server space - known as FTP Publishing - ended several years ago. Now, people attempting to clean up their blog list, and trying to remove old, FTP published blogs will find a problem. We note that the dashboard utilities, in general, can still be accessed, using the navbar links - or the quick edit post links.

We have a Problem Rollup discussion, where we are requesting diagnostic details from victims of this problem.

1. Have you tried using the Classic or the New GUI - or both?
2. Does your Blogger account use a Blogger, Google, or Google+ profile?
3. What's your Blogger Profile URL?
4. Is the blog being deleted in existence, on the remote server?
5. Does the blog being deleted have current and valid DNS addresses, pointing to the contents?
6. What's the URL of the blog being deleted?
7. What browsers have you tried using? Do you get the bX-dm6o9e error from each browser?

If you are experiencing the bX-dm6o9e code, please answer the questions as best you can, to encourage Blogger Engineering to identify and correct the cause of the problem.

>> Top

The New GUI (2011) Will Soon Become The Blogger GUI

This month, we are seeing a sign of the end of The Classic Blogger GUI, coming soon.

The old Blogger interface will be removed in the coming days.
We've made many improvements to the new Blogger interface. Learn more
You can upgrade to the new interface at any time.

We've all been expecting this, for a while - but it's still a shock. Some of us are concerned that forced use of the New GUI will cause problems in productivity, if not blog functionality.

My personal opinion is that the New Blogger GUI still lacks features and stability. I don't think that I am alone.

We have a rollup discussion, where your opinion will be appreciated. Please be objective and polite.

>> Top

Blogger Supports Their Customers

Every week, in Blogger Help, we see the cries of frustration.

Many years ago I had a Google account with a "gmail.com" e-mail address. But I deleted this account, because I didn't need it anymore. Later, I wasn't able to login to Blogger, to delete my blog. And I also wasn't able to remove it by contacting Blogger. Why doesn't Blogger support their customers?

The point being overlooked here is that both Blogger and Google do support their customers.

Blogger / Google, like every commercial enterprise worldwide, simply supports their active customers more than their not-so-active customers.

1. They have millions of customers, who spend much time maintaining and publishing their blogs.
2. They also have some customers, who start blogs, and leave them dormant for many years - then require assistance recovering access to their Blogger accounts, because they have forgotten the account name or password, and the backup email address can't be used.

Considering that Blogger / Google is not a non profit organisation, and needs to support customer activity, which group of customers should they support most readily?

Blogger / Google wants to encourage us to maintain and to publish our blogs regularly.

Blogger can't support inactive blog owners, to the needed level.

People who don't use their services regularly, then demand special assistance when needing to use their services, are not going to receive the same level of support.

1. People who use Blogger regularly will develop a level of proficiency - and won't require special assistance as much as those who don't use Blogger regularly.
2. People who use Blogger regularly simply require a working Blogger interface, and a level of security that keeps their blogs under their control. People who don't use Blogger regularly need a different and more complicated Blogger interface - and a lower level of security, so they can continue to access their Blogger accounts.

The needs of the few (who don't use Blogger regularly) have to be considered against the needs of the many (who do use Blogger regularly).

Blogger can't support inactive owners, over active owners.

Recently, we had a series of well organised hijackings of actively published Blogger blogs.

After Blogger / Google recognised this ongoing threat - which endangers all Blogger blog owners - they tightened down their security, and restricted assistance to those needing help recovering access to their Blogger accounts. People who don't use Blogger regularly don't understand the reasoning behind this reduced level of assistance, and increased level of security.

Unfortunately, understand it or not, we all have to learn to live with it - if we wish to continue publishing Blogger blogs.

The Multiply Blogging Platform Is Ending

Recently, people who use the popular Multiply blogging platform were given bad news.

From December 1st, we will unfortunately no longer be able to support Multiply in its current form - notably we will be removing the social networking and content sharing part of Multiply (photos, videos, blogs, social messaging, etc.). We have decided to discontinue providing and hosting these services, as we have concluded that other Internet sites who are committed to social networking services will do a better job serving you than we can.

They are, right now, unsure what options they can offer, to help existing Multiply blogs be transitioned to alternatives such as Blogger.

We're still finalising the exact list of formats and platforms that we'll export to, but users will be able to download all their original media and data, (in some flexible formats) and also able to migrate directly to alternative blogging platforms.

So, let's see what options Blogger Engineering can offer. Watch this space, for updates.

>> Top

One Of The Blogger / Google Custom Domain DNS Servers Is Down

This afternoon, we started seeing some frantic problem reports, in Blogger Help Forum: Something Is Broken.

My custom domain published blog is not loading today. What is going on with your servers???

The numbers, of concerned blog owners, are relatively small, compared to normal custom domain publishing problems - but the concern is very real.

When we look at the DNS addresses for the domains involved, we see one common factor - a custom domain, relying solely on the Google Apps DNS server "216.239.32.21".

Long ago, I warned people about the dangers of relying on one single DNS server, for domain address resolution.

But not one server is going to be 100% reliable, or last forever. Every computer ever made, like every human born, will die, one day.

Now, we see just that, happening.

This is the correct DNS address setup, for your domain "mydomain.com".

mydomain.com. 3600 IN A 216.239.32.21
mydomain.com. 3600 IN A 216.239.34.21
mydomain.com. 3600 IN A 216.239.36.21
mydomain.com. 3600 IN A 216.239.38.21
www.mydomain.com. 3600 IN CNAME ghs.google.com.

This will work - for a while (but not this week).

mydomain.com. 3600 IN A 216.239.32.21
mydomain.com. 3600 IN A 216.239.34.21
mydomain.com. 3600 IN A 216.239.36.21
mydomain.com. 3600 IN A 216.239.38.21
www.mydomain.com. 3600 IN A 216.239.32.21

This will work - for a while (but not this week).

mydomain.com. 3600 IN A 216.239.32.21
www.mydomain.com. 3600 IN CNAME ghs.google.com.

This will work - for a while (but not this week).

blog.mydomain.com. 3600 IN A 216.239.32.21

None of the above three DNS address setups are working, right now - and here is why.

C:\>ping 216.239.32.21

Pinging 216.239.32.21 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 216.239.32.21:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Server "216.239.32.21" is not online.

Conversely,

C:\>ping 216.239.34.21

Pinging 216.239.34.21 with 32 bytes of data:
Reply from 216.239.34.21: bytes=32 time=25ms TTL=52
Reply from 216.239.34.21: bytes=32 time=23ms TTL=47
Reply from 216.239.34.21: bytes=32 time=24ms TTL=52
Reply from 216.239.34.21: bytes=32 time=34ms TTL=52

Ping statistics for 216.239.34.21:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 34ms, Average = 26ms

Server "216.239.34.21" is online.

C:\>ping 216.239.36.21

Pinging 216.239.36.21 with 32 bytes of data:
Reply from 216.239.36.21: bytes=32 time=49ms TTL=47
Reply from 216.239.36.21: bytes=32 time=45ms TTL=47
Reply from 216.239.36.21: bytes=32 time=25ms TTL=52
Reply from 216.239.36.21: bytes=32 time=23ms TTL=47

Ping statistics for 216.239.36.21:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 49ms, Average = 35ms

Server "216.239.36.21" is online.

C:\>ping 216.239.38.21

Pinging 216.239.38.21 with 32 bytes of data:
Reply from 216.239.38.21: bytes=32 time=45ms TTL=52
Reply from 216.239.38.21: bytes=32 time=71ms TTL=47
Reply from 216.239.38.21: bytes=32 time=46ms TTL=52
Reply from 216.239.38.21: bytes=32 time=24ms TTL=52

Ping statistics for 216.239.38.21:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 24ms, Maximum = 71ms, Average = 46ms

Server "216.239.38.21" is online.

If you specified "216.239.32.21" by itself, for a host address in your domain, that address is now down - except, possibly, for readers who use Firefox. One server ("216.239.32.21") is down - maybe intentionally - but the remaining three servers ("216.239.34.21", "216.239.36.21", and "216.239.38.21") are up. Google will continue as is, until "216.239.32.21" can be conveniently repaired or replaced.

It's Labour Day Weekend in the USA, and all is well - for everybody who specified all four servers for their domains.

>> Top