Quoted

A tweet was recently posted featuring an advert claiming Firefox is the better browser in terms of respect for privacy:

Sadly, this isn’t the case, as this Pale Moon update clearly describes:

https://forum.palemoon.org/viewtopic.php?t=16154&p=117375#p117375

So, if you use #Firefox, best to expect information leakage back to #Google anyway.  If you value your privacy and want a functional browser, check out Pale Moon!

#palemoon

Also on:

Padlock and code image

Some time back, I wrote a post listing the steps required to migrate passwords stored in Chrome to Firefox

That post was a bit convoluted, so this post is hopefully an improvement!  My intention is to make this process as simple, and reliable, as possible.  To succeed, you will need:

There are five main steps.  Let’s get started!

  1. In Chrome’s address bar, paste:
    chrome://flags/#password-import-export

    …then hit enter.

    Chrome flag screenshot
    The option in Chrome should appear like this. Enable it!

    In the option that is highlighted, Select Enabled and then Relaunch.

  2. Now, in Chrome, navigate to chrome://settings-frame/passwords, scroll down and click Export.  Save the file with a .csv extension.
  3. Locate the CSV file and right click > Open With > LibreOffice Calc (Alternatively, start LibreOffice Calc and open the CSV file).
  4. Using LibreOffice Calc, you will need to modify the CSV file to import it into Firefox.  Do the following:
    1. Right-click on row 1 and select ‘Insert Rows Above’.  This should insert a single row at the top of the sheet.
    2. 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
    3. 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.
    4. Paste the following into cell A2, using Shift-Ctrl-V:
      hostnameusernamepasswordformSubmitURLhttpRealmusernameFieldpasswordField

      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.

    5. 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:
      Select these options to correctly export your data!
      Select these options to correctly export your data!
    6. 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.

  5. 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:
    Importing saved passwords into Firefox. Not easy, but definitely rewarding!
    Importing saved passwords into Firefox. Not easy, but definitely rewarding!

 

I recently kept getting this problem in Firefox:

Screen capture of error message in Firefox
Are you seeing this a lot when using Firefox / Iceweasel / etc?

If you use Firefox and have recently come across this error, fear not.  This intention of this page is to resolve these errors once and for all!

There are a few key steps to resolving it:

  1. Clear Cookies & Cache
  2. Use System Proxy
  3. Disable all Add-ons
  4. Close and restart browser
  5. Try again

 

Regain security
Regain email privacy & security

Part #3 of the Data Liberation series

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.

Web cam

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.

Bootnote

ArsTechnica has an interesting article published yesterday (30 March 2014) on “metadata as surveillance” .

 

Part #2 of the Data Liberation series

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.

FFirefox logoirefox 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.

The main task at hand is to follow the detailed instructions published by Mozilla.

As per the instructions, I had to run the following, in order to install required software:

# apt-get install python-dev mercurial sqlite3 python-virtualenv libssl-dev

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:

Firstly, find the DocumentRoot declaration:

DocumentRoot /home/mydomain/domains/subdomain/public_html

and change it to:
DocumentRoot /home/mydomain/domains/subdomain/server-full

Next, you’ll need to insert the following lines, within the same stanza as DocumentRoot (the best thing is to adjust and paste these lines directly after DocumentRoot:

WSGIProcessGroup sync-http
WSGIDaemonProcess sync-http user=<your-virtualmin-domain's-user> group=<your-virtualmin-domain's-group> processes=2 threads=25
WSGIPassAuthorization On
WSGIScriptAlias / /home/mydomain/domains/
subdomain/server-full/sync.wsgi

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.:

WSGIProcessGroup sync-https
WSGIDaemonProcess sync-https user=<your-virtualmin-domain's-user> group=<your-virtualmin-domain's-group> processes=2 threads=25

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!

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!

Mozilla Firefox word mark. Guestimated clear s...
Image via Wikipedia

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  🙂

Enhanced by Zemanta