Blocking web trackers and cookies to help protect your online privacy

Ghostery Logo

I’ve just discovered a really good browser extension that blocks web tracking cookies, code and images.

It’s called Ghostery and versions are available for Chrome, IE, Safari and Firefox.

When active, Ghostery watches web pages being loaded and blocks, removes or replaces tracking cookies, code and images to protect your privacy.

It has easy-to-use and intuitive configuration pages which allow you to specifiy what you want to block and how you want notifications to work.

At time of writing, it recognises and can block 2,080 different trackers in 5 different categories:

I choose to block all trackers except Gravatar, Worpdress Stats and Google Analytics.

You can find out more information from the Ghostery home page at www.ghostery.com

It can also be installed as an extension for Chrome from their Web Store.

Hosting Recommendation

SiteGround Hosting

I’ve been playing around with WordPress as a CMS for a couple of years now – building sites and templates.

Although I really like the open-source nature of WordPress and the community feel it has, I’m often a bit concerned about the performance of WordPress pages and especially frustrated by the administration pages taking forever to load.

I’ve tried using caching plugins and tweaking the web server hosting WordPress’ PHP pages, but this has little effect.

In an attempt to get a better WordPress experience for me (as an admin and developer), my customers (as content editors) and as end users of their websites, I’ve been having a dig around online as dedicated WordPress hosting solutions.

I think I’ve found a really good trade-off between monthly cost and high performance.

I’d like to introduce you to SiteGround – my new preferred hosting company.

SiteGround provide a load of different online services including dedicated WordPress hosting with performance that genuinely surprised me.

And to surprise an old cynic like me nowadays is quite rare 🙂

If you’d like to try SiteGround – especially their WordPress hosting, please use this link as I get a kickback in the form of a couple of months free hosting and you get the same*

https://www.siteground.com/index.htm?afcode=0e7012ee0630b0c6da17491eb10c8d61

* affiliate and subscriber benefits differ throughout the year

Continuous handshaking problems with 2015 MacBook Pro & Denon AVR-X2200W Receiver [SOLVED]

I’ve just bought a Denon AVR-X2200W AV Receiver and it’s a lovely bit of kit, but it doesn’t play nicely with my MacBook pro 2015 over HDMI.Denon AVR-X2200W Receiver

The problem

I plug my MacBook Pro into my Samsung TV using HDMI and everything’s great. I see the MacBook Pro desktop with a great picture, no overscan, correct resolution and refresh rate – perfect 🙂

However, it’s a different story when I introduce the Denon Receiver into the equation…

I use the same cable to plug my MacBook Pro into the Receiver, then (using another identical HDMI cable) plug the Receiver into the same TV using the same HDMI port. I configured the Receiver to not process the incoming signal, so essentially allow it to pass though.

This time, the TV showed a slightly over-scanned version of the MacBook display. This was fixable by dragging the overscan slider on the Mac.

However, the problem was that every four seconds the TV/Receiver/MacBook re-initialised the display which resulted in the TV going black and the connection being renegotiated, then the image of the MacBookPro desktop would come back again.

Its important to note that I’m not playing a video or running iTunes while all this is happening, it’s the the MacBook Pro desktop that’s being shown on the TV.

Observations

While this continuous reinitialising of the display was happening, I noticed a few things…

  1. The MacBook resolution didn’t reset itself, so it knew the HDMI connection hadn’t changed. If the HDMI cable had been unplugged or the Receiver disconnected from the other end, the MacBook would have changed back to it’s native resolution.
  2. The mouse pointer froze for a fraction of a second every time the TV display went black, so the MacBook was either doing something or responding to something coming back down the HDMI cable.
  3. Every time the image came back on the TV, the TV’s on-screen-display showed the resolution and frequency of the incoming signal. This suggests the signal had been stopped then started again or the TV told to re-examine and re-negotiate a connection.
  4. The AV Receiver’s on-screen-display also disappeared when the TV went black, which suggests that the source of the reset instruction is coming from the MacBook and being passed through unaltered to the TV.
  5. I swapped out all the HDMI cables and tested again with new high-speed/ethernet-enabled cables. There was no change and the same behaviour was exhibited.
  6. I tested the same AV Receiver/MacBook/Cable combination on two other TVs. A 24″ Sony and a 58″ Samsung Series 6 Plasma. In every case, the continuous re-initialisation of the display still happened.

Conclusion

The AV receiver is either altering or filtering the HDMI commands sent from the MacBook Pro to the TV or from the TV back to the MacBook Pro which is causing the MacBook pro to repeatedly send HDMI handshaking commands.

Further investigations

During my search for whether other people were experiencing this behaviour, I discovered that Apple has been quietly rolling out High-Bandwidth Digital Content Protection (HDCP) to it’s machines via OS X updates. I always keep my MacBook Pro up to date so it’s running the current version of OS X El Capitan.

It also turns out that Apple has been slowly removing makes and models of video equipment from it’s list of “supported” kit.

I can understand why Apple would want to prevent users from purchasing a film on iTunes, then “recording” it to another machine via HDMI. Unfortunately this has the unpleasant side-effect of preventing users from hooking the MacBook Pro to an “unsupported” projector or TV for presentation purposes.

Solution

After a bit of digging around online I discovered that there are a number of cheap HDMI splitters available that take one HDMI input and duplicate it to two HDMI outputs.

A side-effect of this “splitting” of the signal is that the HDCP commands are filtered out from the source signal and are not relayed back from any connected output devices back to the source device.

After reading through reviews of various products, I bought one of these splitters from Amazon.co.uk for £9.99 (with free P&P).

2-Way iSolem HDMI Switch Box     2-Way iSolem HDMI Switch Box

http://www.amazon.co.uk/gp/product/B006KZBC92

I connected the output of the MacBook Pro to the single input of the splitter and connected one of the outputs of the splitter to the input of the Receiver. I used the same HDMI cables are before.

The effect was that the TV displayed the MacBook Pro desktop just as before, but this time it no longer reset itself every few seconds.

Additionally, the mouse pointer on the MacBook Pro didn’t freeze every few seconds, so it wasn’t trying to re-check anything all the time.

Get aircrack-ng working on Raspberry Pi and Raspbian

Run these commands:

sudo -i
apt-get -y install libnl-dev
wget http://download.aircrack-ng.org/aircrack-ng-1.2-rc2.tar.gz
tar -zxvf aircrack-ng-1.2-rc2.tar.gz
cd aircrack-ng-1.2-rc2
make
make install
airodump-ng-oui-update
apt-get -y install iw
sudo apt-get install ethtool
airmon-ng start wlan0

The airodump-ng-oui-update will take a while to complete.

Looking out for networks

airodump-ng mon0

Information taken from here: http://www.aircrack-ng.org/doku.php?id=newbie_guide

 

Asus BT-400 Bluetooth dongle and Raspberry Pi

Here is a solution.

First switch to admin mode:

sudo -i

Now get the necessary packages. This will install all necessary software.

apt-get install bluetooth bluez blueman

Then use the lsusb command to list the connected USB devices…

lsusb

The result will include something like this:

Bus 001 Device 001: ID 0b05 17cb Vendor Desc.

Now you have to find the correct device. When you found it, copy the ID without colon and write it into the /sys/bus/usb/drivers/btusb/new_id. You can do it like this:

echo "0b05 17cb" >> /sys/bus/usb/drivers/btusb/new_id

Now we will use a tool called modprobe which allows us to load modules on our running system.

modprobe -v btusb

Almost done! Just edit the config with nano  (save= crtl+o ; quit= crtl+c)…

nano /etc/default/bluetooth

… and copy the few lines below

HID2HCI_ENABLED=0
HID2HCI_UNDO=0
HIDD_ENABLED=1

Restart bluetooth and you are ready to go!

invoke-rc.d bluetooth restart

 Testing the bluetooth dongle

Check the device is on and everything is up and running using this command:
/etc/init.d/bluetooth status
This should come back with something like this:
● bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
 Active: active (running) since Wed 2015-11-18 10:38:48 GMT; 5min ago
 Docs: man:bluetoothd(8)
 Main PID: 3800 (bluetoothd)
 Status: "Running"
 CGroup: /system.slice/bluetooth.service
 └─3800 /usr/lib/bluetooth/bluetoothd

Pair the Pi with a keyboard (for example)

Use the hcitool to scan for devices:
hcitool scan
 This should come back with something like this:
Scanning ...
       00:0F:F6:82:D1:BB       Motorola Bluetooth Wireless Keyboard
Pair the Pi using the ID of the device. We’re using the PIN 1234 like this:
/home/pi# echo 1234|bluez-simple-agent hci0 00:0F:F6:82:D1:BB
RequestPinCode (/org/bluez/3964/hci0/dev_00_0F_F6_82_D1_BB)
Enter PIN Code: Release
New device (/org/bluez/3964/hci0/dev_00_0F_F6_82_D1_BB)
Now we need to trust the device so every time the Pi reboots, it connects automatically.
/home/pi# bluez-test-device trusted 00:0F:F6:82:D1:BB yes

Test the device as an input

/home/pi# bluez-test-input connect 00:0F:F6:82:D1:BB

After a reboot the keyboard should still connect. It’s possibe a keystroke is needed to connect. Connection can take a few seconds.

/home/pi# hcitool con
Connections:
       < ACL 00:0F:F6:82:D1:BB handle 41 state 1 lm MASTER AUTH ENCRYPT

Configure Wi-Fi on your Raspberry Pi via the command line

Find available Wi-Fi networks

To scan for Wi-Fi networks, use the command

sudo iwlist wlan0 scan

This will list all available Wi-Fi networks along with other useful information. Look out for:

ESSID:"testing"

This is the name of the Wi-Fi network.

IE: IEEE 802.11i/WPA2 Version 1

This is the authentication used; in this case it is WPA2, the newer and more secure wireless standard which replaces WPA1.

These instructions should work for WPA or WPA2.

You will also need the password for the WiFi network. For most home routers this is located on a sticker on the back of the router. The ESSID (ssid) for the network in this case is testing and the password is testPassword

Add the network details

Open the wpa-supplicant configuration file in nano:

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

Go to the bottom of the file and add the following:

network={
    ssid="The_ESSID_from_earlier"
    psk="Your_wifi_password"
}

In the case of the example network, we would enter:

network={
    ssid="testing"
    psk="testPassword"
}

Now save the file by pressing ctrl+x then y, then enter.

At this point, wpa-supplicant will normally notice a change has occurred within a few seconds, and it will try and connect to the network. If it does not, either manually restart the interface with:

sudo ifdown wlan0
sudo ifup wlan0

or reboot your Raspberry Pi with

sudo reboot

You can check if it’s worked using

ifconfig wlan0

If the inet addr field has an address beside it, the Pi has connected to the network. If not, check your password and ESSID are correct.

Setting up a Raspberry Pi with a Tontec TFT 3.5″ screen (Model MZ61581)

Install the drivers

Taken from: https://s3.amazonaws.com/ttbox/35screen.zip

This is taken from information last updated on 2015-09-05

Below you will find instructions for installing the appropriate drivers for the Tontec 3.5 inch screen on your Raspberry Pi (including Pi 2). This guide was written for Raspbian wheezy, specifically 2015-05-05-raspbian-wheezy.img, though the guide should work on later versions as well.

1. Initial Config of New Raspberry Pi Install

After booting your Raspberry Pi for the first time on Raspbian-Wheezy, we will need to perform the normal tasks of setting up our Raspberry Pi. E.g expand filesystem,

Then we need “update” and “upgrade”

sudo apt-get update
sudo apt-get upgrade
sudo reboot

2. Update Firmware

We now need to update the dtb file to the newest version to support Tontec screen.

cd /boot/overlays
sudo rm mz61581-overlay.dtb
sudo wget http://www.itontec.com/mz61581-overlay.dtb
sudo reboot

3. Enable SPI and set overlay for Tontec MZ61581 Screen

Open /boot/config.txt

sudo nano /boot/config.txt

And add these lines to the bottom

dtparam=spi=on
dtoverlay=mz61581

Then save and reboot

4. Set Tontec 3.5 Screen as the default display instead of HDMI

sudo nano /usr/share/X11/xorg.conf.d/99-fbturbo.conf

Here we will change the default output display from HDMI to Tontec Screen

Change

Option "fbdev" "/dev/fb0"

To

Option "fbdev" "/dev/fb1"

– if you want to switch back to the HDMI display, just change it back to fb0

5.  Edit cmdline.txt

Here we will enable Tontec Screen to display during the booting process

sudo nano /boot/cmdline.txt

Add fbcon=map:10 at the end of current line. (No need to start a new line)

6.  Reboot

sudo reboot

Done!


 

Calibrate the touch screen for X Windows

Taken from: http://s3.amazonaws.com/ttbox/35calibrate.zip

We’ll install an xinput_calibrator and a script to load the calibration data each time X starts.

 

1. Install all the prerequisites required for calibration

sudo apt-get install libtool libx11-dev xinput autoconf libx11-dev libxi-dev x11proto-input-dev -y

2. Download and install xinput_calibrator

git clone https://github.com/tias/xinput_calibrator
cd xinput_calibrator/
./autogen.sh
make
sudo make install

3. Download and setup the calibration script

cd ~
wget http://s3.amazonaws.com/ttbox/xinput_calibrator_pointercal.sh
sudo cp ~/xinput_calibrator_pointercal.sh /etc/X11/Xsession.d/xinput_calibrator_pointercal.sh
sudo sh -c 'echo "sudo /bin/sh /etc/X11/Xsession.d/xinput_calibrator_pointercal.sh" >> /etc/xdg/lxsession/LXDE-pi/autostart'

4. Reboot

sudo reboot

Calibrating

Start up X Windows

startx

Plug in a USB mouse as you won’t be able to click on much as the screen’s not calibrated.

Click on [Menu] -> [Preferences] -> [Calibrate Touchscreen]

Go through the calibration and a console window will appear.

The calibration program will create a file which stores the calibration data( /etc/pointercal.xinput)

Click [File] -> [Close]

To perform calibration again, just delete /etc/pointercal.xinput and restart X. You will be presented again with the calibration program once X starts.