This post has a new edition.


Part #1 of the Data Liberation series

Although Google Chrome is a very fast browser, it lacks one key feature which seems designed to lock users in – any account migration facilities to support moving to other browsers.  This post is intended to help you move your saved passwords from Chrome to Firefox.

Firstly, you’ll need to have a read of this page: http://blog.catoblepa.org/2012/08/linux-how-to-export-google-chrome_28.html – then come back here for more info!

While following the instructions in that post, take note of these steps below before you close your browser. If you have also set up a separate encryption password for your browser, don’t worry – this method still allows access.

  1. Image of Google Chrome settings
    Disconnect Google account in Settings

    In Chrome settings, as a precation, I disconnected my Google account before closing the browser. Therefore, any changes I could make to this temporary session wouldn’t ever be uploaded back to Google.

  2. Once you have the saved CSV file from Chrome, keep hold of it – we need to edit it. In Firefox, install the Password Exporter add-on: https://addons.mozilla.org/en-US/firefox/addon/password-exporter/?src=search
  3. Image of Password Exporter
    Exporting passwords

    Password Exporter allows you to import passwords too, so you can avoid the need to install any third-party workarounds like LastPass (which again require you to upload all your browser data).Firstly, though, using Password Exporter in Firefox (Tools > Add ons … Extensions > Password Exporter > Preferences), we can export a sample CSV file to see how Password Exporter expects its import data. Simply click “Export Passwords” and save the file to your home directory.

    NOTE: This requires that at least one password is saved in Firefox already.

  4. The headings in the exported file are as follows:

hostname username password formSubmitURL httpRealm usernameField passwordField

This is the format that Password Exporter will expect its import data.

The data’s headings that you have just exported from Chrome are a little different:

origin_url action_url username_element username_value password_element password_value submit_element signon_realm ssl_valid preferred date_created blacklisted_by_user scheme password_type possible_usernames times_used

We need to match up the firefox CSV headings with the corresponding Chrome CSV headings. To do this quickly, use a spreadsheet tool I used LibreOffice Calc.

This is what I arrived at:

(FF = Firefox; GC = Google Chrome)

FF: hostname username password formSubmitURL httpRealm usernameField passwordField
GC: origin_url username_value password_value action_url signon_realm username_element password_element

Once the fields are mapped, there’s a couple more important steps to undertake.

Export dialog
Export in the right format!

Firstly, when you come to exporting from your spreadsheet application, make sure you choose to edit the output filter. In the Export Text File dialog, make sure “Quote all text cells” does not have a check (tick) in the box.

For good measure, I also selected ASCII/US in encoding type,  as that is the format used by Password Exporter when exporting.   I think the importer should handle ISO-8859-1 and/or UTF-8, but your mileage may vary.

Now export it.

Remember seeing the additional header in the exported CSV file? It might have looked something like this:

# Generated by Password Exporter; Export format 1.1; Encrypted: false

In order to tell Password Exporter what format to expect its data in, this heading needs to be added back. However… the best way to do this is via a text editor, not in a spreadsheet program.

Open up GEdit, Emacs, Vi… whatever. Add that line to the top, but remove any trailing commas! It should now look like this:

# Generated by Password Exporter; Export format 1.0.4; Encrypted: false
"hostname","username","password","formSubmitURL","httpRealm","usernameField","passwordField"

One more step before you import!

A side-effect of exporting your CSV in LibreOffice is that empty cells are not quoted. In other words, the comma-separated values may appear like this:

"someusername","somepassword","someUrl",,"someusernameField"

Did you see those two commas with nothing between? The Password Exporter won’t like that when trying to import, so do a quick search-and-replace:

Search for ,, and replace with ,””,

Finally, save the file.  Again, ENSURE the file type is US/ASCII.

The importer dialog
Successfully importing passwords!

Now open up the Password Exporter dialog from Firefox and click Import Passwords – you should see progress in the dialog shortly.

CAVEAT #1: BUG WHEN IMPORTING v1.2-EXPORTED DATA

There is an import bug when the version header is declared as 1.1. However, you can get around this by “fudging” the import header to an older version (I used 1.0.4). If you have trouble importing, adjust your header in the file to look like this:

"hostname","username","password","formSubmitURL","httpRealm","usernameField","passwordField"

After importing, you may see that not all passwords were imported. This is because duplicates are not imported. You can view the details in the link.

CAVEAT #2: SOME LOGINS, PASSWORDS, ETC ARE QUOTED

So far I’ve not had time to find a way around this. It’s to do with the import format.

The adventurous can investigate the source code, here: https://github.com/fligtar/password-exporter/blob/master/passwordexporter/chrome/content/pwdex-loginmanager.js

Hopefully you have now successfully liberated your passwords!

Problems?  Comment below!

Google is undoubtedly suffering from some adverse PR in respect of its new privacy policy.  While it may have considered itself on to a PR “winner” with its “privacy made simple” approach, there has been considerable backlash in opinion and re-consideration of the use of its services.

So, what could Google do to demonstrate that it still takes on-line security seriously?

How about setting up its own Certificate Authority, and issuing free SSL certificates?

Google has the infrastructure, manpower and, I’d argue, interest in doing such a thing.  In fact, in many ways, it already offers the flesh around this missing skeleton.

Perhaps it could support the CACert effort with funding and enough energy to get it through the audits required to have their root certificate included in Mozilla’s Firefox, as-shipped?  And, while Google are at it (restoring their image of benevolence, that is), they could include that root certificate in Chrome too.

Just saying…

Scammers rely on your ignorance in order to fool you into clicking on their link and typically entering your bank details.

Don’t let them! 

DISCLAIMER:  DO NOT TRY TO VISIT THE EXAMPLE SCAM LINK GIVEN IN THIS POST.  YOU ALONE ARE RESPONSIBLE FOR YOUR ACTIONS.

When you receive a link in an email, you should analyse that link to determine the authenticity and legitimacy of that link, before you click on it.

I was recently forwarded a scam email to analyse.  If you have recently received a suspicious email with a link, here’s how to analyse that link.

Firstly, hover the mouse pointer over that link.  At the bottom of your email window (commonly called the status bar), you should see a web address appear.

In this example, a link was received purporting to be from the UK bank Cahoot.  But the link address is suspicious – so let’s analyse it…

http://ip270-c6.gi.digl.pl:8887/securebank.cahoot.com/servlet/com.aquariussecurity.bks.security.authentication.servlet.LoginEntryServletBKS/

… the bit in bold is what you’re interested in.  The rest is not really of interest.  However, when you come to inspect a link in the future, it’s worth knowing the following:

How to analyse a link in Thunderbird
(click for larger image)
  • http://

    This means the protocol that your browser will use.  A secure, encrypted browser connection begins https:// ; therefore, the link above will be unencrypted (not secure) between your computer and the server.  This is a tell-tale sign that it’s trouble.

  • ip270-c6.gl.digl.pl

    This is the domain name, like “bbc.co.uk“, “fedoraproject.org” and “google.com“.  This is the most important bit.  The best way to read this is actually from right to left.  The most right hand part, “pl“, is the top-level domain (TLD).  pl is the TLD for Poland.  tw is the TLD for Taiwan.  ru = Russia.  And so on.  For reference, you can find a list of TLDs here: http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

    The next two bits should really indicate the organisation of the originating email. digl is meaningless; it’s been made up by a scammer to probably infer “digital” or something like that.  Likewise, gl is also meaningless.

    A meaningful alternative would be cahoot.co.uk, as it is registered with a UK TLD and represents the claimed originator of the message.

  • :8887

    The last bit of this link is what’s called a port number.  The (optional) use of this by scammers is again a visual distraction which makes it harder to read the real web address.  Apart from the fact that no bank would ever request your details by email anyway, if they were credible they most certainly wouldn’t use a web address with a non-standard port number.

    The best thing to do when reading an address is to ignore the port number but be aware of the fact that it’s been used. 

For more information, check out this PDF on avoiding email scams.

And for those who were paying attention and spotted the deliberate mistake, well done! 🙂

Enhanced by Zemanta

News abounds today of Google’s statement, relating to its operations in China. The statement indicated that Google would consider exiting China completely if it could not operate, with government approval, in an unrestricted manner. The post is here: http://googleblog.blogspot.com/2010/01/new-approach-to-china.htmlIn business, to turn away just under 20% of your potential revenue to comply with your own principles must be a hard call to make. But Google is global, and perhaps 4.8 billion people in the rest of the world is a sufficient number to target with AdWords campaigns…

But what is really happening here? It’s difficult to believe that Google would invest so much time and effort, installing services in 2006, and then expect that within 4 years Beijing would accede to Google’s “wisdom” and suddenly allow freedom of speech. Within 4 years? After thousands of years of communist, dynastic and, occasionally, even tyrannical rule? No, somehow this seems unlikely.

It’s a surprising move by Google; one that could incite anything from a murmur of disquiet amongst the ranks of young Chinese teens, avidly seeking knowledge and understanding, to full-blown protests, perhaps even riots. It’s something of a political move, too: reading between the lines, it would appear that Google suspects Beijing of orchestrating the cyber-attacks on it and the twenty or so other organisations, as mentioned in their blog. By saying “play fair or don’t play at all”, Google may be vocalising the sentiments of the underclasses, still struggling to be heard from within the provinces.

Something that has not been mentioned (to my knowledge) so far in the press is the opportunity to expose Hong Kong. Under Chinese rule, but with special provisions (such as more liberal allowances on internet services), Hong Kong would present a potential new base for Google’s Chinese operation. But perhaps that’s a step too far?

The question remains whether it’s a viable exercise, and for viability, read “bottom-line”. Implementing the required censorship and publishing restrictions as required by the Chinese government will likely have been more technical trouble than they’re worth for Google, who elsewhere in the world have hands-down probably the most advanced information and revenue infrastructure to be found.

But information and revenue go hand in hand in Google’s business model. The less information, the less dynamism on-site, then the less interest there will likely be and the less uptake, over time. Google works in the west because there are virtually no limits, within the law, on trading ideas and services. In the far east, Google may have just observed a synergy that works to the detriment of its model. It may also be outgunned by larger powers at work; Beijing’s insurance.

We shall see if Google’s gambit, encouraging closer but more open ties with Beijing, will pay off.

I recently found myself having the need to revoke an old certificate. The steps are actually quite straightforward, but you do need to have your old revocation certificate to hand.

For more info, visit the GNU Privacy Guard site: http://www.gnupg.org/gph/en/manual.html

Simple follow these steps. In a terminal, issue:

  • gpg –import my-old-key@mydomain.com (0x712AC328) rev.asc
  • gpg –keyserver certserver.pgp.com –send-key 712AC328

That’s it!