Effectively Testing Reader Access To Your Blog

People reporting a problem with blog access / performance, in Blogger Help Forum: Get Help with an Issue, will be frequently advised to diagnose their problems using affinity / differential testing.

Some diagnostic advice starts with simple instructions to "clear cache, cookies, and sessions". Some people, alternately, advise "use a different browser" - and test as a reader. These different strategies, seemingly redundant, will frequently lead to different results.

When you test reader access to a blog, some experts will casually advise you to "use a different browser" or "use a second computer".

There are specific reasons why this strategy may or may not be successful, when part of affinity / differential testing. When you test blog access, you're going to see varying reliability - based on a number of browser and reader details.

There are multiple ways to test blog access, of owner vs readers.

Any experienced testing technician knows that the most reliable testing, in affinity / differential analysis, will use identical browsers, on identical and separate computers.

Very few blog owners will have use of a bank of identical computers, for testing. There are alternate possibilities, when identical computers can't be used.

• This browser, in the primary session - after "clear cache, cookies, and sessions".
• This browser, in a secondary session - aka "Incognito" / "Private" browsing.
• A different browser, on the same computer.
• The same branded browser, on a different computer.
• Any browser, on a different computer.

All of these details will be relevant, sometimes - though not always. The differences between "always" and "sometimes" will lead to some testers using incomplete testing techniques - and cause inconsistent results.

This browser, in the primary session - after "clear cache, cookies, and sessions".

The best way to avoid environment based inaccuracy is to re use the environment, sequentially. This approach requires more time - plus development of a testing script, to keep testing procedures consistent.

It is, however, the best way to avoid confusion from inevitable testing variations.

Using the same browser, in the same browser session, one can try using a different identity. This technique starts with the apocryphal instructions to "clear cache, cookies, and sessions".

This browser, in a secondary session - aka "Incognito" / "Private" browsing.

Some browsers support multiple sessions. In Chrome, a secondary session is provided as "Incognito" mode - and in Firefox, a similar (not identical) option is called "Private" browsing. The differences between the "Incognito" and "Private" features are significant - and can cause different testing results.

This blog, displayed in "Incognito" mode.



A different browser, on the same computer.

Each different browser will have differences in the browser itself. Plus, different add-ons and settings, on the different browsers, will produce differing results.

Having both browsers on the same computer will eliminate computer setup differences, present when multiple computers are involved.

The same branded browser, on a different computer.

If the branded browser, on the two computers, is maintained identically, there is a chance for consistent results. Having two different computers involved, however, may offset the consistency gained by using identical browsers.

Any browser, on a different computer.

This is the most inaccurate testing procedure, of the choices listed. Any difference between the browsers, or computers, can lead to inaccuracy.

The differences, in testing, involve multiple details.

• Login identity in use.
• Cookie filters, that block identity.
• Script filters, that block identity access.
• Browser add-ons, that may or may not be present.
• Browser brand and design differences.

Login identity in use.

This is the one difference that you intentionally need, to test the reader experience. In the primary session, you are logged in as the owner. You require at least one secondary session - where you are not logged in as the owner, to test your blog as a reader.

The secondary session is where the need for sequential session reuse - or use of a different browser and / or computer - becomes necessary.

Cookie filters, that block identity.

Many Blogger features - involving both the dashboard, and access to the blog - use cookies to determine identity and permissions. Cookie filters, inappropriately managed, can cause havoc with Blogger. As an example, consider commenting ability, and third party cookies.

Different browsers may have different cookie filter settings. In some cases, identity is not relevant, for testing as a reader.

If you are testing access to a private blog, though, reader identity - which is cookie based - will be essential. A cookie filter involved, with a private blog being tested, will cause problems.

Similarly, testing Google+ comments requires known identity - for both the blog owner and readers. With Google+, identity is essential, to guarantee consistent display of comments.

Script filters, that block identity access.

Many Blogger features - involving both the dashboard, and content in the blog - are JavaScript based. Script filters can cause havoc with Blogger.

Different browsers may have different script filter settings - and different browser brands may have completely different script filters.

Browser add-ons, that may or may not be present.

The Firefox browser does not have native script filters, so many computer owners who use Firefox will add NoScript.

NoScript is a very intense add-on, with a lot of options, and opportunities for confusion. If you were to use Firefox on two different computers, you would need to carefully synchronise NoScript settings on both computers, for reliable testing.

Firefox with NoScript is the best known example - but it's not the only possibility for confusion. Every browser can have script filters, which will make browser to browser testing comparison a challenge.

With Chrome, one can select each individual add-on to be present in the secondary session ("Allow in incognito") - and this will create uncertainty. Some advice to "try using a Chrome incognito window" will be successful, with other advice being useless - and the absence or presence of the necessary add-on will be one of the issues.

AdBlock, optionally included in incognito mode, will produce uncertainty in testing - and is a well known script block.



Browser brand and design differences.

Every different browser produces differences in displayed content. Even a formatting discrepancy can lead to difference in test results.

The end results.

Interpreting test results, based on comparison of different browser displays, will be a challenge for anybody trying to produce reliable conclusions. The most reliable results will come from testing using the same browser session, sequentially. This will start with instructions to "clear cache, cookies, and sessions" - a painful but necessary process.

---

Many #Blogger problems need to be diagnosed using repetitive testing, and affinity / differential analysis. People who don't understand organised testing will sometimes recommend testing procedures, such as use of different browser sessions - which will produce inconclusive results.

Read More

Browser Cache, And Blogs Locked After Hacking

The effects of browser cache, upon our Internet life, are not always understood.

Most of us know, by now, to clear cache and restart the browser, after updating a blog, for consistent testing. Some folks know that blog security changes don't always take complete and immediate effect.

Recently, we're seeing a new effect, reported by owners of Blogger accounts locked, after hacking activity is detected.

I got a message mentioning suspicious account activity, when I logged in to Blogger. I provided my phone number, and I received a code on my phone, that I had to enter before I could then log in. My blog was working fine just after I logged in. A short while later, though, it was gone. Why was my blog deleted, because I unlocked my account?

This blog owner is just slightly confused, about the cause and effect here.

Google robotic processes are constantly monitoring account login activity, and watching for signs of hacking activity, such as brute force password entry.

Hacking Cannot Be Detected, Immediately.

When hacking is detected, the detection may not be immediate - so Google protects us by considering the possibility that the hacking could have been successful, and deletes or locks blogs owned by the account under attack. The blogs in question are taken offline, immediately, when hacking is detected.

When a blog is taken offline, blog content may be found in cache.

If a blog owner has just been working on a blog, as is frequently the case, the blog contents will be cached somewhere between the owner and the Blogger servers. Blogger can take the blogs offline, on their servers - but any cache containing the blogs will remain. If the blog owner is working on a blog while the Blogger account is under attack, what's in cache will remain, visible to the owner, until cache expires.

If a Blogger account is attacked, and the attack is detected, shortly after the owner has viewed a blog, what's in cache will be used, until it expires. The owner won't see the effects of the blog being deleted until the cache expires, and the browser tries to retrieve a fresh copy from the Blogger servers.

As cache expires later, the blog owner sees the blog go offline.

The blog owner sees the blog go offline shortly after he verifies account ownership, and thinks that the verification process caused the blog to go offline. In reality, the blog was taken offline before the owner even knew of "suspicious" account activity.

The blog owner has to wait, while the blogs are examined for hacker changes.

Now, the blog owner can do nothing, except wait until the account and the blogs are examined for signs of tampering. In some cases, no notification of progress will be received - and the owner will see the blog(s) returned to service, sometime later.

How much later the blogs return to service will vary widely, depending upon several details - and this variation, added to the uncertainty caused by cache latency, leads to mystery. And less attentive owners may take the delay as revenge, by Blogger, for their lack of attention to their blog(s).

---

Browser Cache, And Confusion About Blogs Locked After Suspected Account Hacking
Browser Cache, And Blogs Locked After Hacking

Read More

Visitor Logs Cause Undue Concern

We see periodic concern, expressed in Blogger Help Forum: Something Is Broken, over apparent visitor access to blog maintenance wizards, using the Quick Edit icons.

I found this entry, in my StatCounter log. How did this person get access to my blog?

http://www.blogger.com/post-edit.g?blogID=7834826019588534175&postID=890014875501476492&from=pencil

Was my blog hacked?

This may not be a justified reason to panic, however. One may first wish to check that Stats (or whatever visitor log is in use, in this case) is properly configured, to not track your own activity. The link that you see may reflect your activity.

Even if the visitor log entry in question does not appear to reflect your own activity - even when allowing for the vagaries of geo location, you may still do well to remain calm.

Thanks to the unpredictable nature of cache, some blog artifacts may be visible to people other than blog owners.

Cache in your browser, on your computer, or even on your network, may cause the Quick Edit icon - which provides you with access to the sensitive wizards, which control the content of your blog - to also be visible to the casual visitor to your blog. Any idly curious visitor may even click on such an icon, when visible.

However, visibility of the icon does not guarantee access to sensitive blog controls. Here's what I saw, when I clicked on the link above.

D'Ohh!!!

Maybe, you'd like to verify that your blog is safe?

1. Extract the URL, from a Quick Edit pencil, or screwdriver / wrench, on your blog.
2. Verify that the link works, by testing it in your browser. See that you can access the post editor or the wizard, for the pencil or screwdriver / wrench.
3. Save the verified URL, somewhere safe.
4. Clear cache, cookies, and sessions (yes, clear all 3!).
5. Restart your browser, and do not login to Blogger.
6. Load the saved URL.
7. What do you see?

If the above suggestion isn't interesting, I'll let you try to attack my blog.

Similar to the problem with phantom visitors reading a private blog, or maybe seeing your email address where other people can see it, or even porn sites linking to your blog, this may not be an issue to concern you. Calm down, and get back to work.

Read More