Why the UK Porn Block is an Awful Idea

From 15 July 2019, the UK’s age verification system for online pornography will become mandatory. Here’s why it’s a terrible idea.

  1. It actually doesn’t block much porn at all. It only applies to commercial porn, which you need a credit card to access anyway, and children generally don’t have credit cards. It doesn’t apply to porn on social media, free sites, or P2P sharing, which is much easier to access.
  2. It will likely do more harm than good. It may provide many parents with a false sense of security that their children can no longer access porn online, resulting in a lower emphasis being placed on parents properly managing their childrens’ internet access. Parental controls on home wifi, home computers, and mobile devices are widely available and relatively easy to use.
  3. It plays into the hands of the big commercial porn providers. The main age verification system (AgeID) is owned by the same company that runs the most popular and lucrative porn websites in the world. The largest porn company in the world is being tasked with controlling access to porn. Already, some smaller businesses in the realms of ethical porn and feminist porn have shut down because implementation of this system is too expensive for them. If we’re going to have porn on the internet (and who are we kidding, there will always be porn on the internet), do we want it controlled by one big US firm?
  4. It has serious privacy implications. The age verification systems will contain the personal information and erotica browsing history for every adult who’s ever wished to access online porn from July onwards. If (or more realistically, when) this database is breached, it will be a treasure trove for identity thieves and blackmailers.
  5. It just won’t work. Technologically, it’s easy to bypass the system. Because it only applies to the UK, a simple VPN to break out to a different country will easily and cheaply circumvent most controls. At the same time, as has been seen in China, India and other authoritarian regions, consumers simply switch to other channels, such as torrenting, social media, newsgroups (yes, they’re still a thing), and the dark web.
  6. It’s based on flawed evidence. Whilst there’s anecdotal evidence that children “stumble across” online porn, there’s very little evidence that they access commercial porn sites, particularly when parents make some effort to manage internet access. The main study cited as the catalyst for the Act “found” that “almost a tenth of all 12- to 13-year-olds thought they were “addicted” to pornography”, and was carried out by OnePoll, the same people who generate such hard-hitting research as “German men are the world’s worst lovers” and “Fifty percent of British adults think Mount Everest is in the UK“. There is evidence that children access porn online, and some evidence that it’s harmful, and some that it isn’t as harmful as you’d think. Whichever way it’s cut, this age-verification approach is not evidence-based.
  7. It’s censorship and control. It provides a mechanism for the government to monitor online activity and decide what content is acceptable or unacceptable for the population to access, and change this definition as they see fit. The terms in the act even include the ability to block “material other than the offending material”. We may trust today’s government (though do you, really?), but we’d be foolish to implicitly trust future governments not to extend the controls to other content. As the award-winning English lawyer Myles Jackman put it, “Pornography is the canary in the coal mine of free speech: it is the first freedom to die. If this assault on liberty is allowed to go unchallenged, other freedoms will fall as a consequence.”

Technologically, this approach is fundamentally flawed, is unlikely to work at all, and creates some worrying implications for digital identity and privacy in the hands of large US corporations.

Anonymous feedback can destroy your team

Feedback sucks. Advice is better.

First of all, feedback sucks. It really does.

Unless the person delivering the feedback is highly empathetic, has lots of free time, is highly skilled and is in the proper position to provide it, and the person receiving it is in the right frame of mind, open to feedback, confident, mature and in a safe place, it’s probably going to be uncomfortable at best or at worst, devastating.

Delivering feedback is hard. In my experience managing teams over a couple of decades, I’ve seen it done so badly that it verges on abuse (in fact, on occasion it certainly was abuse), and despite my best efforts, I’ve have delivered feedback so badly that the relationship took months to recover. I’ve learned from those experiences, and now I’m better, but certainly not perfect.

But ultimately it is important to give and receive feedback if we want to get better at the things we care about. Given how incredibly hard it is to deliver feedback in person, why would we facilitate anonymous feedback?

A misguided solution.

Anonymous feedback is often presented as a solution to problems including unequal power dynamics, bias, fear, or a lack of candour. In reality, anonymous feedback masks or even exacerbates those problems. Great leadership and management solves, or should solve, those problems.

Anonymity reinforces the idea that it’s not safe to speak up. It’s mistaken for objectivity. It presumes that the people who receive it will interpret it exactly as it was intended.

Feedback must be contextual. It must also be actionable, otherwise why provide it?

Conversations matter.

The reason we deliver feedback in person is because it demands a discussion; for example, imagine someone wishes to give you feedback on the way I behaved in a meeting because you came across as aggressive and intolerant. You’d certainly want to know, but you would also want them to know that an hour before that meeting, you’d received some upsetting family news and were struggling to deal with it. That conversational feedback then provides a channel for an open and frank discussion, and an opportunity to support each other.

If that same feedback was delivered anonymously, not only is your theoretical self having a tough time with family problems, but now (in your head, for that is where we all reside) you’re overly aggressive, intolerant, and failing in your role.

Feedback must be actionable.

Anonymous feedback is incredibly difficult to act upon, and can breed a sense of frustration, fear, and resentment, particularly in small teams and organisations.

All feedback must be a conversation. And in order to have a conversation, you must be able to converse with the other party.

You may work in a high-trust, low-politic environment. Or you may believe that you do, since rarely is this truly the case. If you believe that you do, check your privilege. Are you experienced, senior, well paid, white, cis, male, able-bodied or neurotypical? Chances are, for those that are not in those categories, the degree of trust and safety they feel may be somewhat lower, and the impact of feedback considerably greater.

Unconscious bias

There are numerous biases in effect when it comes to feedback and indeed all interpersonal relationships, particularly in the workplace. For example, women are often perceived as more aggressive than men when demonstrating the same behaviour, due to an unconscious bias that women should be more feminine.

Anonymous feedback, rather than removing that bias, enables it, and feeds it, because a woman receiving anonymous feedback that she should “be less aggressive” is forced to accept it as objective, when it’s actually less likely to be the case.

Bias affects everyone. A man may receive feedback suggesting he should be less softly spoken in meetings, an introvert may be told they should speak up more, or (and this happens a lot) a young woman may be told to smile more.


Consider the motivations for someone providing anonymous feedback. One reason might be that they genuinely want you to be better, and they already think you’re great, so they’re giving you a chance to excel even more. That’s the only good reason for feedback. All others, including power-plays, envy, bias, inexperience, or simple misunderstanding of the situation, are terrible reasons, and will only have a negative impact on the team.

The point is that when providing feedback, even if your intentions are pure, you will not be aware of your unconscious bias, and working through those biases is that is something that only a conversation can facilitate.


In every single 1-1 you have with a team member, ask what you can do better, what more or less you could be doing, or what, if anything you could change in you interactions with team members. This regular, light-touch, conversational cadence provides a safe space for feedback. And even if in 99% of the sessions, there is no feedback to give, it ensures that when there is some feedback required, it comes easily, and isn’t a difficult process.

Anonymity encourages poor leadership.

Anonymous feedback processes also provide a get-out, an excuse, for poor leadership and avoiding conversations where feedback is requested or proffered. The thinking may be “I no longer need to ask what more I can do or how I can be better, since we have regular anonymous feedback instead.” This is dangerous, and leads to a general degradation of good leadership practices.

For these reasons, I never provide or accept anonymous feedback. I will always, instead, have a conversation.


If you’re tempted to use anonymous surveys and feedback, ask yourself why you feel that anonymity is required, and address the underlying issues. A truly great culture doesn’t require anonymity, and an organisation without a great culture is not maximising the potential of the people within it.

Using Hugo and AWS to build a fast, static, easily managed and deployed website.

Most of my websites are built using WordPress on Linux in AWS, using EC2 for compute, S3 for storage and Aurora for the data layer. Take a look at sono.life as an example.

For this site, I wanted to build something that aligned with, and demonstrated some of the key tenets of cloud technology – that is: scalability, resiliency, availability, and security, and was designed for the cloud, not simply in the cloud.

I chose technologies that were cloud native, were as fast as possible, easily managed, version controlled, quickly deployed, and presented over TLS. I opted for Hugo, a super-fast static website generator that is managed from the command line. It’s used by organisations such as Let’s Encrypt to build super fast, secure, reliable and scalable websites. The rest of my choices are listed below. Wherever possible, I’ve used the native AWS solution.

The whole site loads in less than half a second, and there are still improvements to be made. It may not be pretty, but it’s fast. Below is a walk through and notes that should help you build your own Hugo site in AWS. The notes assume that you know your way around the command line, that you have an AWS account and have a basic understanding of the services involved in the build. I think I’ve covered all the steps, but if you try to follow this and spot a missing step, let me know.

Notes on Build – Test – Deploy:

Hugo was installed via HomeBrew to build the site. If you haven’t installed Homebrew yet, just do it. Fetch by running:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then install Hugo:
brew install hugo

One of the things I love about Hugo is the ability to make rapid, on-the-fly changes to the site and see the result instantly, running the Hugo server locally.

hugo server -w -D

The option -D includes drafts in the output, whilst -w watches the filesystem for changes, so you don’t need to rebuild with every small change, or even refresh in the browser.

To create content, simply run

hugo new $postname.md

Then create and edit your content, QA with the local Hugo server, and build the site when you’re happy:

hugo -v

V for verbose, obvs.

You’ll need to install the AWS CLI, if you haven’t already.

brew install awscli

Check it worked:

aws --version

Then set it up with your AWS IAM credentials:

aws configure
AWS Access Key ID [None]: <your access key>
AWS Secret Access Key [None]: <your secret key>
Default region name [None]: <your region name>
Default output format [None]: ENTER

You don’t need to use R53 for DNS, but it doesn’t cost much and it will make your life a lot easier. Plus you can use funky features like routing policies and target health evaluation (though not when using Cloudfront distributions as a target).

Create your record set in R53. You’ll change the target to a Cloudfront distribution later on. Create the below json file with your config.

            "Comment": "CREATE/DELETE/UPSERT a record ",
            "Changes": [{
            "Action": "CREATE",
                        "ResourceRecordSet": {
                                    "Name": "a.example.com",
                                    "Type": "A",
                                    "TTL": 300,
                                 "ResourceRecords": [{ "Value": ""}]
And run:
aws route53 change-resource-record-sets --hosted-zone-id ZXXXXXXXXXX --change-batch file://sample.json

Create a bucket. Your bucket name needs to match the hostname of your site, unless you want to get really hacky.

aws s3 mb s3://my.website.com --region eu-west-1

If you’re using Cloudfront, you’ll need to specify permissions to allow the Cloudfront service to pull from S3. Or, if you’re straight up hosting from S3, ensure you allow the correct permissions. There are many variations on how to do this – the AWS recommended way would be to set up an Origin Access Identity, but that won’t work if you’re using Hugo and need to use a custom origin for Cloudfront (see below). If you don’t particularly mind if visitors can access S3 assets if they try to, your S3 policy can be as below:

	  "Principal": "*",

Request your SSL certificate at this time too:

aws acm request-certificate --domain-name $YOUR_DOMAIN --subject-alternative-names "www.$YOUR_DOMAIN" 

ACM will automatically renew your cert for you when it expires, so you can sleep easy at night without worrying about SSL certs expiring. That stuff you did last summer at bandcamp will still keep you awake though.

Note: Regards Custom SSL client support, make sure to select ONLY SNI. Supporting old steam driven browsers on WinXP will cost you $600, and I don’t think you want that.

The only way to use https with S3 is to stick a Cloudfront distribution in front of it, and by doing this you get the added bonus of a super fast CDN with over 150 edge locations worldwide.

Create your Cloudfront distribution with a json config file, or straight through the cli.

aws cloudfront create-distribution --distribution-config file://distconfig.json

Check out the AWS documentation for details on how to create your config file.

Apply your certificate to the CF distribution too, in order to serve traffic over https. You can choose to allow port 80 or redirect all requests to 443. Choose “custom” certificate to select your cert, otherwise Cloudfront will use the Amazon default one, and visitors will see a certificate mismatch when browsing to the site.

When configuring my Cloudfront distribution, I hit a few issues. First of all, it’s not possible to use the standard AWS S3 origin. You must use a custom origin (specifying the region of the S3 bucket as below in order for pretty URLs and CSS references in Hugo to work properly. I.e.


instead of


Also, make sure to specify the default root object in the CF distribution as index.html.

Now that your CF distribution is ready, anything in your S3 bucket will be cached to the CF CDN. Once the status of your distribution is “deployed”, it’s ready to go. It might take a little while at first setup, but don’t worry. Go and make a cup of tea.

Now, point your R53 record at either your S3 bucket or your Cloudfront disti. You can do this via the cli, but doing it via the console means you can check to see if your target appears in the list of alias targets. Simply select “A – IPv4 address” as the target type, and choose your alias target (CF or S3) in the drop down menu.

Stick an index.html file in the root of your bucket, and carry out an end-to-end test by browsing to your site.

Build – Test – Deploy

Now you have a functioning Hugo site running locally, S3, R53, TLS, and Cloudfront, you’re ready to stick it all up on the internet.

Git push if you’re using Git, and deploy the public content via whichever method you choose. In my case, to the S3 bucket created earlier:

aws s3 cp public s3://$bucketname --recursive

The recursive switch ensures the subfolders and content will be copied too.

Crucially, because I’m hosting via Cloudfront, a new deploy means the old Cloudfront content will be out of date until it expires, so alongside every deploy, an invalidation is required to trigger a new fetch from the S3 origin:

aws cloudfront create-invalidation --distribution-id $cloudfrontID  --paths /\*

It’s not the cleanest way of doing it, but it’s surprisingly quick to refresh the CDN cache so it’s ok for now.

Time to choose a theme and modify the hugo config file. This is how you define how your Hugo site works.

I used the “Hermit” theme:

git clone https://github.com/Track3/hermit.git themes/hermit

But you could choose any theme you like from https://themes.gohugo.io/

Modify the important elements of the config.toml file:

baseURL = "$https://your-website-url"
languageCode = "en-us"
defaultContentLanguage = "en"
title = "$your-site-title"
theme = "$your-theme"
googleAnalytics = "$your-GA-UA-code"
disqusShortname = "$yourdiscussshortname"

Get used to running a deploy:

hugo -v
aws s3 cp public s3://your-site-name --recursive
aws cloudfront create-invalidation --distribution-id XXXXXXXXXX  --paths /\*

Or, to save time, set up npm to handle your build and deploy. Install node and NPM if you haven’t already (I’m assuming you’re going to use Homebrew again.

$ brew install node

Then check node and npm are installed by checking the version:

npm -v


node -v

All good? Carry on then:

npm init

Create some handy scripts:

    "name": "hugobuild",
    "config": {
        "LASTVERSION": "0.1"
    "version": "1.0.0",
    "description": "hugo build and deploy",
    "dependencies": {
        "dotenv": "^6.2.0"


    "devDependencies": {},
    "scripts": {
        "testvariable": "echo $npm_package_config_LASTVERSION",
        "test": "echo 'I like you Clarence. Always have. Always will.'",
        "server": "hugo server -w -D -v",
        "build": "hugo -v",
        "deploy": "aws s3 cp public s3:// --recursive && aws cloudfront create-invalidation --distribution-id  --paths '/*'"
    "author": "Tom Geraghty",
    "license": "ISC"

Then, running:

npm run server

will launch a local server running at http://localhost:1313


npm run build

will build your site ready for deployment.


npm deploy

will upload content to S3 and tell Cloudfront to invalidate old content and fetch the new stuff.

Now you can start adding content, and making stuff. Or, if you’re like me and prefer to fiddle, you can begin to implement Circle CI and other tools.

Notes: some things you might not find in other Hugo documentation:

When configuring the SSL cert – just wait, be patient for it to load. Reload the page a few times even. This gets me every time. The AWS Certificate manager service can be very slow to update.

Take a look at custom behaviours in your CF distribution for error pages so they’re cached for less time. You don’t want 404’s being displayed for content that’s actually present.

Finally, some things I’m still working on:

Cloudfront fetches content from S3 over port 80, not 443, so this wouldn’t be suitable for secure applications because it’s not end-to-end encrypted. I’m trying to think of a way around this.

I’m implementing Circle CI, just for kicks really.

Finally, invalidations. As above, if you don’t invalidate your CF disti after deployment, old content will be served until the cache expires. But invalidations are inefficient and ultimately cost (slightly) more. The solution is to implement versioned object names, though I’m yet to find a solution for this that doesn’t destroy other Hugo functionality. If you know of a clean way of doing it, please tell me 🙂


Compliance in DevOps and public cloud.

As a DevOps engineer, you’ve achieved greatness. You’ve containerised everything, built your infrastructure and systems in the cloud and you’re deploying every day, with full test coverage and hardly any outages. You’re even starting to think you might really enjoy your job.

Then why are your compliance teams so upset?

Let’s take a step back. You know how to build secure applications, create back ups, control access to the data and document everything, and in general you’re pretty good at it. You’d do this stuff whether there were rules in place or not, right?

Not always. Back in the late 90’s, a bunch of guys in suits decided they could get rich by making up numbers in their accounts. Then in 2001 Enron filed for bankruptcy and the suits went to jail for fraud. That resulted in the Sarbanes-Oxley Act, legislation which forced publicly listed firms in the US to enforce controls to prevent fraud and enable effective audits.

Sarbanes-Oxley isn’t the only law that makes us techies do things certain ways though. Other compliance rules include HIPAA, ensuring that firms who handle clinical data do so properly; GDPR, which ensures adequate protection of EU citizens’ personal data; and PCI-DSS, which governs the use of payment card data in order to prevent fraud (and isn’t a law, but a common industry standard). Then there are countless other region and industry specific rules, regulations, accreditations and standards such as ISO 27001 and Cyber Essentials.

Aside from being good practice, the main reason you’d want to abide by these rules is to avoid losing your job and/or going to jail. It’s also worth recognising that demonstrating compliance can provide a competitive advantage over organisations that don’t comply, so it makes business sense too.

The trouble is, compliance is an old idea applied to new technology. HIPAA was enacted in 1996, Sarbanes-Oxley in 2002 and PCI DSS in 2004 (though it is frequently updated). In contrast the AWS EC2 service only went out of beta in late 2008, and the cloud has we know it has been around for just a few years. Compliance rules are rarely written with cloud technology in mind, and compliance teams sometimes fail to keep up to date with these platforms or modern DevOps-style practices. This can make complying with those rules tricky, if not downright impossible at times. How do you tell an auditor exactly where your data resides, if the only thing you know is that it’s in Availability Zone A in region EU-West-1? (And don’t even mention to them that one customer’s Zone A isn’t the same as another’s).

As any tech in a regulated industry will appreciate, compliance with these rules is checked by regular, painful and disruptive audits. Invariably, audits result in compliance levels looking something like a sine wave:

This is because when an audit is announced, the pressure is suddenly on to patch the systems, resolve vulnerabilities, update documents and check procedures. Once the audit is passed, everyone relaxes a bit, patching lags behind again, documentation falls out of date and the compliance state drifts away from 100%. This begs the question, if we only become non-compliant between audits, is the answer to have really, really frequent audits?

In a sense, yes. However, we can no longer accept that audits with spreadsheet tick box exercises, and infosec sign-off at deployment approval stage actually work. Traditional change management and compliance practices deliberately slow us down, with the intention of reducing the risk of mistakes.

This runs counter to modern DevOps approaches. We move fast, making rapid changes and allowing teams to be autonomous in their decision making. Cloud technology confuses matters even further. For example, how can you easily define how many servers you have and what state they’re in, if your autoscaling groups are constantly killing old ones and creating new ones?

From a traditional compliance perspective, this sounds like a recipe for disaster. But we know that making smaller, more frequent changes will result in lower overall risk than large, periodic changes. What’s more, we take humans out of the process wherever possible, implementing continuous integration and using automated tests to ensure quality standards are met.

From a DevOps perspective, let’s consider compliance in three core stages. The first pillar represents achieving compliance. That’s the technical process of ensuring workloads and data are secure, everything is up to date, controlled and backed up. This bit’s relatively easy for competent techs like us.

The second pillar is about demonstrating that you’re compliant. How do you show someone else, without too much effort, that your data is secure and your backups actually work? This is a little more difficult, and far less fun.

The third pillar stands for maintaining compliance. This is a real challenge.  How do you ensure that with rapid change, new technology, and multiple teams’ involvement, the system you built a year ago is still compliant now? This comes down to process and culture, and it’s the most difficult of the three pillars to achieve.

But it can be done. In DevOps and Agile culture, we shift left. We shorten feedback loops, decrease batch size, and improve quality through automated tests. This approach is now applied to security too, by embedding security tests into the development process and ensuring that it’s automated, codified, frictionless and fast. It’s not a great leap from there towards shifting compliance left too, codifying the compliance rules and embedding them within development and build cycles.

First we had Infrastructure as Code. Now we’re doing Compliance as Code. After all, what is a Standard Operating Procedure, if not a script for humans? If we can “code” humans to carry out a task in exactly the same way every time, we should be able to do it for machines.

Technologies such as AWS Config or Inspec allow us to constantly monitor our environment for divergence from a “compliant” state. For example, if a compliance rule deems that all data at rest is encrypted, we can define that rule in the system and ensure we don’t diverge from it – if something, human or machine, creates some unencrypted storage, it will be either be flagged for immediate attention or automatically encrypted.

One of the great benefits of this approach is that the “proof” of compliance is baked into your system itself. When asked by an auditor whether data is encrypted at rest, you can reassure them that it’s so by showing them your rule set. Since the rules are written as code, the documentation (the proof) is the control itself.

If you really want your compliance teams to love you (or at least quit hassling you), this automation approach can be extended to documentation. Since the entire environment can be described in code at any point in time, you can provide point-in-time documentation of what exists in that environment to an auditor, or indeed at any point in time previously, if it’s been recorded.

By involving your compliance teams in developing and designing your compliance tools and systems, asking what’s important to them, and building in features that help them to do their jobs, you can enable your compliance teams to serve themselves. In a well designed system, they will be able to find the answers to their own questions, and have confidence that high-trust control mechanisms are in place.

Compliance as Code means that your environment, code, documentation and processes are continuously audited, and that third, difficult pillar of maintaining compliance becomes far easier:

This is what continuous compliance looks like. Achieve this, and you’ll see what a happy compliance team looks like too.


Re:Develop.io History of DevOps talk

I recently gave a talk at Re:Develop.io about the history of DevOps, and this page is where you can find the slide deck and other relevant resources.

Video of the talk

Re:develop.io DevOps Evolution Slide deck

The Theory of constraints

Agile 2008 presentation by Patrick DuBois

10+Deploys per day, Dev and Ops at Flickr – Youtube

10+deploys a day at Flickr – slide deck


Nicole Forsgren research paper

2018 State of DevOps Report

My “Three Ways” slide deck

Safety culture

Amazon DevOps Book list

Deming’s 14 points of management

Lean management

The Toyota Way

The Agile Manifesto

Beyond the phoenix project (audio)

Netflix – simian army

My Continuous Lifecycle London talk about compliance in DevOps and the cloud





Going solo

This is the view from where I’m living now.

I’ll explain. A couple of months ago, my partner was offered a once-in-a-lifetime opportunity to live and work in Andalusia, doing digital marketing for an organisation that is part retreat centre, part permaculture farm, and part yoga teacher training school. With brexit looming and faced with such a great opportunity to do something very different, we both rapidly left our jobs in the UK, packed up what stuff we didn’t get rid of or put in storage, and moved.

All of which means I’m now working with the organisations here (suryalila.comdanyadara.com and froglotusyogainternational.com ) alongside developing my own consultancy business and working as CTO for ydentity.com (so new we still have lorem ipsum text). I will freely admit that coming off the salary drug is a tough task, but having the freedom to do my own thing, develop my skills and work the hours that I want is proving very satisfying so far.

For the moment, I’m getting involved in a really wide range of work, from project management, tech consultancy, AWS engineering, to digital marketing and analytics, security consultancy and more. The reason for me getting stuck into such a wide range of tasks is so I can really work on evaluating what the most suitable area is for me to focus on in the future, both from a perspective of what I’m good at and enjoy doing, and also what I find there is most demand for in the marketplace.

If you would like to work with me or you’d like to discuss an opportunity for us to collaborate, drop me a line through LinkedIn, email me at tom@tomgeraghty.co.uk or pop in to see me in Andalusia, if you can get past the goats on the highway.

GDPR, and how I spent a month chasing my data.

sherlock holmes basil rathbone

In May 2018, I received a letter from a local firm of solicitors, Roythornes, advertising a property investment event. I hadn’t heard of them and I was damn sure I hadn’t given them my permission write to me at home. They were wide of the mark to say the least- I’m an unlikely potential property tycoon, unless we’re playing Monopoly. Even then, I’m a long shot.

It was a quiet week at work so given the recent implementation of GDPR and the fact that I really don’t like junk mail, I thought I’d give the new Data Subject Access Request (DSAR) process a whirl.

I couldn’t find contact at Roythornes to send a DSAR to but, helpfully, GDPR places no restriction on the medium someone can use to make a request, so at around 9am that day I filled in their online contact form, despite my concerns that it would get picked up by a clueless admin assistant. I requested a copy of the data they hold on me, the source of that data and the evidence of my opt-in for direct mail. I also asked that they delete the data they hold on me and send no further marketing material.

At 1:42pm, I had a from “Norma” of Roythornes (not joking, sorry Norma), asking for a copy of the letter and stating that she couldn’t find me in their database. So far, so good…

At 1:55pm, I received an automated recall email from Norma.

A few hours later, another email arrived, this time from the firm’s “compliance partner”, stating that they had acquired my personal data in a mailing list they purchased from Lloyd James Media, on the 1st of May 2018, and that my letter was sent out on the 21st May 2018. She stressed that the purchase of the list, and the sending of the letter itself was prior to the GDPR implementation date of 25th May 2018, and therefore legal.

Solicitors abiding by the letter of the law, not the spirit of the law? Imagine that.

Dancing around technicalities notwithstanding, Roythornes did confirm that my data had been deleted and I wouldn’t be hearing from them again. Phase 1 complete, but who exactly were Lloyd James Media, and how did my data fall into their hands?

For Phase 2 of my quest, a quick google told me that Lloyd James Media “is a multi-channel data agency focusing on the intelligent use of data to optimise customer acquisition and retention.” I can only assume this translates as “we make and sell mailing lists”. So, off went my DSAR email to their sales email address, because yet again, there was no contact information available for non-sales enquiries, let alone DSARs.

Andrew of the compliance team at Lloyd James Media only took 24 hours to get back to me. He confirmed that they sold my personal data to Roythornes for a postal campaign. They had acquired my data from another firm, “My Offers”, and the consent for postal marketing was obtained by them, apparently. Helpfully,  Andrew suggested I get in touch with the “compliance team” at My Offers. Evidently, this is a team of one, someone called Saydan, whose email address Andrew provided. I reminded Andrew to remove my data from their system and headed off to continue the hunt for the true source of my data, feeling like a geek version of Bear Grylls tracking an elusive squirrel. Phase 3 had begun.

My Offers are “Europe’s leading online direct marketing company with a database of 22.2million registered users.” I fired my third DSAR email off to Saydan later that day. One week later, I’d heard nothing. According to GDPR, there is no need for an immediate response, as long as the DSAR is executed within a month, but the silence was unnerving. Was Saydan trying to ghost me? I found their Facebook page and sent a message to whichever poor soul supports their social channels. For good measure, I also dredged LinkedIn for their employees, emailed Ivan, one of their directors, and in true annoying millennial style, tweeted at them. The only response was from their Facebook team, who reiterated that I should email the enigmatic Saydan, then also went quiet on me.

Over the next few weeks, because nothing seemed to be happening, I pinged their facebook team a courtesy message once each week with a gentle reminder of the impending deadline for a response. Part of me was relishing the prospect of not getting a reply, and I began googling, “What to do if someone doesn’t respond to a DSAR.” I was way too invested in this.

Then, exactly one month to the day since the original request, an email from Ivan, the My Offers director arrived in my inbox. Ivan’s email was straight to the point and only had a few spelling mistakes. Attached was a password protected CSV file containing all the information I’d requested. The password was sent in a separate email. So far, so good (though, yet again, I had to remind him to remove my data from their systems).

The CSV file was interesting. And by interesting, I mean in the way that hearing the creak of a stair when you’re in bed, and there’s nobody else in the house is interesting. The data contained my full name, birth date, gender, home address, email address, phone number, data subject acquisition date and source (Facebook), as well as a list of businesses that my data had been shared with in the past year. The list totalled around 60, including Lloyd James Media, various PPI and no-win no-fee firms, and more. That explains all the marketing calls over the past year then.

This CSV file was the smoking gun. However, the trigger was evidently pulled by my own fair hand. At some point, possibly whilst drunk, bored at work, or both, I’d clicked on a campaign offering me a beard trimmer. I still don’t have a beard trimmer (I do have a beard), so I presumably I didn’t pursue this purchase but in getting only that far, I inadvertently provided My Offers with access to my personal data, and consent for direct marketing. Sounding eerily familiar, I wondered if my voting choices in the last election were my own making.

So, just over a month after I sent my first DSAR to a local firm, what have I learned from this?

Firstly, GDPR actually works. Not only was the DSAR process easy to do, it was free (for me), and two out of three firms responded within 24 hours. Presumably GDPR is also helping to reduce unwanted junk mail; after all, Roythornes as good as admitted that they wouldn’t have posted the initial letter to me after the GDPR implementation date.

Secondly, once your data is out there, it gets around. It only takes one “online direct marketing company” to get hold of it, and your personal information will spread faster than nationalism in Europe.

Finally, don’t be dumb on facebook (like me). We know about Cambridge Analytica of course, but they’re not the only guys trying to harvest information and profit from it. Resist the lure of data-harvesting surveys and competitions, even when drunk.

Compliance in the Cloud

Continuous Lifecycle London slide deck:


AWS compliance information:


ENISA cloud computing security doc:


AWS security products:


Life without SSH:





Contino Compliance as Code pdf:


Curve is making using money whilst traveling much easier.

Most people who know me are somewhat aware that I travel quite a lot. I love visiting new places, and I really enjoy being on the move. One thing that often bugs me, however, is how awkward using money in different countries can be.

Getting local cash at a decent rate can be a pain. Using an ATM abroad incurs fees from your bank, and you don’t necessarily get good rates. Going to a currency exchange can be a hassle too. I usually carry some dollar notes on me anyway, because they’re accepted almost everywhere.

Using your debit or credit card abroad incurs yet more fees, with unpredictable and usually poor rates.

This is where my new Curve card comes in. A Curve card essentially acts as a proxy between the world and your existing cards. You can add multiple credit and debit cards to it, and select which one to use for each payment (or even change it afterwards!). Using your Curve card doesn’t incur any currency conversion fees, and you receive a better rate than most high street currency exchanges.

Cleverly, all the transactions on your Curve appear as purchases on the “source” cards, which means you can also take cash out of an ATM using your Curve card, and choose to source the cash from any of your cards, including credit cards (without incurring the cash advance fees that you normally would), debit cards and pre-paid cards.

So what does this mean for travelers? Firstly, using your Curve card saves you money abroad, both when using it to purchase goods and services, or getting cash from an ATM.

Secondly, it’s far more secure. Just take your Curve out with you, and leave your main cards in the safe at the hotel, or simply keep them elsewhere on your person. If your Curve card gets stolen or lost, simply open the app and deactivate it. Even if it somehow got cloned by some unscrupulous bartender or waiter, you’ll receive instant alerts of any payments, so you’d know the instant it was used, which means you could instantly disable the card and request a refund.

Thirdly, you get real-time feedback and notifications, making budgeting far easier. You can tag your purchases, add notes, and scan receipts to add to purchases. This means you can keep track of your spending, check how much you’re spending on travel, food, shopping, etc, and even use it to form the basis of your expenses claim if travelling for business.

In my opinion, Curve is still lacking a few features though. You can’t yet add it to Apple Pay, which would streamline payments even further. You can’t add a single debit or credit card to multiple Curve accounts either. The reason for this is that when travelling as a group or a couple, you could all add some money into a shared pre-paid card (e.g. Monzo), and then add that to your individual Curves. This would solve all those split-payment problems when you’re paying for supplies or travel costs for the whole group. If there’s any “debate” around a certain item being charged to the group card, it’s easy to “go back in time” (as Curve put it), and charge it to a different (i.e. personal) card.

I’m pretty sure the group payment challenge is solvable, either with existing tech, or by someone shortly bringing out fintech joint accounts. Either way, using Curve has definitely made my travelling life a lot easier, and I’m excited to see what they do next.

Shameless promo: sign up for Curve here with code NPWZA and you’ll get £5, and so will I.

Embrace the silence

When i am silent, i have thunder hidden inside me.

Over the years in my career so far, I’ve found that in some (many) situations, my speaking style in meetings doesn’t always “work” effectively.

Some background: when I was young, I was diagnosed with dyspraxia, and had trouble forming sentences and speaking properly. I had speech therapy until the age of around 8 years old. The word “hammer” was a particular challenge for me, apparently. I don’t know why. I can say hammer really well now. Try me.

As a result of this (or maybe it’s just coincidental), I often pause before speaking, particularly when in a larger group, or in a situation where what I say really matters. It’s partly to formulate the content, the idea, the concept, but also to establish the “how” of it; i.e. how to structure the sentences, what phrasing to use, and how the statement is to be delivered.

Now, this pause is useful for everyone. It allows for a more cogent, relevant and useful discussion.

But, people seem to feel the need to fill this audible space. Whether that’s a result of a discomfort with silence, or a desire to be the one speaking and presenting their ideas instead of me, I don’t know. I suspect both, in different scenarios. I don’t really care though, as it gives me more time to build my response anyway.

I guess I could be concerned that some might interpret a pause as a weakness, as some kind of hesitation because I don’t understand the subject matter, but I choose to ignore that concern, and focus instead on being me, and how I function best.

I wonder if we should all try to pause a little more. Think about what we say, how we say it, and how we deliver it. Imagine if meetings were 30% less talk, but with 50% better quality contributions as a result.

Embrace the silence. Embrace your own, and allow others to use theirs.