"HTTPS Redirect" And Private Blogs

URL redirection is a Blogger magic trick, similar to a common sleight of hand trick in stage magic performances.

The Blogger HTTPS Redirection, a recently added feature in Blogger security, may be a similar Blogger magic trick - and a possible problem. Some browsers treat websites with multiple redirects as possibly malicious.

Private blogs, accessed through the Blogger / Google interstitial login, may also complicate HTTPS Redirection.

Interstitial webpages may pop up like magic, where you (or your prospective viewer) would least expect them.

• In front of a "private" blog, where you have to identify yourself to continue.
• In front of a blog that contains (or is reputed to contain) objectionable material (naughty pictures or such).
• In front of a blog that is (or appears to be) published off site.
• In front of a blog that has been blocked, for TOS violation, or maybe for hosting hacking content.

One of the problems with HTTPS Redirection may involve private blogs.

To access a private blog, you must be identified.

To access a private blog, one must be logged into Blogger, using an account that is a member or owner of the blog.

If you are not logged in to Blogger, you may be asked to identify yourself, to access the blog.

If you are logged in to Blogger, but using a non member / owner account to access the blog, you may simply be refused access.



Both of those displays come after the link to the blog - and before the blog is viewed. They are called "interstitial" webpages.

If you try to access a private blog, and are not a member / owner, you should see the well known Blogger / Google interstitial login webpage. In order to check that you are a member / owner, the infamous Google Login Cookie must be accessed.

The Google Login Cookie, created under the Google login sequence and accessed from a Blogger display, is a "third party" cookie. If the browser blocks "third party" cookies, as many do, the browser may refuse access to the private blog - even if the prospective reader is logged in to Blogger, as a member or owner.

If third party cookies are not blocked, too many redirects may present a problem.

If third party cookies are not blocked, some browsers may still have a problem - too many redirects. Some browsers may object to multiple redirects to other websites - as possible malicious content. A redirect to an interstitial display, following the "HTTP to HTTPS" redirect, may be one too many redirects.

The mysterious Blogger "private blog" interstitial display, which lets people login to a private blog when necessary, may contribute to the "too many redirects" problem, for browsers which are sensitive to multiple redirects. Even if a private blog member / owner is logged in properly, the interstitial display is still involved, in checking for proper login - and this is where the infamous "third party" cookie is involved.

You may need to adjust your security settings, for best results.

If you are trying to access a private blog - and you see "This blog is open to invited readers only", or you are forced to login, again (!!), you will need to check and correct your cookie filters. You might want to similarly check and correct your script filters.

Please remember that the filter that is affecting your private blog access - whether cookie or script - may not be part of your browser native settings. Check thoroughly.

---

One of the challenges involved with the recently added #Blogger "HTTPS Redirect" may involve private blogs, and the Blogger private blog interstitial login. "Third party cookie" filters, and the Blogger private blog interstitial login, will complicate this problem.

https://productforums.google.com/d/topic/blogger/WiR84_IRF8w/discussion

Microsoft Windows Security Updates, May 2016

If you use a computer that runs Microsoft Windows, you may have been affected by Microsoft supplied updates, distributed 3 weeks ago.

May 10 was the day termed "Patch Tuesday" - the day when Microsoft releases important security related patches, to its various Internet updated products. During the 3 weeks after May 10, we've seen a significant number of security related discussions, in Blogger Help Forum: Get Help with an Issue.

It appears that Microsoft updates, for May 2016, affect use of Blogger.

The Microsoft Security updates, applied May 2016, appear to have affected various Blogger features, that are known to be vulnerable to layered security.

• CAPTCHA visibility when daily post limit is exceeded.
• Publishing comments, or replying to published comments.
• Quick Edit icons.
• Followers / Reading List maintenance.
• Stats self initiated pageviews.

All of these features are known to be affected by cookie filters, and / or by script filters.

If you are using a computer that runs either Microsoft Windows 7 or Windows 10, and you are experiencing a problem with publishing comments, or with using Quick Edit, or with blocking your own views in Stats, or similar problems, you may want to check your cookie and script filters.

I note that some of the reports mention the browser used as Chrome or Firefox. You'll want to check filter settings in Windows Security Essentials.

Being realistic, it's also possible that Microsoft broke something within Windows - but we'll have to wait patiently, for them to admit that.

If you need different or more advice, please start a new topic in Blogger Help Forum: Get Help with an Issue.

---

Microsoft released monthly security updates May 10, 2016 - and since that date, there have been a number of security filter related issues, reported in Blogger Help Forum. It appears that the the Microsoft Updates involve cookie or script filters, which affect use of Blogger.

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.

Blogger Magic - Enabling Exceptions, In Chrome

Some blog owners and readers prefer to ignore recommendations in Chrome - and block cookies and / or scripts.

Blocking cookies can cause problems with many Blogger features - and blocking scripts will cause problems with both Blogger and with Google, and with various other websites.

If you want to use Blogger and Google effectively, you need to allow cookies to be installed, and to allow scripts to be run, on your computer.

If you cannot allow cookies and scripts for all websites, you can allow cookies and / or scripts on specific websites.

With Chrome, if you are willing to selectively allow specific websites to install cookies / run scripts, you should enable exceptions for those websites.

Start with the "Content settings" wizard.

Select "Block third-party cookies and site data", and / or "Do not allow any site to run JavaScript".



Add cookie exceptions, for specific websites.

Click on "Manage exceptions" under Cookies, to get the "Cookie and site data exceptions" wizard.

To add "google.com" as a cookie exception, paste / type "[*.]google.com", and select "Allow".

Click anywhere in the wizard window, to see the addition - then click "Done".



Add JavaScript exceptions, for specific websites.

Click on "Manage exceptions" under JavaScript, to get the "JavaScript exceptions" wizard.

To add "google.com" as a JavaScript exception, paste / type "[*.]google.com", and select "Allow".

Click anywhere in the wizard window, to see the addition - then click "Done".



Remember that cookie and script filter settings, in Chrome, may not be the only settings which you need to consider - and that many filters are subject to change, without your knowledge or approval.

For more detail about cookie and JavaScript exceptions, see Chrome Help: Manage exceptions. These are settings that you must determine and install - neither Blogger nor Google can make these changes for you.

---

Security conscious #Blogger blog owners may wish to ignore #Chrome recommendations, and block general permission for websites to install cookies and / or run scripts on their computers.

Some websites will not run properly, without cookies and scripts. If one is to use websites like Blogger and Google successfully, they need to be trusted - and Chrome must allow those websites to install cookies / run scripts.

Blogger Magic - Enabling Cookies, In Your Browser

The Blogger dashboard, and blog displays, is less of a pair of websites - and more of an application with code that runs on our computers.

The Blogger code on our computers requires cookies and scripts, which are installed as we use the various Blogger dashboard pages. The cookies and scripts are susceptible to interference, from overly restrictive layered security.

If you have a problem with Blogger - either accessing / using the dashboard, or using / viewing a blog - one of the simplest things to check, complementing script filter settings, is the browser cookie filter settings.

The browser is the most important component, when setting up security - and cookies are a common challenge.

Cookie filters are adjusted differently, for each browser. Consider the multiple domains used by Blogger / Google - and layered security, on any computer, used by the owner and readers of any blog.

• Chrome.
• Firefox.
• Edge / Internet Explorer.
• Opera.
• Safari.

Setting the cookie filters in Chrome.

With Chrome, you enable cookies, using Settings ("Customize and control Google Chrome") - aka the 3 bar toolbar icon.

In Settings, if necessary, click on "Show advanced settings" at the very bottom of the page. Under Privacy, click on "Content settings", which gives you the "Content Settings" wizard.

Here, you have selections for Cookies and Javascript - including "Manage exceptions" for each section. Select the recommendation.

• Cookies: Allow local data to be set

Hit "Done" - and close the Settings tab.

From "Privacy", hit "Content settings".

Under "Cookies", select "Allow local data to be set".



If you want to enable cookies selectively, select "Block third-party cookies and site data". Then use "Manage exceptions", and add "blogger.com", "google.com", and any addresses which apply to your blog.

Setting the cookie filters in Firefox.

With Firefox, you enable cookies, from the browser menu - aka the 3 bar toolbar icon, using Preferences - Privacy.

• Under History, select that "Firefox will:" is set to "Remember history" then "Use custom settings for history". That will give you an array of settings.
• Check "Accept cookies from sites".
• Close Preferences. Settings will be saved.
• Note that any Firefox add-ons which filter cookies, and offer more detailed options, will have to be dealt with, separately.

Select "Remember history", then "Use custom settings for history".

Check "Accept cookies from sites".



If you want to enable cookies selectively, change "Always" to "Never". Then use "Exceptions", and add "blogger.com", "google.com", and any addresses which apply to your blog.

Setting the cookie filters in Edge / Internet Explorer.

With Edge / Internet Explorer, you enable cookies, using the browser menu, selecting Tools - Internet Options. Optionally, you may access the "Internet Options" applet directly from the Windows Control Panel.

• Edge / IE uses a zone defense setting, where you designate "blogger.com" and "google.com", in Security, as being in the Trusted zone. Please note that "blogspot.com" should not be in the Trusted zone.
• Default settings for the Trusted zone will allow proper filtering of scripts.
• Verify proper settings, with "Trusted sites" selected, and the Security level slider control set to "Medium". Hit "Custom level", and examine the Settings list.
• You enable Cookies under the "Privacy" tab.
• Move the Privacy slider to the bottom, to allow all cookies.
• Click "OK".

Setting the cookie filters in Opera.

With Opera, you enable cookies, using the Advanced tab, in the Preferences wizard. Select "Accept", to accept cookies from all sites.

Setting the cookie filters in Safari.

With Safari, you enable cookies, using the Preferences wizard. The Privacy wizard, in Preferences, contains selections for cookies ("Cookies and website data”). Select "Always allow", to enable third party cookie access.

Cookie filters cause half of the problems reported, with many Blogger features.

Maybe 50% of the problems, reported in Blogger Help Forum: Get Help with an Issue, with many Blogger features involve cookie filters.

• Comments.
• The Cookie Advice Banner.
• Post/Page/Template Preview.
• Reading List.
• Template Designer.

Stats and the "Don't track ..." option used to involve third party cookies, for many years. In March 2016, "Don't track" was rewritten to run under the URL of the blog, when being set - and now requires enabling scripts from the blog URL.

Consider how your blog is published.

If your blog is published to "blogspot.com", consider the non "blogspot.com" alias that may be relevant to your country. If your blog is published to a custom domain, consider the custom domain URL.

Many computers have other relevant settings, which block cookies.

Many blog owners and readers will have computers, and networks, with additional protection. Cookies, in the browser, may not be the only filter that needs to be checked - but this is a start, to learning how to control the cookie filters.

Having checked and corrected your cookie filters, continue by checking browser script filters - then check cookie and script filters, outside the browser. Be aware that many settings may not be obvious - and that both obvious and obscure settings may be updated, without your intention or knowledge.

Learn more.

• Google Accounts Help: Enable or disable cookies.

---

Many #Blogger problems are cause by overly restrictive cookie filters. If you, a blog owner or reader, are going to use Blogger successfully, you need to configure your browser properly.

Commenting Requires Login, To Suppress Spam

Some blog owners don't understand the need to identify themselves, when commenting on our blogs.

We see an occasional question, in Blogger Help Forum: Get Help with an Issue, about comment authentication.

Why, if I've selected "Anyone - including Anonymous Users" under comment settings, for "Who can Comment?", do my visitors complain of having to login?

This blog owner, like many others, does not understand the Blogger spam mitigation policy, in Blogger Comments.

Blogger lets us select who we wish to allow to comment, on our blogs.

When we do not moderate, they require authentication, to cut down on the spam. Moderated comments, with CAPTCHA ("Show word verification") not required by the owner, appear to go straight to moderation.

Comment authentication makes genuine comments more normal.

By requiring authentication, Blogger makes it more likely that a comment, awaiting moderation, will be genuine - instead of more spam. This encourages us to moderate comments more frequently - and helps us publish moderated comments, more promptly.

And more frequent moderation discourages spam - and makes it more likely that we will see actual comments, later.

Blog owners choose how to allow comments.

As a blog owner, it's your choice how / whether to allow comments.

• Anyone - includes Anonymous Users.
• Everybody with a Google, or an OpenID, account.
• Everybody with a Google account.
• Blog members only.
• Comments disabled.

Blog readers choose how to publish comments.

Depending upon the choices that you provide, your readers choose how they may authenticate.

• "Anyone" allows a reader to comment anonymously - or identified.
• If they wish to comment anonymously, they login, using a CAPTCHA.
• If they wish to comment using a profile, they login, using an account.
• Login is generally only required, with the first comment.

"Anyone" allows a reader to comment anonymously - or identified.

"Anyone" allows anyone to comment anonymously (if they wish). To cut down on spam, anyone commenting has to login.

If they wish to comment anonymously, they login, using a CAPTCHA.

Solving a CAPTCHA lets them remain anonymous - but still identify themselves as a person, not a bot. Any comments, awaiting moderation, or published, are more likely to be genuine - not spam.

If they wish to comment using a profile, they login, using an account.

They can login, as permitted, using a Google or OpenID account. Anyone able to login with a Google or OpenID account can still publish a comment anonymously, if they wish.

Login is generally only required, with the first comment.

If someone has to login repeatedly, to comment, they have a problem with identification, and filters. With cookies and scripts properly permitted, login (with the first comment) will be remembered (with any later comments).

The Blogger / Google login status, and the ability to post comments, is sensitive to both cookie and script filters. Your readers may need to enable (stop filtering) "third party cookies", in their browser and on their computer - if they wish to comment, most easily.

---

Both a #Blogger blog owner - and blog readers - get choices how to authenticate when commenting. Depending upon the choices made by the owner, the readers get more, or less, choices.

Stats "Don't Track" - You Cannot Satisfy Everybody

Blogger recently redesigned the Stats "Don't track ..." option - and removed third party cookies from the picture.

The "Don't track ..." wizard is now accessed from the blog URL. The wizard still produces cookies - but they are ordinary first party cookies, which are much less feared than third party cookies.

But, every silver lining has a cloud.

In making the "Don't track" wizard accessed under the blog URL, Blogger created a new requirement - which is no more understood, by some blog owners, than "third party" cookies.

"Don't track" now runs scripts from the blog URL, instead of the Blogger dashboard.

In order for a blog to observe - and preserve - the "Don't track" setting, any computer that the owner uses has to permit first party cookies - and all scripts - from the blog, instead of from the Blogger dashboard.

Since "Don't track" is designed to be used by the blog owner, this new requirement should not be a problem. Every blog owner should be able to trust herself / himself, to not add dodgy code to his / her own blog.

Owners of blogs published to custom domains will have to tweak the URL used by the "Don't track ..." Stats wizard, to set "Don't track" - since custom domains do not support HTTPS.

Many security products block scripts from personally owned blogs.

Unfortunately, general security practice is to block scripts from "blogspot.com", "blogspot.xx" (for every "xx" for every country local domain"), and preferably for blogs published to custom domains.

You can trust scripts from "blogger.com", and the Blogger dashboard. You cannot trust the individual blogs, since you cannot trust every blog owner. Even if you could trust some people not to intentionally try to hack your computer, you cannot trust everybody to not stupidly install malicious software from a very convincing hacker, providing one more "gotta have this" blog accessory.

And since you cannot trust the individual blogs, you will have filters. And those filters have to be adjusted, to trust your own blogs - if you want to ignore your own pageviews.

Some blog owners add security software, and don't know how to maintain the filters.

There are too many Blogger blog owners who have installed protective software on their personal computers - without knowing how to adjust the filters, in the protective software. And some of those owners think that it is a Blogger responsibility, to provide them instructions, how to adjust the protective software on their own computers - when only they are capable of knowing what they installed.

---

The new version of the Stats "Don't track" option is an improvement, because it no longer requires third party cookies - and involves the associated security risk. Unfortunately, it now requires blog owners to permit scripts, from the blogs themselves.

This is not a security risk, in that only personally owned blogs need to be trusted - but the blog owners do need to know how to adjust the filters involved. And not everybody with a computer knows how to configure their security accessories.

The New Stats "Don't track" Option, And Script Filters

The new Stats "Don't track" option is an improvement, to many blog owners.

"Manage tracking your own pageviews", as before, starts from the Stats dashboard page. The wizard now runs from a sub directory of the blog managed by the dashboard - and uses a normal (first party) cookie.

Now, blog owners no longer must enable third party cookies, to make Stats ignore their page views. This is an improvement - but it can still present a challenge, for some blog owners.

Besides filtering "third party" cookies, not all blog owners and readers will permit complete control by content under the individual blogs.

If you want "Don't track" to work reliably, enable scripts for the blog URL.

If you want the "Don't track" option to work reliably for your blog, you now must enable scripts to run under the published URL.

We have to trust scripts run from "blogger.com" - that is the Blogger dashboard. The Blogger dashboard is produced by Blogger Engineers - and if we trust Blogger to host our blogs, we have to trust their code.

Scripts which run under the individual blogs - "blogspot.com", local country domains, and custom domains - can be added by the owner of each individual blog. Not all blog owners should be trusted.

People who mistrust third party cookies may also mistrust scripts which run under "blogspot" etc. Unfortunately, to make "Manage tracking your own pageviews" work, you (the blog owner) now have to open up any script filters, which block content run as part of your blog.

Start from the Stats dashboard page.

Click on "Manage tracking your own pageviews".



"Manage tracking your own pageviews" now runs under the blog published URL. This removes "third party" cookies from the problem.

With a custom domain published blog, you must use the wizard in "HTTP:" mode.

By default, the new wizard runs in SSL mode. This will be a problem, with blogs published to custom domains.

If the blog is published to a custom domain, you will need to change "https" to "http".

Check "Don't track my views for this blog." - then close the tab / window.



The new wizard, "Would you like to have your pageviews counted when you visit this blog?", now runs as "blogging.nitecruzr.net", for this blog.

http://blogging.nitecruzr.net/b/statsCookieManage

If you publish to a custom domain, and you can correct the URL, you will see the same, for your blog. If you publish to "blogspot", you can see the same also. This is a script - and the script is subject to security filters.

And yes, there is no "Save" button, or link. Just the box.

Don't track my views for this blog.

Click the box or don't. As soon as you click, it's set. If you change your mind - now or later - click the box, again, and clear the option.

You should trust your blog - even though you do not trust other blogs, in general.

Generally, as the blog owner, you can safely trust content run under your blog. You probably should not trust "blogspot.com", and all blog publishers, however. This means that you will require multiple filter rules - for every browser and security add-on, that contains a script filter.

• Block all "blogspot.*". (Please!).
• Permit "yourblog.blogspot.com".

If you publish to "blogspot.com", and live in a country which has a local domain, such as the UK, you need a rule to permit the local domain alias.

• Permit "yourblog.blogspot.co.uk".

If you have multiple blogs - and want to block pageviews from being counted, for each blog, you need permissive filter rules for each blog.

• Permit "yourblog1.blogspot.*".
• Permit "yourblog2.blogspot.*".
• etc.

If you publish your blog to a custom domain, you need a rule to permit the domain URL. For this blog, I need

• Permit "blogging.nitecruzr.net".

If you do not permit the proper URL(s) for your blog, you will find Stats counting your own pageviews. Possibly, this will happen even with "Don't track my views for this blog." checked. In some cases, the check mark will be cleared, when you close the window.

---

Owners of #Blogger blogs who don't want their activity tracked by Stats now see a new "Don't track" wizard. Using the "Don't track" option no longer requires enabling third party cookies - and worrying about the security issues.

Unfortunately, this now means that the "Don't track" wizard may now be vulnerable to filters which restrict scripts that run under blogspot, and any custom domains.

Comments "Lost", With Google+ Comments Selection

Besides the confusion about being in the right Circles, some Google+ comments can be overlooked, because of the comment view selector.

We see odd problem reports, in Blogger Help Forum: Get Help with an Issue.

When a friend mentioned she'd commented, I found that odd - because I couldn't find the comment anymore. It had shown up previously - but it was now gone.

The view selector is not so obvious, either. It's similar to the "Compose" / "HTML" buttons, in Post Editor.

Besides the view selector, we see another possibility for third party cookies, unwisely filtered, to cause confusion.

Displaying comments for a blog, with Google+ comments involved, requires determining the identity of the individual viewer. Viewer identity - much more specific than "blog owner" / "blog guest" - is required, to determine visibility of specific comments, published against a given blog.

Here's an example, using a post from my recipes blog.

12 comments - from Circles + Public.

Circles + Public, selected.

6 comments - from my Circles.

Circles only, selected.



Can you see the difference? Other viewers of the blog will see a completely different set of comments.

Here's a different example, from a forum topic.

The blog owner, signed in, sees a count of 27 comments.

The blog owner, not signed in, sees a count of 42 comments.



There's actually 3 possible different displays - each showing a different comment count, and a different list of comments.

1. Not signed in.
2. Signed in, looking at "Public" + "Circles".
3. Signed in, looking at "Circles" only.

One might expect #1 and #2 to be the same. In some cases, it appears that #1 displays a total comments count - though #2 and #3 display a count specific to the blog owner or reader. And I would not expect that one will actually see a precisely equal number of individual comments, displayed.

And if blog owner / reader access is affected by a third party cookie filter, both the comment count - and the list of comments displayed - will be smaller than what really should be displayed.

We now have a Rollup Discussion, in Blogger Help Forum: Get Help with an Issue, where we are requesting details from anybody experiencing mysterious loss of comments, If you are losing comments, please provide your details.

---

Owners of #Blogger blogs that use Google+ Comments don't realise how much more important their personal identity is, when looking for comments, that should be displayed with the individual posts. Personal identity is further relevant, with the "Circles" / "Public" comment selector, a feature of Google+ Comments.

And determining personal identity is affected, when cookie filtering becomes involved.

Reading List Use Requires Recognition Of The Owner

Last year, we saw a number of reports from Blogger account owners with empty Reading Lists.

When first reported, the common observation mentioned "one entry". Recently, we found out what the one entry was.

All I get is Blogger Buzz - which I could care less about!

The account owner does not know that Blogger Buzz is automatically a part of every Reading List.

The fact that Blogger Buzz is being seen indicates that the personal portion of the Reading List is actually empty. This is similar to problems removing Reading List content, and suggests that the account owner is not being recognised.

There are two possible reasons for a Reading List being completely, constantly, and inappropriately empty.

• The owner is using the wrong Blogger account.
• The browser being used is subject to a cookie or script filter.

Wrong Blogger account being used

It's not hard to recognise an empty Reading List (or one with just one entry, which was not requested).

We've been discussing problems resulting from having additional Blogger accounts (intentional or non intentional) for many years. If someone sets up a Reading List for one Blogger account, then uses a different account, there will be no Reading List for the second account.

If the owner then sets up a Reading List for a second (third, ...) account, unless very lucky, there will be tiny differences between the two Reading Lists. If the account owner is just using Blogger to read blogs - and does not own any blogs - it is possible that other accounts could be used. The owner may occasionally notice miniscule differences, but never bother to diagnose the differences.

Cookie / script filter, preventing identification

Whether the account owner is using the intended account, or an additional account - if the account can't be identified, Blogger can't generate a Reading List either.

If the script, which identifies the owner, doesn't run - or if the cookie identifying the owner can't be read - a Reading List can't be generated. Cookies and scripts can be filtered, for various reasons.

Thanks to ever changing security needs, and unannounced updates to many security products, a filter which worked yesterday may not work today. People unaware of security updates won't think to check the update log for any security product - and some may not be aware that they have security products that can cause problems.

The end result

There are several reasons for an unreliable Reading List - but this will generally result in inconsistencies over time, or partial displays. An empty Reading List has definable causes, with predictable results.

If the Blogger account cannot be recognised, Blogger won't show a Reading List - other than the sometimes unwelcome Blogger Buzz entry.

Account Owners Can't Maintain Their Reading Lists

We've been seeing suggestions, for years, that the Reading List is unreliable.

Many Blogger account owners have reported the mysterious disappearing Reading List. A few have reported a second problem - inability to remove blogs from the Reading List.

Few account owners connect the two problems. The two problems may each affect different account owners. Of the few affected by both problems, not many are likely to see them as having a common cause.

Aggressive cookie / script filters contribute to both problems with the Reading List.

Inability to identify the account owner affects using and maintaining the list.

Both the empty Reading List, and inability to remove Reading List entries, may result from inability to properly identify the account owner. Since the Reading List is unique to each account owner, lack of identification, caused by cookie / script filters, can lead to either problem.

Most account owners can recognise a problem with displaying the Reading List. This problem - even with the cause unknown - is obvious. It's not hard to recognise an empty Reading List.

What's not so obvious, though, is that an account owner, if not properly identified, can't successfully accomplish removal of a blog from a Reading List. Only the owner of the account can request removal of a Reading List entry for that account.

The dashboard Reading List - and the Followers gadget - complement each other.

The Reading List complements the Followers badge. The Followers badge, found on many Blogger blogs, lists everybody who Follows the host blog.

The Reading List, found on many Blogger account owners dashboards, list the blogs which an account owner is Following. In order to remove a given blog from the Reading List, the account owner must stop Following that blog.

You can use either a dashboard script, or a Followers GUI, to un Follow a blog.

The process for Un Following a blog starts from a link on the Followers badge, or in the Reading List. Both the link in the Followers badge, and in the Reading List, lead to scripts that are subject to cookie and script filtering.

In order for you to Un Follow a blog, using the Followers gadget on the blog, you have to identify yourself using the correct Blogger / Google account. When you remove a blog from your Reading List, you are identified by your login cookie - if the cookie is present and is readable - and if the script is allowed to run.

When the un Following is actually done will affect success of the process.

Some scripts run while the account owner is present - and those scripts may return an error message, while the account owner is watching, indicating a problem. Other scripts may run while the account owner is not present. Those scripts, when not successful because of cookie or script filters, can't display an error message, because the account owner is not watching.

In the latter case, the account owner starts the process of deleting a blog from the Reading List - and later finds that the blog was not actually deleted. And then wonders why the blog is still listed.

And this is why.

---

Account Owners Can't Remove Blogs From Their Reading Lists
http://blogging.nitecruzr.net/2015/01/account-owners-cant-remove-blogs-from.html
Account Owners Can't Maintain Their Reading Lists
http://blogging.nitecruzr.net/2015/01/account-owners-cant-maintain-their.html

Not All bX Error Codes Are Temporary

Everybody who has owned or read a Blogger blog, for more than a week, surely knows about the infamous bX codes - and has probably asked how to fix one.

Some people have fixed one - but immediately, seen another. Others have seen theirs go away, then later discovered that the blog is broken.

Some folks see the errors as major problems, others minor annoyances.

it's disheartening to see that the bx error code problems are still existing.

Not everybody realises that the codes are not the problems - they are simply a method to identify the problems. Many Blogger problems cannot be identified easily in language.

Many problems, many "solutions"
There are many known "solutions" for the codes, because there are many different problems, with many different causes. Here, we have 5 examples.

• Some codes are caused by an inconsistency in private data. These codes can generally be cleared by "clearing cache, cookies, and sessions".
• Some codes are caused by over enthusiastic template customisation. These codes can be cleared by getting a new template, or restoring the template from backup, for the blogs that are issuing the code.
• Some codes are caused by bogus custom domain addressing, for the blogs that are issuing the code. These codes can be cleared, only, by correcting the DNS addressing, for the blogs that are issuing the code.
• Some codes are caused by trying to use an unsuitable browser. Right now, Blogger does not support Internet Explorer V11 These codes can be cleared only by using a different browser.
• Some codes are caused by dodgy Blogger code. These codes cannot be solved by blog owners or readers. The bX codes, in many cases, are simply from Blogger Engineering adding "break points" into their code, so they can diagnose a known problem.

Above, we see just 5 examples. There is one rule, which you may want to consider, when diagnosing bX codes.

There are no rules, in diagnosing bX codes.

That is the plain truth.

History
Before they started issuing bX codes, Blogger would simply issue one universal error, that was incredibly annoying, to everybody seeing it.

We apologize for the inconvenience, but we are unable to process your request at this time. Our engineers have been notified of this problem and will work to resolve it.

Replacing that error, with the unique bX codes, was so simple - and elegant. The program, that issues a bX error report, simply takes the address of the failure point in the Blogger code library, where an unacceptable condition has occurred, and hashes the address into a 6 character alphanumeric code. And there is the bX code. Yes, that simple.

Blogger keeps a database listing of bX codes that are currently active, and a running count for each code. When a given code becomes more noticeable than others, an engineer simply uses the 6 character code to locate the failure point in the Blogger code library, and diagnoses the cause of the error. Fixing the code will vary, depending upon the cause of the code.

A hypothetical example
If you add an extra "<div>" tag in your template code, using the Template Editor, it's possible that the Template Editor code may detect it, and specifically advise you.

Don't add a "<div>" tag there!

In many cases, through, an extra "<div>" tag won't be noticed until you try to save the changes - or even until a reader views the blog under specific conditions. Either of the latter two cases may result in another bX code.

When you report your bX code in Blogger Help Forum: Get Help with an Issue, if other people have reported that same code, it's possible that we might have a known solution, ready for you.

Don't add a "<div>" tag, there!

In many cases, though, you will be advised to

Restore the template from backup - or get a new template from the dashbooard Template wizard.

In either case, though, the advice to get a backup or new template is not a solution - it's a workaround. The proper solution is for you to figure out what you did, that was wrong, and correct what you did.

In some cases, if we see enough of the same code, as we do now with the "bX-w7tr63", currently being reported in Blogger Help Forum: Get Help with an Issue - we may advise you.

Blogger cannot support you, using Internet Explorer, right now.

Internet Explorer V11 has too many internal changes, for Blogger Engineering to update the Blogger dashboard utilities, and remove all known problems. That may be vaguely similar to the problems where we alternately advise.

Restore the template from backup - or get a new template from the dashbooard Template wizard.

In either case, we provide most advice based on feedback from other blog owners.

Reality
Be aware that each bX code may have a different solution. Be wary of advice that simply instructs.

Most bX errors are temporary and will usually go away on their own.
You may read [FAQ] What Are The Mysterious bX Codes? and try clearing your cache and cookies.

Some errors may go away, on their own - but most require somebody to take some action. Not all that many are temporary.

Confusion From Comments And The CAPTCHA

This week, we're seeing complaints from quite a few angry blog owners, in Blogger Help Forum: Get Help with an Issue.

Why do I have to solve a CAPTCHA, to comment on my own blog?

and

Everybody sees a CAPTCHA - even if they are logged in to Blogger!

Previously, the CAPTCHA was visible only to those not logged in to Blogger, or to those wishing to comment, anonymously.

It appears that the full page and popup window comment forms were updated, possibly to make the CAPTCHA form more usable, for those blog readers who are using a computer subject to filtering of "third party" cookies.

The CAPTCHA appears to be always required.

The effect that we are now seeing is that the CAPTCHA appears to be required, for all comments, when the full page and popup window forms are used.

In some cases, even with the CAPTCHA displayed, you can publish without solving.

• If you are authenticated, the reCAPTCHA, though displayed, may not require solution.
• If you are authenticated, and a blog member, neither the ezCAPTCHA nor the reCAPTCHA should require solution.

In either case, simply compose and Publish your comment.

People who wish to publish anonymously will always have to solve a CAPTCHA.

Unfortunately, people who are publishing anonymously will still need to solve the CAPTCHA. The non optional reCAPTCHA, which gets displayed, is not as easy to solve as the optional ezCAPTCHA.

Cookie filtering, once again, may be part of the problem.

To increase the confusion, people using a computer where "third party" cookies are filtered will be treated as if they are publishing anonymously, and will have to solve the reCAPTCHA. Some people, who think that they are properly authenticated, will find out otherwise, if they try to publish a comment without solving the CAPTCHA.

Continuing to cause confusion, in some cases, comments entered may simply vanish, if the CAPTCHA can't be displayed when necessary. This, is another consequence of cookie filtering.

Clearing Cache Won't Always Solve Problems

Sometimes, when diagnosing a problem which involves cache, you may be advised to "clear cache" - or possibly, "clear cache, cookies, and sessions".

Instructions, to do either, may vary according to the problem being diagnosed. Unfortunately, clearing "cache" or clearing "cache, cookies, and sessions", for problems which involve cache, may not always solve the problem at hand.

If you have a problem when viewing your blog - or if you wish to immediately refresh your personal view of your blog, you might clear "cache". If you have a problem with your Blogger dashboard - maybe when switching between Draft and Production Blogger, on the other hand, you would want to clear "cookies". Whenever you clear cookies, you should clear cache, also - so, if you have a problem when maintaining or publishing your blog, you will be advised to clear "cache, cookies, and sessions".

Not all problems involving "cache" will always be solved by "clearing cache" - or even "clearing cache, cookies, and sessions". Clearing browser cache won't help, if the problem involves

• cache outside the browser being used
• cookie or script filtering

Clearing browser cache won't help, if the problem involves cache outside the browser being used. When you clear cache, you are clearing cache in one individual browser.

• If you have other browsers, or other computers, you may have to clear cache there, also.
• You cannot control cache, outside your computer.
• You cannot control cache, on your reader's computers.

There is no permanent solution, for upstream cache. But, there may be a diagnostic step, that helps us understand what is going on.

This is the URL of this blog.

http://blogging.nitecruzr.net/

If I need to access the main page, without refreshing the browser, or clearing cache, I can retrieve the updated content, on a temporary basis.

http://blogging.nitecruzr.net?

A URL containing a "?" is normally used for retrieving a web page, dynamically, with extra settings embedded in the URL.

http://blogging.nitecruzr.net?something

A dynamic retrieval is evaluated immediately, using the Blogger server (in this case) - and without any interference from any caches.

Even without a real need to have the URL evaluated by the server, we can still make the URL dynamic, just by adding the "?" at the end. And this bypasses any cache - including cache upstream from the browser.

http://blogging.nitecruzr.net?

Just remember - this is a temporary solution.

Clearing cache won't help, if the problem involves cookie or script filtering. If you clear cache when diagnosing a problem with the Blogger dashboard, a problem with commenting, or any other problem which requires logging in to Blogger, you will need to clear cookies and sessions, at the same time. This won't always be successful, even so. If a problem starts from improper filtering of private data, you won't solve anything by clearing private data.

Cookies, needed when viewing a Blogger blog, are vulnerable to "third party" cookie filters.

• A preference cookie (aka "cookie") is created under "blogger.com", where an interstitial display runs.
• A session cookie (aka "session") is created under "google.com", where you login.

Both types of cookies are read under "blogspot.com" - or under whatever custom domain, or whatever country code alias, is being used by the blog, as displayed.

Whether a cookie is needed, but non existent - or needed, but can't be read - the result is the same. The reader is unable to continue, and does not get to view the blog, when necessary.

If a problem which appears to be caused by out of date cache is actually caused by a cookie filter, and you clear cache, cookies, and sessions, you won't solve anything. A cookie, wrongly filtered, will continue to be a problem, even with cache cleared.

If a reader is subject to a filter that blocks "third party" cookies, and a preference or session cookie is needed, the reader will be unable to continue. This is a condition that Blogger Engineers cannot program around, because it is part of the security code, in the browser - and helps to protect us from malicious activity, when we surf dodgy websites.

The bottom line is you need to know when to clear cache (and cookies and sessions), in your browser - when you need to clear cache, elsewhere - and when you need to check your cookie and script filters. None of the 3 makes either of the other 2 redundant - advice given in Google - Blogger Help: Fix a Blogger error notwithstanding.

Comments, Owner Choices, And Reader Choices

Much of what we do in life - and what we do when using Blogger - is based upon, and limited by, choice.

Some choices we get to make, for ourselves. Other choices are made for us, by people who make their own choices.

Some blog owners do not want their readers to have to login to Blogger, to comment on their blogs. Other blog owners do not want their readers to have to solve a CAPTCHA, to comment on their blogs.

A few blog owners do not want their readers to have to do either.

It seems anyone who wishes to leave a comment, will have to do some form of login, either via Google or a CAPTCHA, to do so! Is there a reason for this, would it not be easier, for anyone to just leave a comment?

And the answer here is simple.

It would be easier, if neither were required.

But reality - involving activity by spammers, and activity to counter spammers - leaves some of us with less choices.

Long ago, Blogger allowed anonymous comments, without a CAPTCHA to solve. Spammers benefited from that possibility.

Later, Blogger added the ezCAPTCHA, to be required at the owners decision. Some owners chose to not select the CAPTCHA, because their readers were inconvenienced. Spammers continued to benefit from blogs which allowed anonymous comments, and no CAPTCHA.

Recently, Blogger added the non optional reCAPTCHA. This requires anybody not logged in to have the choice - login, or solve a CAPTCHA.

Unfortunately, the latter change made the third party cookie filter issue more critical. People who are already logged in, but are subject to third party cookie filtering, have to login, or solve a CAPTCHA. This requirement may vary, according to the variant of the commenting form, used by the blog.

Now, a blog owner has 4 choices, to control anonymous comments.

1. Don't allow anonymous comments, and don't require a CAPTCHA. People who are not logged in will have to login, to comment.
2. Don't allow anonymous comments, but require a CAPTCHA. People who have not logged in will have to login, and solve a CAPTCHA.
3. Allow anonymous comments, and don't require a CAPTCHA. People who have not logged in will have to either login, or solve a CAPTCHA.
4. Allow anonymous comments, and require a CAPTCHA. People who are not logged in will have to solve a CAPTCHA.

Some people will have to either login, or solve a CAPTCHA, to comment. Depending upon what choices are made by the blog owner, the readers may have any 2 of 3 choices.

1. Solve a non owner optional reCAPTCHA.
2. Solve an owner optional ezCAPTCHA.
3. Login.

You'll like the ezCAPTCHA a lot more than the reCAPTCHA.

People who are logged in to Blogger / Google, and are not subject to third party cookie filters, may not see a CAPTCHA - and will not have to login to comment. People who are logged in, but are subject to third party cookie filters, will have to either login, or solve a CAPTCHA.

Owners of blogs which attract readers, who choose to maintain their cookie filters, will benefit more from the new CAPTCHA, than owners of blogs which attract readers who do not choose - or do not care - to maintain their cookie filters.

To make the choices easier to understand, Blogger would have to make "Require CAPTCHA" a binary option, for at least 3 comment authentication levels.

1. Anonymous.
   • Require CAPTCHA.
   • Don't require CAPTCHA.
2. OpenID.
   • Require CAPTCHA.
   • Don't require CAPTCHA.
3. Google account.
   • Require CAPTCHA.
   • Don't require CAPTCHA.
4. Members.
   • Require CAPTCHA.
   • Don't require CAPTCHA.

If Blogger were to offer this binary option, too many owners would select "Anonymous" / "Don't require CAPTCHA" - and spammers would continue to flood the spam filters - as they were, before the latest update.

As long as spammers choose to do business - and choose to target our blogs, in their business - our choices, as blog owners and readers, will be limited.

>> Top

Clearing Cache, Cookies, And Other Website Data

Most of us, as we surf the Internet, are going to surf some websites, repeatedly.

Everybody has favourite websites. When we surf the same website, over and over, some of what we do and see may not change a lot.

To keep us from wasting our time, and generating unnecessary network traffic, our browsers keep track of the websites that we visit over and over, save records of what we do and copies of what we see, and note what has changed. The website content, stored locally, is known as "private" data.

There are times when we need to clear "private" data. Note the different browsers - and the different menus and selections, provided by each browser.

• If you have a problem when viewing your blog - or if you wish to immediately refresh your personal view of your blog, you should clear "cache".
• If you have a problem maintaining or publishing your blog - maybe when switching between Draft and Production Blogger, you should clear "cookies".
• Whenever you clear cookies, you should clear cache, also - so, if you have a problem when maintaining or publishing your blog, you should clear "cache, cookies, and sessions".

There are other reasons for clearing private data - but there are also reasons for not clearing private data, indiscriminately. It will be worth your time, to understand what and when you should clear - and not clear.

Normally, you would not, routinely, clear private data.

What if you use a publicly shared computer - maybe in a coffee shop or library? Or maybe, you carry your computer to a coffee shop or library? Do you want your private details - such as account names, passwords, even a list of what websites you surf - being available for other patrons of the coffee shop or library, after you leave?

Most of us do not want our private details, visible to any curious fellow patron - or maybe to our family either. But not all data is equally as damaging, if revealed to strangers, or to people who know us.

To help us keep our private lives private - yet not waste time or generate unnecessary network traffic, our browsers offer us the opportunity to save some content, and to delete other content - when we know what options are available to us.

• Cache.
• Forms.
• History.
• Passwords.
• Preference cookies.
• Session cookies.

Cache is simply locally stored copies of code and static pages, that you and other people, using the computer, might accumulate. Cache contains no sensitive, personally identifying material - other than (again) possibly identifying what websites you have visited.

If you share a computer with another person, identifying what websites you visited, and what websites the other person visited, will require knowing times each of you used the computer. There are no personal identifiers which indicate which of you visited a given website.

Forms contain online entered data, such as account names. Forms are slightly less sensitive than passwords, since they may contain large volumes of random data. Look at the boxes in the Blogger dashboard - those are all forms. Hidden in the forms, you may find an account name - or an email address. It's like asking how dangerous a needle may be, in a stack of hay.

History is a log, describing what websites, and website pages, that you have visited. History might be important if having people, other than you, know that you visit certain websites; other than the personal embarrassment possibility, history is relatively harmless.

Passwords are the most sensitive bit of data, that you can store on your computer. Someone extracting your passwords, on a per website basis, can use your account in each website, to operate as you. An online password is just as sensitive as the password (aka "PIN") that you might enter at an ATM.

Preference cookies (aka "cookies") are local storage of website relevant details. Preference cookies are miscellaneous settings, used to remember choices which you might make, when viewing a given website, repeatedly. Some browsers identify "preference cookies", and "session cookies", collectively, as just "cookies". Firefox, in various places, identifies "preference cookies" as "cookies", and "session cookies" as "sessions".

Session cookies (aka "sessions") are a cookie, designated by some browsers, as containing login identifiers, and other data relative to one website visit (but let you extend one "visit" to include multiple browser openings and closings). Firefox designates the Blogger login cookie as a session cookie. This is why, when I advise you to clear Blogger dashboard problems, I always specify clear "cache, cookies, and sessions".

In order of sensitivity, I would rank the above elements in a different order.

• Passwords.
• Forms.
• Session cookies.
• Preference cookies.
• History.
• Cache.

Look at cache, to start. Cache is locally stored copies of content, from remote servers. Other than inadvertently revealing our favourite naughty content, there is no danger in cache content being seen to other people. There are three scenarios, when we might want to clear cache.

• To clean up the computer, when it is running slower than normal.
• To provide an up to date copy of a website, immediately.
• When investigating a website login problem, such as a Blogger dashboard problem, which requires clearing cookies.

Cache takes up thousands as much space as cookies, and as passwords.

At the other end of the sensitivity scale, you find Passwords. My personal advice is to not store passwords, period. If you want convenience when accessing a website like Blogger, which offers long term login sessions - when you use a private and safe computer - simply don't log out, from Blogger. If you never clear session cookies, you never have to log out.

If you enjoy the convenience of online banking, on the other hand, you should always log out after an online banking session. If you never store passwords, for online banking, you never have to worry about clearing passwords.

In the middle of the scale, we find Cookies. A cookie is a small, encrypted file, which contains a single setting that lets us visit the same website repeatedly, without having to re enter something.

The Google login cookie (aka "session" cookie) lets us visit Google (and Blogger), and maintain our blogs, without having to login, over and over. This is the infamous "third party" cookie which we need, to use Blogger readily.

Cookies, since some provide login data, are encrypted. Open a cookie file, using a text reader, and see what is there (But do not use "Save" to close the text reader), if you wish to understand.

If you have a problem when viewing your blog - or if you wish to immediately refresh your personal view of your blog, you might clear "cache". If you have a problem with your Blogger dashboard - maybe when switching between Draft and Production Blogger, on the other hand, you would want to clear "cookies". Whenever you clear cookies, you should clear cache, also - so, if you have a problem when maintaining or publishing your blog, you will be advised to clear "cache, cookies, and sessions".

If you have inconsistent private data (cookies don't properly match cache or scripts), you may have to deal with one of the mysterious bX codes. When this happens, then clearing "cache, cookies, and sessions" may be one of the first things to try.

Note that not all problems involving "cache" or "cache, cookies, and sessions" may be solved by "clearing cache" or even "clearing cache, cookies, and sessions". Some problems may require corrected filtering. Also, not all problems, that involve cache, can be necessarily solved by clearing browser cache.

All of these are personal preferences, which I exercise - when using my own personal computer, in the privacy of my home. Other people may be more strict - or some computer owners may never clear anything. When using your computer outside your home - or maybe, when using a public computer - you may wish to be more careful.

My personal advice, for using a public computer, is simple.

• Never, except in an absolute emergency, use a public computer for online banking.
• Whenever finishing a session on a public computer, always clear all private data, and restart the computer.

Some short term use public computers, such as stand up terminals in libraries and shopping centres, are specially designed to reload the entire system configuration, and operating system, and wipe all "private" data, after each individual person has used the computer. If you must use a public computer, those would be the safest ones to use.

Similarly, if you carry your own computer outside your home, you may be concerned with other people seeing what's on your computer, intercepting your network activities (if you use a public network), and / or stealing the computer. Depending upon which possibility concerns you, you might take any or all precautions, before carrying the computer out the door.

• Clear passwords (if you store passwords, locally).
• Clear history and cache (if you fear people browsing your computer).
• Clear all private data (if you fear theft).

Who knows what embarrassment (financial, and personal) you might save yourself, by thinking ahead?