The Problem HistoryIn the olden days, long before Microsoft even came up with Internet Explorer, a browser was simply a program to display text. HTML was just text files, with links ("anchor links") to other text files. Surfing the web meant reading text, and clicking on links to read more text.
Then someone decided to add colour to the text, and someone else decided to put pictures in, to make it all less boring. That was just the beginning.
Fast forward to today.
Now, we have music and movies, delivered as both complete files and files played while you download ("streaming" content) - I listen to streamed music, like
XTC Radio London. And we have various files which appear to be either interactive movies, or video games, where you can control the movie elements / players with your mouse. Some games download to your computer and are played there, others may run from a game server. And we have still more code and scripting that nobody knows what it does. We hope that it's benign, or at least not intentionally malicious, but we're not always sure.
And some of it contains
very malicious code indeed, created by well paid criminals, and designed to
take control of your computer.
WorkaroundsSo your browser, other programs on your computer, and other network devices, contain as much code to protect your computer from malicious code, as code that actually does something useful for you.
ConundrumsAny website owner, that wants to stay in business as a website owner, has to walk a fine line.
- Include some content besides plain old text, or your readers will see it as boring, and won't return.
- Include too much non-text content, and some readers won't be able to use your website at all, because their security will block it, as possibly malicious.
Looking at it the other way, if you want to use your computer for surfing the web, you have to choose between boring (nothing but plain old text) and dangerous (exposing you to the hackers). You, too, have two extremes.
Historical WorkaroundsOriginally, securing your computer meant adding software, and setting up the new software to block specific threats. And the security experts were constantly busy, cleaning up computers whose owners had "checked out this fascinating new website" or "downloaded this great new game", without having the necessary new protection. And they were advising folks to close this security hole, or patch that setting, but after the computer had been hacked.
That strategy is called "permit by default (deny on demand)", and is one reason why propronents of alternative operating systems like Linux will sneer at Windows as insecure. Now, browsers are being released with built in protection, and with that protection activated by default. This is "deny by default (permit on demand)", and is more like Linux security.
Recent HistoryAnd there's today's problem.
Recently, Microsoft released Internet Explorer Version 7, and Mozilla Foundation released Firefox Version 2. Both browsers contain protection activated by default, protection that would have been activated (if even available) only upon demand, in previous versions.
The browser releases were preceded, almost immediately, by Bloggers release of its Beta Blog product. It's quite likely that Beta Blogger was tested against Firefox Version 1.5, and Internet Explorer Version 6, but releases no more current than that.
The Current ProblemAnd that's where we are now. Painted into a corner by our new software, with restrictions by default. Protected - and unable to use Beta Blogger - by the newer software. And there were some unknown changes made in early December by Blogger, of which we know only that we need to
clear our cache to use Beta Blogger.
But the browser settings, and changes by Blogger, probably aren't the only problem here. Your other protective components - your network level perimeter and personal firewalls, and your application level anti- malware programs - may also need tuning.
If you have a
well designed layered defense, the various components are (or should be) updated regularly. I observe one or more updates to mine, at least weekly. With every security update, there's always the possibility of a false positive - a new malware signature matches a vital software component on your computer. You apply the update, and something breaks.
Some material that's subject to filtering, for instance scripts, may be
subject to caching also. A filtering change, and subsequent false positive, may not be immediately effective. After applying any security update, you should
clear the cache on the browser, then
test each change. If you're using two or more browsers, you should clear both simultaneously, for consistent results.
You need to test immediately after making changes, so you know when any change causes a problem. It's much easier to solve a problem, when you can observe that the problem started after you made a specific change, or updated a specific program.
And now, in 2009, possibly resulting from diversification and expansion efforts by Blogger / Google, we see that their code occupies
several mysterious address spaces, besides the known Blogger / Blog*Spot domains. We may need to add some trust settings to (or remove some from) our browser configurations for these new domains. This will involve both cookies and scripts - and each will have separate settings, again for the different domains.
Overall DiagnosisMy guess is that the current problems involve two key components, that are required by Blogger, and that are being blocked by either your browser, or by external security products.
- Cookies provide the ability for Blogger scripts to retain selections and settings, as needed. Remembering your previous login requires cookies to be allowed.
- Scripts provide the ability for any Blogger GUI application, such as photo uploads, post editing, or word verification (aka captcha) to run on your computer.
If Blogger made any changes to their servers that require different cookies, or different scripts, on our computers, it's possible that the cookies and / or scripts, cached on our computers right now, is out of date. This is why the recommended strategy, of
clearing cache and cookies, which forces Blogger (and other websites) to refresh everything, would work.
Both cookies and scripts are prominently featured in various security settings recommendations. If incorrectly blocked, either could provide some of the problems seen in the Blogger Help forums of late. For advice from Blogger, see Blogger Help:
Continual prompting to login, or "Session Expired" messages. And see
below for an interesting detail about cookies and Blogger.
The bottom line here? It's your computer, and
some of the problems can only be resolved by you. Blogger hasn't the resources to support
every problem that you might have, when accessing their computers.
And your problems are only going to get worse. But that's another story.
Update Notes(Edit 2009/04/11): Besides "Blogger.com" and "BlogSpot.com", there are
new domains used by Blogger / Google, in letting us maintain our blogs, and letting our readers enjoy the features in our blogs.
(Edit 2007/03/01): Besides considering filtering of cookies and other elements, based upon the difference between "www.blogger.com" vs "www2.blogger.com", there's also
a difference in how you login, that you should consider.
(Edit 2007/02/13): Besides the
various cookie issues in Firefox (which may or may not be an actual security issue), there is an interesting, and very real,
security issue involved for Blogger and users of Internet Explorer (and possibly Firefox too).
(Edit 2007/01/03): In addition to the
third party cookies issue presented below, there's a good chance that
first party cookies could be a problem too. It's very possible that a lot of folks specified
"www.blogger.com", rather than "blogger.com", as allowed to serve cookies. Check your cookies settings, in both Firefox and Internet Explorer.
(Edit 12/30): Now on the subject of cookies, there is a special type of cookie, which may be relevant right now. Most cookies are designed to be read by the same server that wrote them, ie, cookies written by "www.blogger.com" can only be read later by "www.blogger.com". Why would processes running from any server care about cookies written by processes running from another server?
How about when changing servers?
So when Blogger replaced Beta Blogger (which used "beta.blogger.com" for many of its activities) with New Blogger (which uses "www2.blogger.com"), they may have New Blogger login processes setup to read cookies from Beta Blogger login processes. This is called
third party cookies. If you're having problems with login, and cookies in general are not a problem, check and make sure that third party cookies are not a problem.
(Edit 11/6): If you are publishing a Beta blog to an external server (FTP / SFTP), you need to
check the filter on your firewall. Blogger may be publishing from servers with unexpected IP addresses.
>>
Forum threads: bX-*00007>> Copy this tag: bX-*00007
>> Top