Locate the CSV file and right click > Open With > LibreOffice Calc (Alternatively, start LibreOffice Calc and open the CSV file).
Using LibreOffice Calc, you will need to modify the CSV file to import it into Firefox. Do the following:
Right-click on row 1 and select ‘Insert Rows Above’. This should insert a single row at the top of the sheet.
Copy the following and paste into cell A1, using Shift-Ctrl-V (to ensure you paste as plain text):
# Generated by Password Exporter; Export format 1.0.4; Encrypted: false
You need to move one column, B, to where column D is – but we don’t want to overwrite your data!
At the top of column B, right-click and select Cut.
Then right-click again and select Delete Columns – this should remove the now-empty column, and shift-left columns C and D, to positions B and C.
Now, on column D, select Paste. Your url data should now live in column D.
Paste the following into cell A2, using Shift-Ctrl-V:
When pasting, you may be prompted to select the data format. Select “Unformatted Text” in the list and click OK. We are ok with overwriting other cell contents, so “OK” that.
Finally, we’re ready to export this data! Go to the File menu, select Save As…In the Save As requester that appears, at the bottom check ‘Edit Filter’ and select ‘Text CSV (.csv)’ in the format drop-down:
Before we get too excited, there’s just one more step to perform – some textual clean-up!Open up the exported CSV file in your favourite plain-text editor. In the first row, you may see this:
"# Generated by Password Exporter; Export format 1.0.4; Encrypted: false",,,,,,
Delete the leading ” and trailing “,,,,,, from that line.
Secondly, do a Find/Replace on double-commas (,,) making them ,””, (with two quotes inserted) instead. You may need to perform this Find/Replace twice. Now save the file again.
In Firefox, click on the burger menu and select Add-ons (or just go to about:addons). Find Password Exporter and click Preferences. In the Preferences window, click Import Passwords. Now locate your saved CSV file and load it.You should finally see something like this:
Is there ever time in the day to reconsider your online security? I mean, really consider it?
Take the most common access point for communication in the 21st century – email. Yes, you read that right. It’s still email. Email is the root of online authentication for people worldwide, not only allowing them a “safe place” to recover lost account credentials, but also facilitating properly secured communications with the use of PGP signed and encrypted email. But is your email storage secure?
The woes of web mail
The “problem” with email is that its ubiquity spawned, some years ago, the explosion of “free” web mail services. All the big players provide it. These services are advertising-supported. In other words, the cost of providing such services are met by revenue generated from scanning your email and providing “relevant” adverts within your browser to click on. Each click is tracked and the advertiser billed accordingly.
An issue here, then, is that your email is scanned. All your emails are read by an indexing process which scours every single nugget of information. What information could that include? How could it be used? How about this little list for starters:
the date & time
the sender’s name and email address
their computer’s name
their network (i.e. their email provider, their ISP, any intervening mail routers)
their probable native language
their approximate location when sending the message (obtained from their original IP address)
your approximate location when reading the email (based on your IP address)
yours and their exact locations if using any location service
That’s not all
If the sender is using the same “free” web-mail service as you:
if they use a calendar in that service, what they were doing when they emailed you (giving an insight into the sender’s thought processes…)
if they maintain a contact list / address book in that web-mail service, that service may “know” you are a friend or family member of the sender
in this case, it will also know their friends – and your friends – and any shared friends too. It can start to build up a map of contacts – who knows who and possibly why.
Knowing “who knows who” means those related contacts’ web-mail services can be interrogated for commonalities, such as shared events (in a calendar), shared interests via a social network, and so on.
There are yet more ways your data can be exposed. If they are not using the same “free” web-mail service, but are using another service which they log into using their web mail service’s credentials:
that web-mail service provider could poll the other services to see what data you are sending (e.g. what you are posting) to those services
it can map any correspondence to or from your contact via its services even when not in relation to your email – e.g. It can expose a contact’s movements, their communications and interests in a given time-frame.
they can even be exposed by their use of related services from that provider. For example, new photos into a flickr or instagram account which is public, can be mapped back from their date, time and location to the IP address that was used to query location services.
Finally, a crucial problem with all online services is that there is no guarantee your data is actually deleted when you choose to delete it. After hitting “delete” through a web site, this could simply flag the email to be removed from your visible account and stored in MegaWebCorp’s vault of “deleted” email, remaining there forever. Or until needed…
This is the risk of putting data into another provider’s hands – what gets uploaded or stored in your name, stays there in your name, forever. What goes up, sometimes stays up.
Resolving the privacy crisis
Coming back to email, then, the first priority for someone who wants to maintain some privacy with respect to their life activity needs first to remove the source of indexing from MegaWebCorp’s database – the link between all things you do, your email address.
When the email address is removed from the purview of MegaWebCorp’s systems, your online activity can start to become your business – not the advertiser’s.
Getting your own address is simple. You can register a domain name with any of numerous providers around the world and sign up for a low-cost hosting plan. For any person who values their privacy and the sanctity of anonymity, this is a small hurdle to overcome.
For the gain in privacy you can achieve by hosting your own web site, the price attached to a “free” web-mail account may seem rather high.
Mozilla, the organisation behind the ubiquitous Firefox web browser, kindly publishes its source code powering a key service which it provides – Firefox Sync. Because of this, we are able to run our own password sync servers securely and not necessarily be the target of a large-scale data-mining break-in, such as might be performed by a malicious cracker, or the NSA. Sorry, of course they are the same thing.
Firefox Sync is a neat service which allows you to, quite literally, sync your settings in Firefox across multiple devices. These settings can include bookmarks, web browsing history, cookies, form-filling data and passwords. Anyway, I too was keen to run my own password sync server, so I set about doing just that.
I host quite a bit of stuff using Virtualmin, another superbly produced piece of software which facilitates the set-up of multiple domains on a single box. Setting up Firefox Sync on your own server under virtualmin is actually very straightforward.
In addition, I also needed to install and enable the WSGI Apache module, which wasn’t present on my system (drawing in dependencies as needed):
# apt-get install libapache2-mod-wsgi
I decided to install the Mozilla sync software in the home directory of my newly created domain, which in Virtualmin is either “/home/domain” or “/home/domain/domains/subdomain”, depending on whether you have created a subdomain for this specific purpose or not. In the subdomain situation, the folder path would end up being: /home/domain/domains/subdomain/server-full.
Once installed, I inspected the Apache config file. A key change I had to make was to the WSGI configuration within this file. On my Debian box, the Apache config files are located in the standard place: /etc/apache2/sites-available – the same would be true for Ubuntu (on CentOS and other RHEL/Fedora derivatives, you’ll probably find them in /etc/httpd/conf.d/). Once you have created your domain in Virtualmin, your domain’s config file should be within this folder, appropriately named “domain.com.conf”.
In the “domain.com.conf”, there are a few lines to add and one to edit:
The above example assumes that you are working within the :80> stanza. If you have enabled SSL on your virtual server, within Virtualmin, then you’ll also have a :443> stanza to add these lines to, with one or two exceptions!
A WSGIDaemonProcess is assigned to each virtual server in Apache. In doing so, it creates a system process which requires a name. According to the WSGI docs, this name must be unique:
“[…] note that the name of the daemon process group must be unique for the whole server. That is, it is not possible to use the same daemon process group name in different virtual hosts. “
When you come to pasting in the additional lines in your :443 stanza, you are dealing with a separate virtual server in Apache. So, within your Apache config file, be sure to rename your WSGIDaemonProcess process name. E.g.:
This configuration should now be valid. You can test this with:
service apache2 reload
This won’t stop the current Apache process, but it will attempt to load the new configuration file. If it fails to load the config, it will tell you without stopping Apache.
Once this works, simply issue:
service apache2 restart
Syncing on mobile
If you intend to use Firefox on Android, or any other mobile Firefox (or clone) that supports the same syncing protocol, there is one caveat. If you are using an unsigned or self-signed SSL certificate on your sync server, you should visit the site first in your mobile Firefox and add a permanent exception. Once done, set up firefox sync in the normal way, by typing the characters into your desktop browser’s sync dialog, and the two browsers will shortly be synced up nicely!
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.
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.
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.
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.
Once the fields are mapped, there’s a couple more important steps to undertake.
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
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:
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.
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:
Stupid Firefox 7! It doesn’t recognise my plug-ins! But they did work in FF3.5. What gives?!!!
Ok, perhaps I’m overreacting. In fact, I am. Sorry.
I use #CentOS for my daily work which includes the rather antiquated Firefox v3.5. Ouch. As a web developer, it’s good to test on legacy browsers but it’s also important to use the latest – so I updated to the latest Firefox (v7, at time of writing).
Because my desktop machine (HP Opteron ML115) has 6GB of RAM, I typically use the x86_64 (64-bit) edition of #Firefox. However, unlike Firefox v3.5, v7 doesn’t seem to pick up my plug-ins automatically from /usr/lib64/mozilla/plugins.
To fix this, I had to open a shell and navigate into my home directory‘s mozilla plugins directory (I didn’t even know this existed until now!).
cd ~/mozilla/plugins Then, just fix up all the missing symlinks:
ln -s /usr/lib64/mozilla/plugins/* .
No problemo! They’re now all back again at about:plugins 🙂