The "w i d g e t s e r v e r" Abandoned Domain Is Now Malicious

We've been dealing with a minor recent deluge of reports, from blog owners reporting mysterious redirection of their blogs.

The original typical report, which started like any report involving a respected Internet service going out of business, was annoying - yet benign.

Today, the status changed to malicious.

Right now, "w i d g e t s e r v e r . c o m" is redirecting to "l i b o s t u d i o s . com".

Please enter your email address to continue.

Many gadgets, long known for redirecting, are again redirecting - recently to "w i d g e t s e r v e r . c o m" - and now to "l i b o s t u d i o s . c o m". As some were diagnosed, a few owners advised that the misbehaving gadget had been installed long ago.

We've seen, so far, a few old (not!) friends. M a u k i e , N e o C o u n t e r, and "S u n a n d M o o n P h a s e" can be seen, in some topics.

A brief sample of forum topics involving "w i d g e t s e r v e r . c o m" mention gadgets previously installed by Blogger, using the "Add a Gadget" wizard. Recently, Blogger cleared out the third party gadgets from "Add a Gadget" - and the gadgets rejected by Blogger are now hosted by ""w i d g e t s e r v e r . c o m". And they are malicious.

We will not sell, rent, or share, your email address. Your privacy is important to us!

Yeah, right.

And what will you do, with my email address?



What more should be said?

---

For a week, we've been dealing with #Blogger blog owners reporting mysterious redirecting by their blogs. Many helpers have dismissed the issue, as another popular third party gadget publisher gone out of business.

Today, the redirection changed - to an email mining op.

The Blogger / Google CDN, And Logout Problems

Recently, we've been seeing queries from some anxious blog owners

Why should I have to sign out a total of three, four, or more times?

With blogs that use a template that shows the navbar, the owner may logout, using the "Sign out" link - but the navbar may continue to suggest that they remain loggedin.

This problem may start with how we connect to Blogger, as part of the mysterious Internet cloud.

Blogger provides multiple connection points ("nodes") to their databases, through the Blogger / Google Content Distribution Network ("CDN"), in many different cities worldwide.

Generally, a blog owner will connect to Blogger, using the closest CDN node. Thanks to Internet Protocol networking with Multipath Routing, the "closest" node won't always be the node with the shortest distance, "as the crow flies", from the owner.

Determining logical distance between 2 computers involves more detail than simple geographical distance. Some blog owners will be equally "close" to multiple nodes - and this is where the problem starts.

All Blogger databases, in all CDN nodes, won't update immediately.

If a blog owner logs out from Blogger, when connected to one node, the Blogger database in other nodes won't always be updated immediately, to reflect the log out status. The CDN nodes update each other periodically - and there is always going to be some delay between updates.

The logical distance between a blog owner and a nearby node can change - and a different node may become "closer", at any time. With multiple nodes equally "close", the slightest change in the network between the blog owner and any "close" nodes can make the blog owner connect to a different node. The blog owner can fluctuate between 2, 3, or more "close" nodes, within seconds.

If the blog owner logs out while connected to one node, then re connects to a second node - before the first node updates with the second - the owner will appear to be still logged in.

Different CDN nodes may show a blog owner as logged in, until updated.

In some cases, the owner can continue to appear as "logged in", when connected to a different node. After logout (log out, signout, sign out) using the "Sign out" link, and the display refreshes, the navbar status will continue to display the account name and "Sign out" link.

Some blog owners will be equally "close" to multiple nodes. They may go through 2, 3, or more sign outs - until all nearby nodes are properly updated, or updated by repeated "Sign out".

Long ago, update delay led to a different mysterious problem.

Long ago, blog owners reported the mysterious advice

You have logged out from another location. Do you want to log in again?

Now, they continue to see the navbar "Sign out" link.

This monolithic error used to make many scream, in anguish.


Previous advice, to workaround the mysterious "You have logged out from another location. Do you want to log in again?", may work for the logout problem.

1. Check cookie and script filters.
2. Clear cache, cookies, and sessions (yes, all 3).
3. Restart the browser.
4. Click on the link below, to login to Blogger.
   

   https://www.blogger.com

A similar example of CDN node update delay involves post editor / template editor.

I see this problem currently, when updating posts. I update my posts, frequently - and see this error message, almost daily.

An error occurred while trying to save or publish your post. Please try again.

Post Editor, showing another monolithic error, after clicking "Update" - just as I updated this post.


There's nothing to do now, but hope for the best. The above procedure may or may not fix this problem.

Template editor will be subject to the same frustration. Any Blogger dashboard change that involves significant delay between opening and saving changes (such as editing) will have a similar problem potential. And here may be one more detail that affects stability of long term draft mode post editor sessions.

If you connect to multiple CDN nodes, while you update a post or edit a template, you end up with "conflicting edits". How should we expect the different database nodes to update each other, consistently, with different edits made to the different nodes?

Some blog owners connect through nodes in different countries.

With "nearby" nodes in different countries, it's possible that country local domains, affected by intrusive cookie or script filters, can complicate this problem. A cookie or script filter can prevent the "Sign out", until the blog owner is connected to a node in a different country.

A cookie or script filter can be a part of many network, performance, or security accessories, on the computer or network. Some filters are updated without knowledge of the blog or computer owner.

Network connections may change in milliseconds.

Multipath routing can cause network connection changes within milliseconds. CDN node updates won't be that frequent. Impatient blog owners may observe the lack of update from "Sign out", and report the problem.

Why would I have to sign out a total of three or more times?

No matter where Google locates their many nodes, some blog owners will be equally "close" to multiple nodes - and their connections can change frequently. The more equally "close" nodes, the more random path changes, and the more this problem will be seen, by different blog owners. Other blog owners won't care, because they may never see this happen.

The new "Responsive" templates may serve as a solution.

The new, "Responsive" class templates lack the navbar, and "Sign out". Blog owners, who publish their blogs to the new templates, won't use the "Sign out" link in the navbar - and they will not observe the delay in CDN node updates.

---

Some blog owners report that after logging out from #Blogger, the navbar continues to show that they remain logged in.

Thanks to the Blogger / Google Content Distribution Network, where an owner can connect to any of many different nearby CDN Nodes, this will probably always be with us.

Adding Whitelist Entries, To Adblock Add-Ons

Ad blockers are popular Chrome add-ons, which let us manage various websites abilities to serve ads in our browsers.

Many ad blockers include a script blocker. Like NoScript in Firefox, ad blockers may interfere with various Blogger features - such as the "Don't track" script, in the dashboard.

If you publish a Blogger blog, and you have a problem with any pages in the Blogger dashboard, you will want to whitelist "blogger.com" in your ad blocker.

You will do better if you not whitelist "blogspot.com". BlogSpot includes many Blogger blogs - and third party code on those blogs. If you are not very picky about what Blogger blogs you view, you won't do well permitting scripts on every Blogger blog.

Adblock Plus is an extension, in Chrome.

I use "Adblock Plus" as an ad blocker, on my Chrome installations. "Adblock Plus" installs as an app, or an extension.

There are several ad blockers available, for Chrome.



I use the "Adblock Plus" extension, in my Chrome installations.

Start with "More tools" - Extensions.

Select "Options" for "Adblock Plus".

Adblock Plus "options" are also accessible from the browser toolbar. Right click on the ABP icon, and select "Options".

Select the "Whitelisted domains" tab.

Let's whitelist "addthis.com".

Paste / type "addthis.com" into the box. Hit "Add domain".

And now, "addhis.com" is whitelisted.



And having whitelisted "addthis.com", I can support a useful third party social sharing blog accessory, by permitting ads that they host.

---

Some #Blogger blog owners use ad blockers in their browsers - and see problems with using various Blogger features. The Stats "Don't track", for instance, is vulnerable to ad blockers, and similar filters.

Fortunately, it's not difficult to whitelist "blogger.com" in your adblocker.
target="_blank"

Custom Domain Publishing And Private Blogs

We see an occasional report in Blogger Help Forum: Get Help with an Issue, about custom domain publishing.

My readers can't view the blog - they get a redirection count error!

DNS analysis shows a properly setup domain. When we try to examine the blog, we see a private blog notice - or we are required to login.

But why a private blog, using a custom domain?

The purpose of publishing to a custom domain is to increase readership - by making a blog more visible, using a non BlogSpot URL.

A private blog has limited readership, based on permissions provided by the owner. The need to make a blog private conflicts with the need to increase reader population.

Besides the functional conflict, there's a second problem with combining a custom domain published blog, and access by invitation. Both the custom domain redirection, and the private blog redirection involve interstitial code.

This is a private blog. Combine this, and a custom domain redirection - and you get trouble.



A potential blog reader, when accessing the blog by the BlogSpot URL, will redirect to the domain URL - and then to the access checking interstitial. Some browsers will interpret this as a possible security issue, and cite

Too many redirections!

In other cases, the two redirections may lead to a redirect loop - and the reader will see a white screen of death.

What ever the result - "Too many redirections", or a redirect loop, the potential reader will never see the blog.

If you want to publish a blog, and limit reader access by invitation, you're better off publishing to BlogSpot. If you want to use a non BlogSpot URL, a public blog makes sense.

---

You are allowed to publish a #Blogger blog with a designated reader population - and you're allowed to publish a blog to a non BlogSPot URL.

You can publish a private blog to a custom domain, if you wish - but this is not recommended. Learn why combining limited access with a non BlogSpot URL is not a good idea.

https://productforums.google.com/forum/#!category-topic/blogger/5IUByvxKYeg

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.

HTTPS Availability For All "blogspot.com" Blogs

The rollout of SSL, for "blogspot.com" published blogs, continues.

All "blogspot.com" published blogs will now offer HTTPS connectivity, to the reader. The choice, offered to the blog owner, is now whether to force every reader to use SSL - and the dashboard option is now labeled "HTTPS Redirect".

You can force your readers to use SSL, to access your blog - but will that make them more secure?

Every blog will offer SSL connectivity, to readers who use "HTTPS:" URLs.

The dashboard option is now "HTTPS Redirect".

The choice is now whether to force "HTTPS:" upon each reader - or allow some to continue to read, using "HTTP:".



If you select HTTPS Redirect, you will be limiting your reader population.

Some readers access our blogs, by using free proxy servers - and most proxy servers, when they offer HTTPS, offer it as a premium (with a paid subscription). You are entitled to require everybody to use SSL, if you wish - but you may see reader activity drop, as readers using free proxies find other blogs and websites to read.

Everybody will see the "HTTPS:" alias - with "HTTPS Redirect" set to "Yes".



My personal favourite connectivity diagnostic tool, Rex Swain HTTP Viewer, won't work with blogs that only support "HTTPS:" connectivity.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://nitecruzr-test-ssl.blogspot.com/&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

No "HTTP:" diagnostics, for "HTTPS:" redirected blogs.



The "www" alias of a "blogspot.com" published blog will not work, using SSL.

Using the "www" alias, of a "blogspot.com" URL, will not work - with "HTTPS Redirect" set to "Yes".



Forcing SSL will not make your blogs readers more secure.

Use of "HTTPS Redirect", while nominally making your readers more secure, will limit access to your blog.

• Readers, using proxy servers, may not be able to access your blog.
• Diagnostics of blog problems, using proxy servers, will be limited.
• Readers who bookmarked your blog, using the "www" alias, will not be able to access it.
• Readers who are vulnerable to hijacking, when using "HTTP:", will not access your blog.

Offering SSL connectivity is good for everybody - but understand the limitations.

Enjoy offering SSL connectivity - and improved search engine reputation. But keep it in perspective.

People who explicitly use "HTTP:" to access your blog, and are vulnerable to hijacking, will see an imposters blog - even if your blog forces them to use SSL. Only people who explicitly use "HTTPS:", to access your blog, will predictably see your blog - and they won't benefit from being forced to use SSL.

---

As #Blogger continues the rollout of SSL to "blogspot.com" published blogs, they have changed the HTTPS option. All blogs which support SSL will offer "HTTPS:" connectivity, and the option will be to allow explicit access, using "HTTP:".

You may do well to consider what benefits you get, from forcing your readers to use SSL to access your blog.

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.

Now, You See It - Now, You Don't

Some blog owners create a post, with content that should be visible, only when required.

The post contains a question - accompanied by the answer to the question. The question should be viewed, without the answer being visible, to make the reader think about the answer. This is called, by many, a "spoiler".

Not everybody knows how to construct a spoiler. Some blogs use JavaScript - painful to construct, and maybe not effective for every reader. Security conscious blog readers may block scripts from Blogger blogs - and either your spoiler is visible, immediately - or never becomes visible.

Neither of the latter scenarios make the post a lot of fun to read.

You don't need JavaScript, to make a spoiler.

This is fortunate, because not every reader is going to allow scripts, from every blog. Personally, I block JavaScript, in general - and enable only for my own blogs - and for specific websites, like the Blogger dashboard and most Google pages.

If the blog posts have a solid white background, you make the post text white.

Examine a post, in my text blog.

Two spoilers - both blank.

Click and drag across the first spoiler - and see the first answer.

Click and drag across the second spoiler - and see the second answer.



The spoiler code is not complicated.

What would YOU do?

What Lancelot chose is hidden. But - make <span style="font-weight:bold;">your</span> choice before peeking. To see the answer, highlight the area indicated, by clicking the mouse and dragging the cursor between the arrows.

The answer is here ==><span style="color: rgb(255, 255, 255);">Noble Lancelot said that he would allow <span style="font-weight:bold;">her</span> to make the choice herself. Upon hearing this, she announced that she would be beautiful all the time because he had respected her enough to let her be in charge of her own life.</span><==

Now - what is the moral to this story? To see the answer, highlight the area indicated.

The answer is here ==><span style="color: rgb(255, 255, 255);">If you don't let a woman have her own way, things are going to get <span style="font-weight:bold;">ugly</span>.</span>==

Hoping that your blog does not use a semi transparent floating background over a multi colour background, just make the text the same color as the background. Then, instruct the reader to click and drag the cursor, to highlight and make the spoiler visible.

---

A #Blogger blog post which contains a question and answer section is fun to read - but not every blog reader will benefit, with posts that use JavaScript, to hide text content.

An easy way to hide content is to make the text the color of the background. The reader can click and drag, to highlight the text, when then is visible.

http://blogging.nitecruzr.net/2011/10/cookies-vs-scripts-two-types-of-server.html

http://blogging.nitecruzr.net/2009/04/many-faces-of-google.html

</span>

Avoid Use Of FeedBurner "Password Protector"

Some Google products contain features that have limited usefulness, when applied to Blogger blogs.

FeedBurner has a feature, "Password Protector", which may be useful, to newsfeed readers that support HTTP authentication. Within FeedBurner, we have the "Email Subscriptions" service - which does not support feed authentication.

Your readers will be required to use newsreader or aggregator software that supports authentication to view your feed.

Some Google, and non Google, services will have a problem, with a FeedBurner protected feed.

Newsfeeds, published by Blogger blogs, are supposed to be publicly accessible.

A blog with designated readers will not produce a newsfeed. Blogger does not support authenticated newsfeeds.

To use Password Protector, look on the FeedBurner dashboard, under the Publicize tab, for "Password Protector". Enter a Username and a Password, and hit "Activate". But don't do this, without knowing the downsides.

Password Protector uses a single username / password combination. All blog readers will use the same username.

FeedBurner warns us of possible problems, caused by this service.

Important: This service prevents our Email Subscriptions service from delivering email updates from your feed, and it will also password protect your feed's content when redisplayed using our Headline Animator graphic. This graphic itself becomes password protected, which is undesirable if you wish to use it to promote your site/feed. Therefore, we recommend not using Headline Animator or Email Subscriptions, and this Password Protector service, with the same feed.

From what I can see, Blogger Reading List may ignore the authentication requirement. People may use Reading List, and view the blog feed, redirected through FeedBurner - even if not authorized.

We know, however, that email subscriptions will not work, with a protected feed. Looking at an HTTP trace of the feed from my test blog http://techdict.nitecruzr.net, we see a symptom of the problem, with this option.

http://techdict.nitecruzr.net/feeds/posts/default

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://techdict.nitecruzr.net/feeds/posts/default&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Sending request:

GET /feeds/posts/default HTTP/1.1
Host: techdict.nitecruzr.net
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7834.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 74.125.28.121

• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·302·Found(CR)(LF)
ETag:·W/"32e869db-18a9-4ccf-8ad9-dbded29f2b25"(CR)(LF)
Date:·Wed,·27·Apr·2016·15:04:06·GMT(CR)(LF)
Content-Type:·text/html(CR)(LF)
Server:·blogger-renderd(CR)(LF)
Expires:·Wed,·27·Apr·2016·15:04:07·GMT(CR)(LF)

Cache-Control:·public,·must-revalidate,·proxy-revalidate,·max-age=1(CR)(LF)
X-Content-Type-Options:·nosniff(CR)(LF)
X-XSS-Protection:·1;·mode=block(CR)(LF)
Location:·http://feeds.feedburner.com/ChucksTechWorld(CR)(LF)

This appears to be just a redirected blog posts newsfeed, targeting a FeedBurner published feed.

Here, we see a normal redirected blog posts feed.

But what happens, when we try to open the feed?

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://feeds.feedburner.com/ChucksTechWorld&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=TXT

Sending request:

GET /ChucksTechWorld HTTP/1.1 HTTP/1.1

Host: feeds.feedburner.com
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7834.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 172.217.0.14

• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·401·Unauthorized(CR)(LF)

WWW-Authenticate:·BASIC·realm="FeedBurner·feed·ChucksTechWorld"(CR)(LF)

The "HTTP Viewer" service does not support feed authentication (and only works with "HTTP:" protocol). And, we see the result.

It's possible that this feature will be useful, with feeds that are used outside Blogger (noting the Reading List ability). If you're publishing a Blogger blog, however, you're not likely to get any useful result.

---

Owners of #Blogger blogs, which use the FeedBurner "Password Protector" service, may find that the service delivers less protection - and some interference - other than the service name suggests. It would probably be best to avoid use of this service.

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.

CloudFlare, Custom Domain Publishing, And HTTPS

A few blog owners, who publish blogs published to custom domains, are becoming impatient, waiting for Blogger Engineering to finish the Blogger upgrade to support HTTPS / SSL.

If I get a domain through Google Domains, will I be able to get HTTPS?

Unfortunately, no. HTTPS / SSL is simply not available, to blogs published to custom domains.

HTTPS is not available, for non BlogSpot published blogs.

Whether registered by eNom, GoDaddy, or Google Domains, it simply is not possible to publish a non BlogSpot URL as a supported custom domain, and make HTTPS / SSL available. CloudFlare, a supposed alternative, does not produce a supported custom domain.

A proxied CloudFlare domain looks like malicious redirection.

In some cases, a CloudFlare DNS "solution" tried by some blog owners, will look like dangerous / malicious redirection. Some blogs will show up as "Deceptive sites", aka "phishing".

Some blogs using CloudFlare, for custom domain publishing, will be classified as "Deceptive" sites.



Others will produce alarming warnings about malware.

"This blog is not hosted by Blogger and has not been checked for spam, viruses and other forms of malware."

Click on "Details".



Look at the warning.

Phishing sites pretend to be other websites to trick you.

And there is the typical Dig log, with a redirecting proxy service, like CloudFlare.

kireisubs.id. 300 IN A 104.27.133.198
www.kireisubs.id. 300 IN A 104.27.133.198

or

topmovies21.biz. 300 IN A 104.28.0.106
www.topmovies21.biz. 300 IN A 104.28.0.106

This is the basis for malware / phishing classification.

Any observed malware warning is generally a false positive - most custom domain published blogs do not contain malware. Even so, it's not likely that the "Deceptive site" classification will be easily corrected - or the malware warning interstitial display removed.

And this is one more blog owner, who must next be provided instruction to correct the DNS addresses.

Having corrected as instructed, DNS addresses will be asymmetrical, and righteous.

kireisubs.id. 86400 IN A 216.239.32.21
kireisubs.id. 86400 IN A 216.239.34.21
kireisubs.id. 86400 IN A 216.239.36.21
kireisubs.id. 86400 IN A 216.239.38.21
www.kireisubs.id. 86400 IN CNAME ghs.google.com.

With DNS corrected, Google shows "Not dangerous" - but the warning still displays.

"Not dangerous".

Note "CloudFlare" is still seen as the host.

You can report an error, to SafeBrowsing.



False classification now requires time consuming site review.

Use "Report Incorrect Phishing Warning", if you believe the site is safe.

Finally, get the site reviewed, from the Security Issues page in Security Console (Webmaster Tools) - Security Issues.

And while the blog remains offline, search reputation - and the owner - will suffer.

---

Some #Blogger blog owners want to provide blogs published to custom domains - and offer HTTPS connectivity. Since Blogger cannot provide custom domains with HTTPS right now, the blog owners are using CloudFlare, which provides an HTTPS proxy.

Unfortunately, a CloudFlare proxy looks like malicious redirection - and blogs using CloudFlare are being labeled as "Deceptive" sites.

https://productforums.google.com/forum/#!category-topic/blogger/ApuJ58a4-kg

https://productforums.google.com/forum/#!category-topic/blogger/-LoJCeX6DEA

https://productforums.google.com/forum/#!category-topic/blogger/DhAFOtJFoCw

Blog Security Review Is Not Instantaneous

Blog owners do not always understand the reasons behind the mysterious blog security check (following "suspicious" / "unusual" activity account lock).

We see periodic complaints about deleted blogs and locked accounts - and the inconvenience involved, in Blogger Help Forum: Get Help with an Issue.

I get the security and all - but I don't get how a blog is just deleted.

This blog owner, like so many, does not understand how Blogger is trying to keep our blogs under our control - even after detection of "suspicious" / "unusual" activity.

Blog security check, if immediate and instantaneous, would not be noticed.

Blog security check is an art - not a science - and it takes time.

If blogs could be checked for hacking interference without delay, most owners would not complain. Unfortunately, examining blogs for hacking interference requires intense study - and most security experts do not work on weekends.

One unfortunate issue, about all of this, is that not all "suspicious" / "unusual" activity is malicious. Some of it is a simple result of people unable to use account / blog recovery - being innocently told to try every account name and password that can be remembered.

Owner delay, in requesting account unlock, contributes to security check delay.

In some cases, the locked account / deleted blogs may not be immediately discovered by the owner - and this may lengthen the security check process.

Not all blog owners publish - or even read - their blogs regularly. Nor do they accept the need to intentionally keep their account and blogs under their control.

Some owners are very casual about blog security - until a blog is successfully stolen.

---

Some #Blogger blog owners are not terribly impressed by the need to keep their blogs under their control, until a blog is stolen. The measures taken by Blogger / Google Security staff are considered mere annoyances.

Please, Don't Try Guessing Your Account / Password!

We see too many problem reports, in Blogger Help Forum: Get Help with an Issue, about locked accounts and deleted blogs.

My Google account was suspended because of 'suspicious activities'. Last month, I realized that my two connected blogs, to that account, were also put offline!

Somebody else was unable to use the supplied account / blog recovery tools - and tried guessing what could not be remembered.

The first would be a blog owner, whose only mistake was having a Blogger account with a name similar to another account, owned by the second.

The second would be someone who could not remember her (his) account name / password, could not use account or password recovery, and who got well meaning advice.

Just do the best you can - try what may be your account name, and any passwords that you can remember!

One blog owner must suffer, because another cannot remember login details.

And owner #1 is suffering, because of owner #2. Owner #1 is now anxiously waiting for action by the security experts (with the blind queue of unknown length) to examine his blogs - and possibly, waiting while not knowing why.

Owner #1 may be seeing this - and not know why.



Password guessing may be necessary, in extreme cases - but it can cause misery - and owner #2 will never realise the pain caused to owner #1. Even if owner #2 recovers access to her / his blogs, innocent brute force attempts can cause account lock / blog security lock, to owner #1.

Protect yourself against the anguish, using Google 2-Step Verification.

The best way to protect against this sort of abuse is to use one or more Google Two Step Verification options. This will leave owner #2 seeing (for instance).

Insert your USB security key, and tap the lighted button.

And having no security key, owner #2 will simply have to try guessing a different account name. It may be an inconvenience (for owner #1), carrying a never used USB security key - but the one time it's needed (and available), it will make up for the inconvenience.

---

One #Blogger blog owner, unable to remember a necessary account name or password, may try guessing what cannot be remembered. Guessing an account name can leave one trying an account that somebody else owns - and can cause account lock and blog deletion for somebody who they will never know.

Train Security Products, And Keep Your Blog Clean

Everybody who uses a computer - and expects to use their computer for any amount of time - has one or more protective products on their computer.

Anybody who publishes a blog, with an audience that has any need for security, is going to receive occasional reports from would be readers.

I can't read your blog! My computer displays an "Unsafe website!" warning!

All computer security products, unfortunately, will occasionally generate false positives. Analysing false positive malware reports is as much a part of every security product, as identifying the actual malware.

If you publish a blog, you need to know how to handle reader malware alert reports.

Know online tools, for researching reported problems.

Google provides 2 websites, for analysis of blog / website malware alerts. Both Google SafeBrowsing, and VirusTotal, are Google products that can help to identify actual problems with blogs and websites.

Besides the two Google products above, I use 3 security analysis websites, which can identify specific security problems in blog / website code. Quttera Online Website Malware Scanner, and Sucuri SiteCheck, and Trend Micro SIte Safety Center, have been useful at various times, when a security problem is reported.

You may, from time to time, use all of these - and possibly others - in identifying and verifying a security problem with your blog, or with blogs and websites that you link. For best results, always specify the canonical blog URL, when requesting security analysis - and when sharing the blog, or individual posts.

Specify the canonical URL.

Not a country local domain.



Know what you need to do, to keep your blog healthy.

As a blog publisher, you will occasionally have 2 jobs to do, when receiving a malware alert report which references your blog.

1. Verify / identify / remove any actual malicious content.
2. Report false positives, to the protective service displaying a false positive.

Everybody who publishes a blog, with any reader audience, has seen this advice, or something similar, when surfing their blog.



Know how to keep your blog clean - and your reputation clean.

You have to use online malware analysis services, to identify any problem which you may have created, by installing the latest "gotta have this!" accessory on your blog. And, you have to report any false positive alert, to the owners of any security product, that falsely identifies your blog as a problem.

You do both, to support your readers. You do not want your readers computers hacked, through your inappropriately accessorising your blog - but at the same time,you want your readers to be able to read your blog.

1. Keep your blog content clean.
2. Keep your blog reputation clean.

Do both - or you may not have readers, to read your blog.

---

Any #Blogger blog owner needs to support the blog readers, by publishing a blog clean of any malware, and with a good reputation with the various security products that prevent malicious action by dangerous blogs and websites. Your readers need the ability to use their computers to read your blog - and they need their security to not falsely identify your blog as a problem.

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.