You have become the new currency

I was alerted to the contents of the privacy policy for Google Payments by an episode of the BBC series – Billion Dollar Deals and How They Changed Your World – in which the presenter Jacques Peretti makes a rather astonishing (for me at least) discovery …

Take Apple Pay, there’s a small amount of money they make in each transaction. But with Android Pay, which is run by Google, they don’t take anything. So what’s going on?

The answer lies in the small print of the terms and conditions: “we may collect information about the transaction, including: Date, time and amount of the transaction, the merchant’s location and description, a description provided by the seller of the goods or services purchased, any photo you choose to associate with the transaction, the names and email addresses of the seller and buyer (or sender and recipient), the type of payment method used, your description of the reason for the transaction, and the offer associated with the transaction, if any.”

Remember that space in the transaction, the space where business makes money? Now that space is about data. You have become the new currency.

This piqued my interest as I have been using Android Pay for a few months. In doing so had I also given my consent for my personal financial transaction data to be harvested by Google?!

For the uninitiated, Apple Pay and Google Pay let you create a digital copy of your payment cards, which are held in a secure virtual wallet on your mobile phone. You can then make contactless payments using your phone instead of the physical cards.

The Apple Pay security and privacy overview states: “Apple Pay doesn’t collect any transaction information that can be tied back to you. Payment transactions are between you, the merchant (or developer for payments made within apps and on the web), and your bank“. That sounds perfectly fair and reasonable, but what about Google?

The current Terms of Service for Android Pay includes the line: “Your use of Android Pay is subject to these Android Pay Terms of Service and the Google ToS (which together, for purposes of these Android Pay Terms of Service, we refer to as the “Terms”), as well as to the Google Privacy Policy.

The Google Privacy Policy includes a link to the specific privacy practices with respect to Payments, which contains the aforementioned small print concerning Google’s collection of payment transaction information.

So yes, by virtue of using their product I did unwittingly give Google permission to ‘spy’ on my spending habits. This financial transaction data has intrinsic value and it’s obvious why Google would like to get their hands on it, but I didn’t expect the banks to be so lax as to allow it to be shared in this way.

This revelation left me wrestling with a dilemma. There is no denying that the simplicity of making small payments with a quick tap of my phone is really handy, but I value my privacy more than the convenience factor.

I just can’t abide my personal data being exploited in this way and so have reluctantly removed my payment and loyalty cards from Android Pay and I won’t be using it again. Sorry Google, but how I choose to spend my hard-earned moolah will be kept between myself, the retailer and my bank from now on.


New uses for old Dash buttons

I recently acquired a few Amazon Dash buttons and wondered if they might be repurposed to serve some useful purpose, other than ordering groceries.

I found this article by Ted Benson in which he describes how Dash buttons send an ARP probe after joining the WiFi network. By listening for these ARP probes (and their unique MAC addresses) you can trigger IFTTT Webhooks workflows, which turns the humble Amazon ordering tool into a customisable IoT button.

Bob Steinbeiser replied to Ted’s post with a clever Python script which sniffs ARP packets using a raw socket. Having played with Bob’s script I set about trying to make a few improvements. I’m a novice when it comes to Python though, so forgive my amateur code.

import socket
import struct
import binascii
import urllib2
import time

# Based on an original script by Bob Steinbeiser (
# Adapted to ignore duplicate presses and added support for multiple IFTTT triggers

# Use your own IFTTT Webhooks key here - see
ifttt_key = 'abc123'

# MAC addresses and their corresponding IFTTT Webhooks triggers
things = {
    'aabbccddeeff' : ['lights_off', 'sockets_off'],
    'a0b1c2d3e4f5' : ['test_1', 'test_2', 'test_3']


for macaddr in things:
    last_success[macaddr] = 0

rawSocket = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(0x0003))

while True:
    packet = rawSocket.recvfrom(2048)

    ethernet_header = packet[0][0:14]
    ethernet_detailed = struct.unpack('!6s6s2s', ethernet_header)

    arp_header = packet[0][14:42]
    arp_detailed = struct.unpack('2s2s1s1s2s6s4s6s4s', arp_header)

    # Skip non-ARP packets
    ethertype = ethernet_detailed[2]
    if ethertype != '\x08\x06':

    source_mac = binascii.hexlify(arp_detailed[5])

    time_now = int(time.time())

    # Is this a known 'thing' ?
    if source_mac in things:

        trigger_list = things[source_mac]

        # Prevent duplicate presses from being actioned (within 10 secs)
        if time_now > last_success[source_mac] + 10:
            # Supports multiple IFTTT Webhook triggers
            for trigger in trigger_list:

                print "Device " + source_mac + " has triggered " + trigger
                last_success[source_mac] = int(time.time())
                data = '{ "value1" : "' + source_mac + '", "value2" : "' + trigger + '" }'
                req = urllib2.Request('' + trigger + '/with/key/' + ifttt_key, data, {'Content-Type': 'application/json'})
                f = urllib2.urlopen(req)
                response =
                print response

             print "Ignoring repeated event for " + source_mac

        print "Ignoring unknown device " + source_mac

Note that this Python script doesn’t work on Mac OS, due to the lack of support for AF_PACKET sockets.

Re-signing iOS apps

I am occasionally presented with a packaged iOS .ipa archive by a third-party developer, which is intended for in-house distribution (using an Apple Developer Enterprise certificate), or for App Store distribution using a different developer account.

Re-signing is a quick and simple way of delivering an app when a developer won’t provide you with their Xcode project source from which to spin your own build.

I previously used the iReSign utility to accomplish this, but found that this wouldn’t work in all cases, in particular when the app includes linked frameworks or libraries (which results in errors such as “DYLD, Library not loaded“).

To solve this I wrote the shell script below. It takes an existing .ipa archive, embeds your own developer provisioning profile, replaces any existing code signatures and packages it again for distribution.

Please use with my compliments and leave a comment if this helps you out.

(Note: This script has a dependency on command line tools such as PlistBuddy and codesign, so you will likely need to install Apple’s Xcode developer tools)

Replace DEVCERT with the Common Name of your own Apple developer certificate.

# Re-sign an IPA with specified developer certificate (present in keychain)

DEVCERT="iPhone Distribution: Your Developer Cert Name"

if [ $# -eq 0 ]

  echo "Usage: $0 [app.ipa] [provprofile] [bundleid]"
  if [ ! -e "$SOURCEIPA" ]
    echo "Error: $SOURCEIPA not found"

  if [ ! -e "$MOBILEPROV" ]
    echo "Error: $MOBILEPROV not found"

  SIGNEDAPP=`echo $SOURCEIPA | awk -F".ipa" '{ printf ("%s-signed.ipa", $1) }'`
  unzip -qo "$SOURCEIPA" -d $TMPDIR
  APP=$(ls ${TMPDIR}/Payload/)

  if [ ! -z "$BUNDLEID" ]
     echo "Changing Bundle ID to ${BUNDLEID}";
     /usr/libexec/PlistBuddy -c "Set:CFBundleIdentifier $BUNDLEID" "${TMPDIR}/Payload/${APP}/Info.plist"

  cp "$MOBILEPROV" "${TMPDIR}/Payload/${APP}/embedded.mobileprovision"
  security cms -D -i "${TMPDIR}/Payload/${APP}/embedded.mobileprovision" > Entitlements_full.plist
  /usr/libexec/PlistBuddy -x -c 'Print:Entitlements' Entitlements_full.plist > Entitlements.plist
  echo "Re-signing with certificate: $DEVCERT"

  for folder in `find -d ${TMPDIR} \( -name "*.app" -or -name "*.appex" -or -name "*.framework" -or -name "*.dylib" \)`; do
    /usr/bin/codesign --continue -f -s "$DEVCERT" --entitlements "Entitlements.plist" "$folder"

  echo "Package the signed IPA"
  cd $TMPDIR
  zip -qry ../${SIGNEDAPP} *
  cd ..
  rm -rf $TMPDIR
  rm Entitlements_full.plist


EncFS for OS X Yosemite

securecloud It’s about time I updated my instructions for installing and running an EncFS filesystem on Mac OS X, synchronised to Dropbox. Use a combination of FUSE for OS X, EncFS, Dropbox and DropSec to create and maintain a super-secure filesystem which syncs with the cloud, while maintaining

  1. Download and install FUSE for OS X (the MacFUSE compatibility layer is not required)
  2. If you don’t have it already, install the Homebrew package manager
  3. Download and install EncFS (v1.7.5_1 at time of writing) and any dependencies, it’s as easy as ‘brew install homebrew/fuse/encfs
  4. Download DropSec, extract from the archive and copy it to your Applications folder

To create a new encrypted volume (stored locally at first to prevent your EncFS key from being synchronised with Dropbox):

encfs ~/Desktop/_Encrypted ~/Documents/_DropSec

Answer ‘yes’ when prompted to create the new folders and choose ‘p’ for pre-configured paranoia mode (256-bit AES encryption). Enter a secure EncFS password when prompted and you’re done. Now the filesystem has been created we can deal with securing the key.

umount ~/Documents/_DropSec
mkdir ~/.keys
mv ~/Desktop/_Encrypted/.encfs6.xml ~/.keys/dropsec.xml

The commands above move your key from the EncFS filesystem into a hidden folder in your (local) home directory Now move the entire ~/Desktop/_Encrypted folder (minus your key) into your Dropbox:

mv ~/Desktop/_Encrypted ~/Dropbox/

To mount the secure filesystem run the DropSec app from your Application folder. The first time you run DropSec it will prompt you for your EncFS password which it stores in your local login keychain. The password must match the secure password you set earlier.

When the secure volume is mounted a DropSec folder with a padlock icon will appear on your desktop. If it doesn’t, check that you have ‘Show Connected servers’ checked in Finder preferences.

To mount or unmount the encrypted volume simply run the DropSec app. For convenience copy it to your Mac OS dock for quick access.

WhatsApp Web is keeping my Mac awake

The new WhatsApp Web client is a welcome companion to the hugely popular WhatsApp Messenger cross-platform mobile application. It allows users to link their browser to their WhatsApp account and interact with chat sessions just like you do in the mobile app.

So far so good, but I have encountered one significant drawback. If you run the web client in a Google Chrome session on Mac OS X then a kernel assertion is established which prevents the system from sleeping, regardless of energy saver system preferences.

With the WhatsApp Web client running:

$ /usr/bin/pmset -g assertions
2015-01-29 17:47:11 +0000 
Assertion status system-wide:
 BackgroundTask 0
 ApplePushServiceTask 0
 UserIsActive 0
 PreventUserIdleDisplaySleep 0
 PreventSystemSleep 0
 ExternalMedia 0
 PreventUserIdleSystemSleep 1
 NetworkClientActive 0
Listed by owning process:
 pid 346(coreaudiod): [0x0006336d00011046] 00:00:50 PreventUserIdleSystemSleep named: "" 
 Created for PID: 12006.

With the WhatsApp Web session closed:

$ /usr/bin/pmset -g assertions
2015-01-29 17:47:23 +0000 
Assertion status system-wide:
 BackgroundTask 0
 ApplePushServiceTask 0
 UserIsActive 0
 PreventUserIdleDisplaySleep 0
 PreventSystemSleep 0
 ExternalMedia 0
 PreventUserIdleSystemSleep 0
 NetworkClientActive 0

I assume that this sleep issue is related to the notification feature of WhatsApp Web, since the assertion references Mac OS X’s coreaudiod process. Turning off desktop alerts and sounds in the client settings does not fix it however, so for the moment it doesn’t seem possible to prevent this system insomnia from occurring.

I shall contact WhatsApp product support and see what they can do.

And have you left Twitter?

This was the question recently posed by a friend at the end of an email.

The quick answer is yes!

I have also deleted my LinkedIn, Google+ and profiles.

The next question I presume would be to ask me why?

To be frank, despite my long and illustrious association with the Internet and the various communication protocols it carries, I’ve never been much of a social networker. I’ve never used Facebook, Instagram or Pinterest – and don’t have any burning desire to!

I have been a member of the LinkedIn community since 2004. I viewed it as a handy tool for making business contacts and perhaps career development, but that view has changed. I found their ‘people you may know‘ recommendations disturbingly accurate. I don’t like an algorithm being able to piece together my social interactions in such fine detail. Next it was the nagging endorsement solicitations, avoiding them was harder than dodging chuggers.

The final nail in the coffin was the weekly ‘profile views’ email showing exactly who had been looking me up. At first it was interesting in a voyeuristic way, but it quickly dawned on me that the owners of the profiles I’d been idly browsing would also receive these notifications. The day I received an email from LinkedIn with a smiling photo of one of my exes, I took affirmative action and deleted my account.

Twitter is a slightly different story. Again I was a fairly early adopter, opening my account in January 2009. As an information broadcast medium I like the Twitter model. I used it primarily for keeping up to date with local events and a route for making complaints to service companies (Hello SW_Trains !)

What I wasn’t comfortable with however was the realisation that I had become slightly addicted to the constant stream of news and miscellany. Feeding my information junkie habit became an all too frequent distraction.

So I decided to go cold turkey and simply uninstalled the mobile app. After a couple of days the urge to automatically check Twitter (after email and BBC News) gradually subsided.

Let’s see how long I last 🙂

Share your opinions?

It seems that every time I make any kind of purchase from an online retailer I’m soon bombarded with demands requests from various associated websites to provide my feedback / ratings / opinions / reviews.

Don’t get me wrong, I’m all for user-generated content and I often consult sites like TripAdvisor and Amazon for product reviews. What I object to is being hounded for my feedback.

Take this recent example:

Boots Opinions

As it happens my recent purchase from Boots was not for myself, so I don’t have an opinion. Boots did at least provide an unsubscribe link, but even that reveals the level to which I will be harassed for my feedback:

Manage your subscriptions

How about if I don’t review the product after 4 days then you get the message that I’m not interested and leave me the hell alone?

I thought I’d take a look at the Boots small print anyway.

“By submitting your reviews you agree to us using your opinions.”

That sounds fair enough, but to be thorough we really should take a look at the full Terms & Conditions (like everyone does of course!).

There is the expected legalise around content ownership and intellectual property rights (i.e. I am the author and I voluntarily waive all rights to my content), some sensible clauses about my not submitting false or defamatory comments, but then it takes a darker twist.

You agree to indemnify and hold Boots UK Limited (and its officers, directors, agents, subsidiaries, joint ventures, employees and third-party service providers, including but not limited to Bazaarvoice, Inc.), harmless from all claims, demands, and damages (actual and consequential) of every kind and nature, known and unknown including reasonable attorneys’ fees, arising out of a breach of your representations and warranties set forth above, or your violation of any law or the rights of a third party.

Really? In this highly litigious world we live in I don’t know who I might be offending by what I’ve written about a product. I’m not prepared to bankrupt myself defending Boots against someone who doesn’t like what I’ve said. Should I purchase legal indemnity insurance before posting a review?

For any content that you submit, you grant Boots UK Limited a, perpetual, irrevocable, royalty-free, transferable right and license to use, copy, modify, delete in its entirety, adapt, publish, translate, create derivative works from and/or sell and/or distribute such content and/or incorporate such content into any form, medium or technology throughout the world without compensation to you.

I accept that if I agree to submit some words then they can use what I’ve written, but what’s this about modifying, adapting and creating derivative works? What if I’ve honestly had a bad experience with a particular product and want to share that with the readers? Does that mean they can change what I’ve written and still attribute it to me? That sounds a bit scary.

As I read on I discover that my hypothetical bad review would not be published anyway. Their terms state “The following is not acceptable on this site: Disparaging reference to a healthcare product, company, institution or medical profession”.

Since Boots is predominantly a healthcare retailer, it is highly likely that any review I care to leave will be about a healthcare product, but I guess they only want positive feedback.

Thank you Boots for the offer, but I’ll pass on sharing my opinions.