SEM Wired

A few months aho Google announced Gmail would switch to a default https connection, increasing protection against sniffing and any other network related threat. It was great news, even though the SLL was already available, Google made it the default option for users.

Nowadays all over the world millions of Facebook users get connected via standard http, keeping themselves quite vulnerable to sniffing or man in the middle type of exploits. Is there any way to switch to a safer connection making our Facebook login a bit more secure?

Just type https://facebook.com when logging in and your connection will pass through SLL encoding, making it safer: your machine will exchange a key with the facebook server through which all date will be encoded.

This means the secure socket layer connection s already availbale: how long should users wait for it to become the default connection in Facebook?

CSS transition have been finally made available on Firefox (3.7, pre-alpha2). With this feature developers will finally be able to apply movement to CSS elements, quite a good alternative to the more common use of Javascript. Here’s the developers Firefox version if you want to have a try.

// HTML
<ul>
 <li id="long1">Long, gradual transition...</li>
 <li id="fast1">Very fast transition...</li>
 <li id="delay1">Long transition with a 2-second delay...</li>
 <li id="easeout">Using ease-out timing...</li>
 <li id="linear">Using linear timing...</li>
 <li id="cubic1">Using cubic-bezier(0.2, 0.4, 0.7, 0.8)...</li>
</ul>

// CSS
#delay1 {
 position: relative;
 -moz-transition-property: font-size;
 -moz-transition-duration: 4s;
 -moz-transition-delay: 2s;
 font-size: 14px;
}

#delay1:hover {
 -moz-transition-property: font-size;
 -moz-transition-duration: 4s;
 -moz-transition-delay: 2s;
 font-size: 36px;
}

We all know WordPress is one of the most versatile and easy to use CMSs, with plenty of features which made him one of the best blogging platform available on the market. However it still lacks and adequate support for multilingual blogs, for instance when we’d need ot post the same article in more than one language at the same time.

If the CMS itself does not provide enough support for this feature, we can sort thing out pretty easily with a few plugins:

• Google Ajax Translation, this Google API makes available translation to users on your blog frontpage. It is not to be considered a proper WordPress plugin but it works just as good.

• WPML Multilingual CMS, with this plugin we would be able to get a fully working multilingual blogs in just a few minutes. No need of any change inside the source code or tables, it works straight out of the box.

   

• qTranslate, with this plugin we would be able to manage content in different languages from the WordPress editor, through automatic translation and permalink management.

Robots.txt has got its own system of codification for content, which does not allow any text codification different than US-ASCII.

According to the URI specifications, only the US-ASCII character set has to be used in order to define URL’S. This very point can create quite a lot of trouble for webmasters trying to set up their own robots.txt with a different set of characters.

ASCII’s 128 characters only covers the English alphabet, numbers, and punctuation marks, making impossible to control search engine behaviour when some “weird” characters are used into folder codification, like ñ in Spanish and ç in French, which are left out of ASCII.

Most characters in non-Latin-based alphabets, such as pi (π) in Greek, ya (я) in Cyrillic, and entire alphabets from many other world languages, can’t be accurately written in the limited, English-oriented ASCII.

robots.txt file codification is the following:

• ANSI (Windows-1252)
• Unicode
• UTF-8

The file however supports following codifications for its content:

• ANSI (Windows-1252): 8 bit
• ASCII: 7 bit
• ISO-8859-1: 8 bit
• UTF-8: 8 bit

Let’s take the case of a russian website, using Cyrillic codification for its folders and directories. In this case, characters like π or я should be correctly encoded into US-ASCII.

Percent-encoding comes into play, making possible to encode a non-ASCII string into a set of characters which can be perfectly read by search engines.

Let’s consider a russian website with a admin folder we do not want search engine to crawl:

http://www.domain.com/папка/

In order to avoid search engines crawling the admin folder, the folder’s name should be encoded as following:

Disallow: /%D0%BF%D0%B0%D0%BF%D0%BA%D0%B0/

…while the following line won’t work, since directory specifications into robots.txt must be always encoded in US-ASCII:

Disallow: /папка/

You might also want to read this article from the Bing Community, which explains the issue.

A news realase of WordPress has just been made available and is supposed to fix several security flaws, as explained here on the WP blog.

WordPress got so popular that any security update can actually be crucial, considering the amount of websites using it. Recently a well-known vulnerability allowed a worm to spread around affecting several blogs, according to this article. Still, there’s something more we can do to make our WordPress installation safer.

The WordPress Exploit Scanner extension can scan for well-known vulnerabilities and exploits which might affect your WordPress installation. In order to be used you just need to download, the extension, upload it on you server, active it by the extensions dashboard and a link will pop-up on your general dashboard.

Once you run the extension (it might need a few minutes to complete the task) the report you get is extensive. The plugin analyse in depth every single file, looking for malicious code embedded into standard file. It’s pretty useful, even if a standard report can require some programming knowledge to be fully understood. It’s a very neat tool, I guess it should be included in every WordPress standard setup.