PayPal

I've used PayPal for years - it provides a payment platform which means I don't have to share my bank or card details with every organisation. It has - until recently - been good at maintaining an appropriate level of security on the account, and allows use of my preferred 2FA authentication apps.

However recently I've noticed a privacy-hostile attitude which is driving me away from the platform altogether.

One of the key benefits PayPal has created in recent years was linking to bank accounts directly, rather than using cards. This meant that when cards were replaced I would no longer need to update PayPal. If your PayPal account is compromised the attacker would be able to access your verified payment methods and make a load of purchases. If you noticed the hack you might cancel the cards - or cancel the direct debit on the bank account for PayPal.

Card issuers usually apply stronger anti-fraud than direct debit agreements, so it would be easier to make fraudulent payments through PayPal linked to bank accounts - which is why 2FA is really necessary.

If you notice issues, you could get in touch with PayPal and ask them to suspend the account until the issue can be verified.

So far so good.

However as I discovered towards the end of summer this year, and whilst overseas in the US recently, PayPal have become hostile to the kinds of privacy tools I use ... such as the VPN. If I tried to access my account whilst using a VPN that could be identified by PayPal, they would instantly lock my account.

I have MFA set up, and a verification phone number. That means that once I've entered the correct username and password the platform asks for a six digit number generated by an authentication app on one of my devices. That number sequence is unique to that device and cannot be moved to another device. The key (six digit number) is rotated every 30 seconds.

Occasionally I've seen them send me an OTP (one-time password) via SMS too, I would assume they do this both periodically to ensure the method continues to work, and if a string of transactions are unusual - but not totally suspect. However if someone has stolen your phone and unlocked it - don't use patterns, fingerprints or facepalm ID - they'll have access to your MFA key apps and SMS.

This is a standard approach - if you don't use one of these apps I'd recommend FreeOTP, which implements open standards and is open source (published by Red Hat).

I generally use a good level opsec across a number of different topics, and this is largely to remove my traffic data e.g. web and DNS, from access by companies monetising or filtering / traffic-shaping that data. A lot of the security work I do means that I want to reduce the information surface area as much as possible to prevent counter-investigation or intrusion.

When this PayPal account lockout happened the first time I phoned them and went through the security checks to get my account unlocked. Non-SMS MFA was part of that process which I was glad to see. Whilst the call handler was waiting for responses from the security team I asked why the account had been locked to start with.

I was told that the authentication platform had probably detected VPN use and assumed illicit access was being attempted. Although I pointed out that MFA was enabled and that an attacker would have to compromise four distributed devices to get to the information needed, the answer was that "...VPNs are an indicator of dangerous activity.". I've never heard anything so ridiculous.

Some months later I tried to login to PayPal to use a local food ordering service in the US, and again the account was initially blocked. Using a VoiP number for the UK I again spoke to PayPal and this time asked if my account could be marked to allow non-standard access, seeing that MFA was enabled. The call handler claimed that they couldn't do that, and that unless I accessed the website from my own country this would always happen.

Turns out the Android app does something similar and is thus effectively useless. Google also drives a lot of it's app infrastructure to get their permissions and access via Google Play Services, which means many apps no longer need to ask for specific permissions. I'm not 100% clear on whether that means that an app can access Body Sensors on-device via the Play Services service without explicit permission or not.

I've noticed that when using a safe DNS provider (either our own corporate network which strips malvertising or a public anti-ad DoH DNS provider), a number of apps fail authentication with errors. On initial inspection this appears to be because the tracking tools used are embedded in the authentication mechanism, and therefore disabled at a network level. PayPal appeared to have done this for a while as have TSB. Not sure tracking app usage during login is a good idea, especially if the tracking platform is somehow compromised. Tracking is not authentication or authorisation.

None of the security reasons given by PayPal for these approaches seemed to hold any water - why discriminate against VPN or Tor users? PayPal has historically been hack and breach free, it's still possible to get caught by phishing attacks. I don't open any emails alleging to be from PayPal (even payment receipts) as I would normally check the app on a regular basis.

Some configurations and bug bounties paid do make you wonder though.

To solve the problem at the time, I simply used a VPN through an existing tunnel to remote back to the UK and log in to PayPal. Although this time it was to cancel recurring payments and try and remove payment methods.

Despite removing all recurring payments associated with them, I was not allowed to remove any of the payment methods I'd asked to remove. I'll speak to the bank and cancel the direct debits instead - the first stage of replacing PayPal with something more privacy-friendly.

Maybe I'll go back to the protections of credit cards for online transactions, despite having to be concerned that organisations are not fully PCI-DSS compliant (or get hacked themselves).

DVLA Statistics - And How to Save £146m over ten years

Information is Free

Since becoming entangled with the DVLA, I'd raised a couple of Freedom of Information requests (FOIRs) and a subject access request (SAR). By law an authority is allowed 20 working days to respond to a FOIR, and can choose to either respond in full; respond in part (perhaps noting another authority which may hold the relevant information); or refuse to respond to the FOIR entirely.

In this last case authorities often hide behind the section 12 requirements, which detail the process to follow where the request exceeds the time or cost limits prescribed for different types of authority. I noted in my previous DVLA post in which instrument of law those limits are defined.

DVLA are set the ceiling of 4.5 man days or £600 - whichever is higher.

The scene is now set for each of the two FOIRs I raised.

FOIR #1 - Budget Information Relating to Physical Post

This should have been a fairly simple call to the DVLA accounts department, in order to get some basic information. I would have been fine with the more detailed item breakdowns being refused or declined, as long as the base figures were provided.

I asked the DVLA for figures relating to both the previous and current fiscal years:
- the DVLA budget for that year
- the amount spent printing documents to send to registered keepers e.g. fines, new V5Cs, reminders etc
- the amount spent on postage / delivery for these items

I expected the fiscal years for n-1 and n-2, rather than current (n) and n-1, as in-flight accounting is unlikely to be available. In the FOIR I was more specific as I thought it would help DVLA scope the request better, and leave less room for clarifications back to me. How wrong I was.

Initially the request was rejected under section 12 as being too onerous, until I pointed out that when working on programme budgets at most of my clients, I could get most of these numbers over the phone whilst I wait. I also pointed out that they'd already responded to my other request with the actual number of documents sent to drivers, which must have involved a similar amount of work (see the FOIR #2 section below).

I requested an internal review and DVLA responded with some of the information I'd asked for.

So the total spend on:

• all stationary was £1.1m in 2017-18 & £1.2m in 2018-19
• all postage was £25.9m in 2017-18 & £26.2m in 2018-2019
• all printing was £14.4m in 2017-18 & £14.2m in 2018-2019

The total expenditure across these items was effectively £41.4m and £41.6m in 2017 and 2018 effectively. Yet they still essentially refused to supply their overall budget for those years. As I couldn't find a reference to this figure anywhere else on gov.uk I was reliant on this single public sector organisation for those numbers.

I then asked them to reconsider their position but expect them to walk away from this request. Their initial response was later than the FOIA allows, and their responses were evasive at best.

You can see the live FOIR here for reference.

FOIR #2 - Document Production and Delivery Statistics

This one went a little better and information was slightly more forthcoming. But it was still a struggle to get basic information from them.

I asked the DVLA to provide statistics / their records for the following:
- The number of physical documents sent to registered keepers
- The number of those documents sent via some form of recorded delivery
- The number of known tracked items that have a "missing", "undelivered" or similar category applied after they have left DVLA

Despite the specificity of the request, three weeks later the DVLA asked me to clarify what documents I was referring to. I clarified regardless and the final (late) response to the FOIR was received almost a month later.

It turns out that the DVLA sent 99,461,763 documents from Jan 2018 to 25th October 2019. Based on 662 days in that period and assuming the report was generated on the same day as the DVLA response letter; the average number of documents sent per day is 150244(.355).

That's a lot of documents. Only about 32k of those in that 622 day period were sent via some sort of recorded delivery, and the DVLA does not track how many of those tracked items were returned or otherwise undelivered. The DVLA did not disclose how much they spent on tracked / recorded delivery, so this is an assumed and unknown uplift on the cost-per-document-sent.

Now if we combine the responses of FOIR #1 and FOIR #2 we can say (quickly excusing my shoddy maths) that:

1. In 2018-2019 DVLA spend £41,629,644 on document production (excluding 3rd party costs such as GSP)
2. In 2018-2019 we can infer that in 365 days - and using the docs / day from earlier in this FOIR - the DVLA sent 54839189(.57) docs in this year
3. Therefore the cost-per-item to the DVLA in 2018-2019 is £0.79
4. This does not include the DVLA operating expenditure on the processes surrounding this document e.g. hiring staff to manage the processes, interact with the processes and operate processes where necessary, recorded delivery costs, heating, lighting, utilities and other standard OpEx items. The actual cost is probably between £1 and £2 (if the DVLA are operating efficiently).

In the same request I asked the DVLA to explain the QA processes which govern how they ensure the mail service providers (MSP) - UK Mail and Royal Mail - certify that they've collected all the documents produced.

The response on this front have been unclear at best and plain evasive elsewhere. I part of their more recent response the DVLA state:

"Data is input into the DVLA’s systems in accordance with specific parameters,
depending on the type of transaction. This includes a quality assurance check, which allows for work to be appropriately batched ready to send out."

That's a very broad description without any specifics, that doesn't really tell us anything at all. What parameters? What QA check is actually performed? They also stated in the same response:

"When a document is printed, it is then tracked electronically through the mailing system. This supports integrity checks until the document is enveloped and transferred to the Quality Assurance (QA) section. Some items of mail may then require reprinting.

The DVLA then hands over the items for despatch to the respective Mail Service
Provider and is reconciled against control document"

This is more related to the question, and sounds like a proper answer on the face of it. However the portions of sentences I've highlighted should draw attention to the subtle evasion here.

So a document is tracked (per-item?) through the mailing system, so that the QA section can verify it in its envelope. Are they checking every single of the one hundred million items the claim to have sent since Jan 2018?

Finally the point about the "control document" is very vague - is this the DVLA's control document, and one which the MSPs do not interact with? In order words how are the DVLA verifying each letter is accepted by the MSP, instead of just picking up a box or pallet of mail which hopefully includes all the items DVLA has "tracked" to that point?

In fact if we reference a FOIR from 2009, we can see the DVLA admit that the MSP do not verify each item in the batch. I've asked DVLA to clarify a point relating to this as the answer seems a bit more thought out than the one a decade ago. I suspect they have no way of verifying that the MSP is collecting all the items they've printed (so can't entirely blame the postie for lost mail).

You can see the live FOIR here for reference.

Next Steps

Even if my earlier assumptions for calculation were correct (which I know they aren't), the minimum being spent per item is 79p. It's far cheaper for the DVLA to send a prospective fine, on the chase they can intimidate someone into paying than it is to actually review the case properly. It's a cash generation game.

I've largely exhausted options with FOIR as DVLA are likely to essentially ignore further clarifications on the request. Together with their breach of the Data Protection Act (DPA) I'll be putting together a formal document for breaches of FOIA to the regulator, ICO. This complaint will hopefully ensure the DVLA directly answers any outstanding questions.

A grey area has formed between the FOIA and the DPA where automated decision making affecting a living person is at the forefront. GDPR Article 22 deals with ADM - more specifically ensuring that adequate protections are put in place. These protections are aimed at ensuring that an individual suffers no undue harm. In fact Article 22 Section 3 states: "...safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision."

It appears the DVLA has breached this if ADM was at the core of the decision to fine and prosecute me originally. We cannot say that the DVLA has delivered on this requirement by virtue of pressing for prosecution in a case which it later manually determines not to have merit. This is not covered by the FOIA and must be considered by ICO.

In parallel to that I'll be raising complaints with DVLA directly, as was the suggestion of the DVLA prosecutor in the case I won. This complain will focus on recovering damages and distress.

IR35

I can't resist a poke.... the IR35 changes in 2018 will have killed off any IT projects at DVLA reliant on a contingent workforce of consultants. Those same consultants would have been able to build DVLA a digital presence which would remove the need for documents across a conservative estimate of 50% of use cases. A web-based dashboard with services to encapsulate authentication, authorisation and enable notifications to DVLA such as SORN. More and more people have access to the internet via smart-phones, less and less have no access at all - there are still post offices for the rest of the forms.

Eventually other businesses would want to integrate with DVLA data sources, as insurers already do via MID. The motorists data is already held by DVLA in order to support the production of drivers licenses, and therefore the authentication model should focus on driver-based logins. Data security will be key here considering the kinds of information involved. Ideally using MFA such as smartphone authenticator apps should provide a welcome layer of security, and open-source libraries are available to achieve this. The data layer is the most complete layer as it stands today.

Fines, penalties and reminders could all be dealt with in the first instance via the dashboard, with email notifications send to drivers when new 'documents' are sent to them by DVLA. Delivering these digital journeys will need the most engineering & testing effort. The DVLA claims its processes are largely automated so the integration architectures will need to be carefully designed - and probably brought up-to-standard. The DVLA already accepts payments for car tax online if you have a V5C or V11, so existing authentication and payment API's will need to be re-used and expanded upon.

A project of one feature team working on a digital dashboard, authentication model and microservices based on COTS would cost up to £750k for six months. That's a large feature team costing btw, probably one which would operationally be split into two agile teams sharing architect, BA & programme manager. Each team would have it's own scrum master, engineering and QA peeps. Software and licensing for SaaS, for example might stray into the £1m purchase, and £500k annual licence at worst for this kind of thing.

So making some wild assumptions and adding bloat as it's public sector, I did the following in LibreOffice Calc.

Large assumptions ahoy

I made the following assumptions for this:

- I don't know what architecture would be deployed that is compatible with Gov.uk strategy, so upped the IaaS costings for services, services and networks to 75k / year. This increased cost assumes redundancy and performance needed to support the traffic from potentially 90% of motorists in the UK

- I assume the Gov.uk is continuing with vendor-locked arrangements with Oracle, and Oracle are strong-arming Gov.uk as they are with anyone else. Ideally I'd focus on an open-source approach with something like RHEL, Apache, ELK and PostgreSQL, but I don't know how the x-charging works so assumed a DVLA-owned license cost of half a million per annum; plus new costs of authentication and integration of existing Gov.uk payment gateways

- Purchase of cloud and dedicated tin combinations, plus new infrastructure or services hosted for DVLA (assumed re-use from other Gov.uk departments such as MCOL or local government)

- A feature team costing based working over a two-and-a-half year delivery period; including 2 year build and test continual drops, with six months post-live warranty
- These are finger-in-air-estimates for design & development knowing nothing about what really goes on behind the scenes at DVLA

Any of the programme managers I've worked with at my past clients would've fallen off their chairs at those numbers and assumptions, but that's because they work in pragmatic, efficient and competent environments in the private sector.

So based against only a 50% reduction in printed documents - on the assumption that proportion of people register for paperless DVLA services - the DVLA expenditure on disclosed production would be £20,814,822 (ignoring increases with inflationary-associated costs). That's the cost of documents that no longer need to be printed and can be provided direct-to-drive with assured delivery. How many problems does that solve? :)

So the DVLA would save around £20m per annum OpEx, and expend £11m CapEx on rolling out the digital presence? Ok so those savings wouldn't be fully available until year 4. Over the ten year projection that's £145,703,754 cost savings on direct document production alone, versus a £7m run cost estimate over the same period. Still £137m can pay for a lot of tour buses for Boris Johnson.

How to achieve this? Get HMRC on a leash so they no longer exceed their authority under the law and stimulate what's left of the British economy by encouraging the vibrant, consultative small business.

Or keep flushing money down the drain and drive the skilled consultancy workforce out of the UK. You choose.

Netflix

Streaming Wars Episode III

I've figured out a way Netflix can appease the vast number of people using privacy tools such as VPNs, whilst keeping their noses clean with the distribitors they buy content from.

I'm a regular user of VPNs - I have a policy which excludes open traffic on the UK data networks, and even when I'm not using a VPN I'll use some form of secured (and authenticated) DNS. It's not because I would be doing anything unlawful - I'm a law abiding citizen - but the companies that operate our networks are thriving on our meta-data, filtering our content and injecting malvertising into our web pages and mobile apps.

If you own a second home you want to rent - do you furnish it and offer it for free? No. Your renters pay you rent and then pay their own utilities in most cases. Why should that be different for use of our personal data and meta-data? Data is not "property" in the eyes of the law, but consent to use that data can be deemed as much of a commodity as the subscription services we regularly use. Such as Spotify or Netflix.

You don't own your Spotify or Netflix titles, you effectively rent the right to view them. No different to renting the right to use your personal data or meta-data to companies that use it for profit.

Perhaps four years ago I remember being able to use VPNs to access my regular content on Netflix largely without issue. I'd occasionally see a "You're using a proxy or unblocker" error and have to connect to another VPN server or service.

As the years progressed Netflix were largely forced into a more proactive stance by the film distribution companies, in order to ensure that those market (country) distribution rights were being enforced. Distribution companies make their money by selling distribution of their films in each market e.g. country or region, to the highest bidder in that region. If all regions paid the same slice on a pay-per-view they would lose premium essentially.

Netflix then embarked on an aggressive policy of enumerating as many VPN server IPs as possible - I suspect they buy accounts with many VPN services and catalogue any new IPs. They also watch to see if you stream from one IP then another IP in quick succession. Using probability calculations and geo-IP databases it's easy to work out which is the most frequently used home location, and which are the unusual (out-of-region) IPs. Finally I suspect the Netflix desktop and mobile apps look for network connections associated with VPN. For OpenVPN that's relatively easy as the default is a tun0 adapter. IKE v2 is a little more complex but just as detectable. If your VPN solution DNS leaks, or the DNS servers you're using are known VPN-provider DNS, I'm sure that is factored into the detection algorithm.

You may remember that Netflix then started investing heavily in paying for it's own content to become it's own production and distribution organisation. When pressed for answers about why Netflix continues to block VPN access back to your own country when abroad, or blocks VPN access on hostile networks; you will reach a wall of silence. In one of the help.netflix.com pages it does describe some of the complexities of the distribution (inc. streaming) agreements, which explains some of the inconsistencies for "Netflix Originals".

Basically Netflix has partially adopted the broken distribution rights model, in selling streaming rights to it's own content to other streaming providers. So in some countries you won't be able to see Netflix Originals on Netflix, perhaps you might on Sky or Apple TV.

For me this isn't an answer to the question: "why are you blocking subscribers using privacy tools such as VPN?"

I think there's a simple solution, and one that will help Netflix get an upper hand in the recently started Streaming Wars.

The Solution

When you sign up for an account, you provide a handful of details. The level of information is good for privacy advocates because it isn't burdensome, nor does it require irrelevant information.

You need a username (email), password and payment card. The card can be either a credit or a debit card, and must be authorised with the provider before use.

So if I were to operate the billing department I would then know the following:
- The domain name of the email address, and which country it's registered
- The country of origin of the payment card and it's provider name

Netflix store the card PAN, expiry date and CVV too. From the PAN I can identify the provider and country before I hash and store. I could probably ask the payment gateway API to provide me that information without me having to do it myself - that way I would reduce my compliance requirements for PCI-DSS.

Therefore... I know which country the billing account is based in. Why not associate the account with a home region (my country)? That way if I detect the user to be using a VPN I can restrict the available content to Netflix Originals which Netflix have rights to stream everywhere, and perhaps Originals content Netflix have rights to stream in my home region.

I could still view content from outside my home region if, for example, I was on hols in Spain and using Netflix without a privacy tool (c.f. proxy / VPN). I would be watching the Spanish Netflix library.

Although this dramatically reduces the amount of content I can view whilst using privacy tools, it means everyone is playing by the rules.

We can then also accept the added bonus that people in other countries can't take advantage of geo-unblocking capabilities to view content which breaches the distribution / streaming contracts.

Surely that's a win-win for everyone?

DVLA

A Bit of History

After almost a year of DVLA-driven (ha ha!) nonsense, it's now safe to discuss in the open.

Last year my employer adjusted it's approach to national travel, and essentially allowed me to use rentals to cover the lengthy journeys to / from client site. At that point we were working with a client in Norwich, which isn't very easy to get to on public transport - it was far easier to commute once a week by road.

Everyone's a winner - I get a nice new-ish car every week I'm supposed to be on site, and hand it back when I get back to the Midlands. I don't have to pay for wear and tear on my own car, and it's very slightly cheaper for the company.

So I had my own car sitting on the drive almost entirely unused for a couple of months in the lead up to xmas - what's the point of paying tax and insurance on a vehicle I literally don't use? None. So the obvious route is to SORN the vehicle and let my insurance policy lapse at the end of the year. Of course because the DVLA are involved nothing is that simple - when we moved house a few years ago they failed to send me the new V5C, and only occasionally send me V11s... 2018 was a no-V11 year as it turns out.

What does that mean? Well I can't use the limited digital facilities provided by the DVLA to register the SORN, and - using their own instructions - get a V890 hard copy ready to send. Simply paying for tax requires all sorts of documents, which prevents Samaritans simply paying random vehicle tax (which would happen all the time of course), but SORN is equally baffling. Why not use the license ID of the registered driver? The DVLA have this information too.

From the DVLA website

Of course being a paperless business we've no printers so I have to get to [Insert High Street Stationary Brand] and get the forms printed. Already cost me a quid because the DVLA can't deliver documents properly!

We were off on a holiday to see family in Australia for most of December and some of Jan, so I wrote a letter to accompany the V890 and we dropped the envelope in the postbox on the way to the airport. Of course not being familiar with the process I was expecting no further paperwork

And So It Begins

We had a great time catching up with family in Oz, and returned refreshed (but shivering) back to the UK in early Jan. Back to work, off to client site and so on. Until about the 15th of Jan, when by some miracle a DVLA letter arrived. I was vexed and perplexed, however, that they were claiming my insurance had lapsed and they hadn't gotten their cut.

I just assumed that my original V890 & letter were probably being used to mop up a coffee spill on someones desk in the Enforcement department, and sent a duplicate V890 and letter back to them, carefully stating that I'd already sent one on the 14th of December.

It all went quiet.

Too quiet. Watched too many films to not know that was perfect time for an ambush. January flies past, as does February.

Then at the beginning of March I get another envelope from the DVLA, which contained a nice little SORN acknowledgement slip; I didn't think much of it at the time but the SORN effective date was 14th December 2018, but the printed date on the slip was 8th March 2019. I simply assumed that some paperwork took them a while.

Of course by the time the unexpected SORN acknowledgement had arrived, I was considering selling the car due to it's lack of use. No further carrier pigeons arrived from Swansea and I eventually sold the vehicle a few months later in August. The new keeper got their V5C - I wasn't bitter about not getting mine over the last few years - and the transaction was complete.

The Back Swing

It was never going to be that simple, was it? I'd returned from a trip to London on Friday 13th September at around lunchtime, to find David Wills stood leaning against his white van on our driveway.

"Are you the owner?" he asks.

"Who are you?" I ask.

He keeps asking if I'm the owner and I keep asking who he is - all of a sudden I'm thinking of the time I worked at a debt management business for some reason. I smile and suggest he introduce himself, which he then does. We shake hands and start talking.

It turns out he represents Marstons and is here to collect on a debt. We have a professional and calm conversation - he allows me to take photos of the information he has on his tablet and but has no paperwork to show me. Turns out I'd been convicted of a motoring offence in March or May and a fine had been levied.
 
A little advice for you if you find yourself in this situation - if you're 100% certain there's a mistake, you've not received any of the paperwork yet and you'll be getting a refund back, pay the bailiff and explain you'll be having the conviction set aside. They will have to refund the entire amount and it's dealt with there and then.

If you're not 100% confident and you haven't received any of the notices in the post, ask to see the warrant. If the bailiff can't produce the warrant, ask for the phone number for head office and speak to someone there. Don't open the door or get your keys out. If at all possible walk away and don't return to your door for another few hours.

If they don't have a warrant to seize goods on them (which they usually don't until after the first visit is unsuccessful), or won't prove it you shouldn't let them in. However if you've ignored any notices it's already too late.

I was furious at potentially having a serious issue getting my security checks failed and (if this matter had gone to a county court for recovery) potentially failing a credit check too. My SIA license might get cancelled or blocked from renewal. This would be disastrous for employment as no client would allow me on site. It wasn't David's fault, he's just the guy in the van today.

I also knew with absolute confidence that there had been a breach of proceedings and that I would be able to get the conviction set aside somehow. More on that later. I got home about £660 lighter then started prepping and researching.

More worrying to me was that I couldn't tender any new bids for work for my company out of fear that the BPSS / CBR / CC checks would fail. That would fail the bid instantly, and likely ruin any potential future relationship with parties involved, which could be disastrous for my business.

Fighting Back

After stewing and ranting over the weekend I got my extra strong coffee from the top shelf Monday morning, and set to work.

First up was a call to Marstons head office - partly to put them on notice not to spend that cash, and partly to see what information they could provide. They talked me through the details they had - an original balance (fines) of £350, their fees of £310; a sentencing on 13th May 2019 and on 29th of August Marstons allegedly sent me a notice of enforcement.

What's chilling here is that I can live without the car tax rebate check arriving and I expect physical post to be largely unreliable; but I don't expect to lose so much critical post. I honestly don't believe it's the postie as there's huge organisation behind him with many faults. On the flip-side of that I also realise that with the details Marstons had been provided by DVLA, they could have found more reliable contact details within sixty seconds on a web search. My name is unusual and unique so there's an extremely high probability a PM on Twitter is reaching the right person. e.g "Are you [my full name]? If you are could you call us please so we can verify who you are and talk about a serious situation."

It's also interesting that I suspect the collection agents were originally going to probably look to seize the vehicle as payment, but when I sold it at the beginning of August unaware of all the events that had happened, that loophole was closed. I wonder if that precipitated the doorstep visit?

Regardless I got the details of Hereford magistrates court and tried a call to them and "HMCTS". Hereford clerks first tried to pass me to the county courts, which just isn't appropriate in a criminal case. Then I asked them about HMCTS and they didn't know what I meant. Some google-fu later and I'm speaking to HMCTS. In Birmingham.

A real legal tour of the region.

The clerks there were pretty patient, probably happy to speak to someone who wasn't in tears or swearing I suspect, and helped me file for a statuatory declaration (SD). The SD is the medium by which a conviction and and following actions are unwound. If you've simply ignored the situation I'm afraid this isn't going to do you any good - it's designed for those scenarios where communication has broken down and service has not been delivered.

The last thing I had time for on the Monday was to venture into more familiar territory; raise a SAR and a FOIR. The SAR was simply to get the DVLA to send - in electronic format to avoid delivery "issues" - all events, documents and details associated with myself and the VRN (whilst I was the registered keeper of course) from November 1st 2018 onwards. Key bit of information we'll come back to that data point.

The original FOIR gave me an opportunity to ask the DVLA how many items are produced and "sent" to registered keepers over a given time frame (since Jan 2018); how many are tracked and how many go missing. Around 0.03% of all items appear to be tracked and they simply don't keep records of how many of the tracked items are returned as "undeliverable". The request isn't yet complete and I've asked for clarification after the authority dodged some questions e.g. what QA is done to ensure the produced documents are all collected by the mail service provider (MSP), and where in the overall process are the most documents lost.

DVLA have committed to some form of response by the 25th of November, and you can see the request in full here.

Back to my week of investigation w/c 16th September; and over the next couple of days I'd spoken to HMCTS in Brum, and had managed to get an SD hearing in for the 27th of September. I was still livid at the DVLA.

I also thought about the follow-on activities of the SD, which I intended to plead "not guilty" and have to mount a defence. I couldn't find much through the usual research channels other than to some cases reported in the press, where the DVLA had lost during the application of common sense by the courts. Not sure they're precedents at that level and the DVLA didn't appeal so they're anecdotal at best. However to me it highlighted that similar situations were happening in 2010 as are today. One of the cases involves someone else using FOIR to forcibly extract the facts from the DVLA too.

Most interesting to me out of all of these is a FOIR made by James Collins in 2009, for almost exactly the same set of circumstances as I've seen. In fact the DVLA appear to have even lost items sent by recorded delivery - after they've been signed for by DVLA. I was impressed that Mr Collins had held DVLA to account but also amazed that the net result showed the DVLA were unable to ensure produced documents get delivered - and that received documents are processed outside of relevant QA processes. For me this was key to the whole problem.

In his case, Mr Collins was found not guilty with the court agreeing that he had fulfilled his obligations; that the DVLA has no statutory powers to compel drivers to chase paperwork sent in. It is firmly the DVLAs responsibility to apply common sense rather than prosecute. Even in 2009 there were calls for the DVLA to become transparent and provide an independent appeal system.

Clearly nothing has changed a decade later. At this point I'm beginning to see the scale of the problem and create a second FOIR focusing on how much the DVLA spends on all its postage and stationary. I wanted to understand how much of the DVLA budget is spent on sending and receiving (processing inbound) documents in order to balance the initial assessment on their document processing errors.

I asked the DVLA to provide their budget for the previous and current financial periods; as well as a breakdown of items such as envelopes and document printing relating to registered keepers. On the 25th of October, the DVLA belatedly respond attempting to claim the information was too difficult to acquire. I call cow poo.

I know that if I'm defining costs or doing programme budget projections for my clients and need some stats from their finance teams, I can get almost all details whilst I wait over the phone. I challenged the DVLA to reconsider their response with an internal review and you can see the latest on this one here.

The Defence

So a couple of months on in November and progress has been made. The Birmingham Magistrate agreed my SD, entered my "not guilty" plea and had the previous conviction and fines set aside. The moment I explained that I'd sent the V890 in twice and even had a back-dated acknowledgement the atmosphere in the courtroom changed. Immediately the intention was to set up a case management hearing, rather than go straight to the trial hearing. The magistrate was even kind enough to delay this CM until after the dates the DVLA claimed it would respond to my SAR and FOIRs.

The DVLA eventually responded to my SAR using a secure email system - quite why they don't use this for more use cases including replacing postal SORN's is mind-blowing. Of most interesting to me was that whilst they provided the copies of the documents specifically associated with the case (and nothing else), they provided the timeline as a reference.

This in itself is damning. They acknowledge receiving my duplicate SORN on 21st January 2019. The next date is the 1st of March... where they note that the V890 was ..."resent to Vehicle Input [sic] as they may not have been sent as previously stated.". Quoi???

Hang on so they received my second V890 and admit it took them nearly six weeks to pass it from the Enforcement department to their own VI department to update the record? Hmmm. More interesting is that, a week later when VI actually process the V890, this update is either not noted by the Enforcement department in charge of working with DVLA prosecutors, or automated decision making (ADM) is at play. 

Bear in mind that there are provisions of data protection law which require safeguards in ADM for example GDPR Article 22 section 4 generally, and DPA 2019 Part 2 section 14(2) relating to "significant decisions".

Therefore either the DVLA have failed to deliver an ADM solution with safeguards it is required to by law, or the staff of it's enforcement division are trained to focus on fines and revenue rather than the application of common sense. DPA-breaching systems or inadequate staff?

According to the timeline, the DVLA prosecutor then appears to continue with prosecution in my case, as I hadn't paid a fine I had no idea at the time was allegedly due. For an infringement the DVLA had already acknowledged did not exist by pre-dating my SORN to 14th December 2018.

My defence centred around the fact that I am not obliged to chase the DVLA, nor do they have any statutory power to compel me to possess a valid V5C (as long as the registered keepers details are up-to-date) - for which they charge £25 for replacements. Which they lost to start with. I even sent them a request for a new one with cheque a couple of years ago. Cheque wasn't cashed and I didn't receive a new V5C either. So the only route left open to me was the postal route I'd used. Their direction, not mine.

The evidence provided by the DVLA themselves paints a picture of a disorganised and unreliable document processing approach, which is far from fit for purpose.

I also focused on the fact that the prosecution could not say with any certainty that the warnings, notices & service documents had actually been sent - nor could they or their MSP's prove that they had.

To the contrary - the DVLA appeared to employ bullying tactics with the sole aim of increasing revenue, rather than applying a pragmatic approach which allows an independant review & challenge process - without utilising debt collectors and the courts. I collated a 23 page document of skeleton arguments and evidence, which contained numerous admissions by the DVLA that they simply had no idea how many documents were either received by their recipients; or processed correctly once received in Swansea.

Therefore the prosecution had failed to adequately notify or serve single justice forms, after losing my original SORN and attempted to criminalise me for their mistake.

After review from a legal professional, the situation looked extremely promising for my plea of not guilty to succeed. I expected to be in a position to ask the court to make a costs order in my favour if I won. I also expected that if I lost arguing my own case, I would request leave to appeal on the grounds that there was such a substantial amount of documentation to support the case that I would need a proper lawyer to organise and represent it properly (essentially the appeal would rely on evidence not seen previously thusly new evidence). Cases on appeal can unlock awards for legal fees amongst other things, which can be a useful weapon to wield.

Outcomes & Reflections

Ultimately I never got the chance to have my day in court.

I'm not sure if word had reached the prosecutors office of the FOIRs and SAR, or they could just plainly see that the Enforcement department had tied themselves in knots. They withdrew the charge - although the Birmingham Magistrate said I "must attend" the case management hearing in Redditch, and I wasn't about to start trusting the DVLA when they claimed I "did not need to attend".

So I turned up on 4th November 2019, and the usher let me know the case had been discontinued. I was able, however, to speak to the DVLA prosecutor John [Dursely / Dyson? - Apologies I didn't take note of your name]. He brought his laptop in and confirmed some of the details, explaining that a colleague had reviewed the case after the SD was cleared and decided that the "pragmatic approach" - seeing that I had submitted the SORN after all - was to withdraw the charge. When the prosecutor attempted to show me that they'd sent warnings in December 2018, it occurred to me that the SAR response had omitted a lot of events, documents and data. It took the prosecutor all of a few seconds to find this information whilst we were talking.

I only got a brief look at his screen but it appeared to be either an Oracle Forms or VB application judging by the button implementation and layout.

I didn't say much in the room at the time but I suspect they realised I wasn't going to drop it, and show that they were just as culpable as they had been ten years ago in a public courtroom. Perhaps Mr. Collins' case has stuck in their memory. Better to spend their time on a case where actual criminality may have occurred.

HMCTS sent me cheques for the refunded fines and fees; I sent Martsons an invoice for the rest which they transferred back to me in relative short order. However I spent just under five man-days working on the investigation, putting together my own defence; around an entire working day traveling to-and-from various hearings; around £60 on printing my legal documents for the hearings and so forth. I haven't received a rebate on prorata-ed car tax from December 2018 nor August 2019 from the DVLA.

In all likelihood I'll  raise a complaint and offer the DVLA the opportunity to compensate me for damages and distress caused; I'll have to think about the potential loss of earnings. I wonder how many of the tens (hundreds?) of contract notification emails I'd watched throughout September, unable to apply a bid and the resulting potential loss of revenue.

I'm also still waiting for the rest of the information I asked for in my SAR. Two chasers and no further response. So that's one refused FOIR (assuming DVLA refuse to revisit), one failed SAR and a questionable data practice to discuss with ICO in coming weeks too. I've won the case but I'm not going to drop the data protection issues.

The DVLA are always so forthright with us motorists yet seem unable to discharge their responsibilities under the law. I get the distinct impression that had I not fought it I would have been fined for no reason.

I'm not sure how much they spend on filing fees for cases they don't win, possibly something for a FOIR on another day, but this appears to be a massive overspend of taxpayers money. Why not have an independent arbitration panel that gives motorists a fixed period to challenge a fine? If prosecution is the result the date of the offence won't change. Mind you, it won't make a difference if you don't ensure the documents are delivered. Why aren't they storing the email we give them for notification of successful payment of tax, for use with warnings and similar?

The DVLA really do not have any legal power to compel you to chase them - once you've fulfilled your responsibilities properly everything that follows is their own doing. I'm not suggesting you take any chances but certainly don't let their bullying tactics over fines sway you, their inbound call centre is apparently only there for payments and collections. Not SORNs ironically.

Challenge them all where challenge is due. Although if you've genuinely just messed up then I'm afraid that's on you!

Working in digital and IT industries, I'm also amazed that the DVLA hasn't provided a more efficient and sustainable approach to document management. Some things you literally cannot do online or in the post office.

Perhaps this is a good time to note that the disastrous IR35 Intermediaries legislation decimated the pools of project-based consultants in public sector organisations; which may explain why their IT hasn't moved on much in years.

iProfile / Vertifi / Jobzooma at it **AGAIN**??? (Updated)

Updated 23rd November 2019; Originally posted 30th September 2019

Amazingly the Jobzooma team are still at it.

After tendering some applications for contracts earlier today I had an email from our old friends Jobzooma. I can find no trace of any connection between the potential clients I emailed or how they acquired my details, yet somehow I've sent them my CV???

Yeh but no

This isn't how to deal with consent - there's no opt-in, there's no request about whether I've asked for it. The email asks you to click a link to verify that they have the right data, which I'm absolutely not going to click. That could be interpreted as explicit consent for them to continue storing my data - I've never done any business with them!

Have sent chaser email but be warned - they're still at it. If you read the previously linked scam alert you'll realise why you're better off avoiding altogether.

I've asked them where and how they got the alleged CV and they've acknowledged receipt of the request. Will update when I have more but on the face of it appears to breach PECR and DPA 2018 [inc. GDPR 2018].

It's no good asking for consent after you've already acquired, stored and processed the data.

Updates

I finally received a response from ICO, in which they stated that:

"We have considered the information available in relation to this complaint and we are of the view that Jobzooma has not complied with their Data Protection obligations. This is because you did not receive an appropriate response to the data protection concerns you raised. We consider this to be an infringement of the legislation.

Subsequently, we have written to Jobzooma, via the Data Protection Officer, to explain that we expect the organisation to review your complaint and take action to resolve any outstanding matters.

We have issued guidance to Jobzooma as a result of your complaint and expect they will be in contact with you in due course. Thank you for bringing your concerns to our attention.

This complaint will be kept on file and this will help us over time to build a picture of Jobzooma’s information rights practices.  We keep a record of all the complaints raised with us about the way organisations process personal information.  The information we gather from complaints may form the basis for action in the future where appropriate."

I wasn't happy with this response because it isn't a strong enough message for a repeat offender, and also I've recieved no responses from Jobzooma at all. I asked the case officer to look into further evidence I provided, and examine the linkages evidenced between Vertifi, Talent Spa and Jobzooma.

I asked the case officer to then review the outcome and proceed with a publishable decision, so that Jobzooma would be the target of ICO enforcement should they offend again.

That reply to the ICO case officer was sent on 4th November 2019, and I have not yet received a response, other than the auto-acknowledgement.

However it is good to see ICO confirming my suspicions that Jobzooma are / were acting unlawfully.

I've noted further updates in November 2019 on the scam alert post on the portal.

How to Mitigate the Firefox DNS-over-HTTPS Implementation

Background

I was reading El Reg this morning whilst having some brekko and spotted an interesting article relating to DNS-over-HTTPS (DoH). It seemed to me that the approach taken by Mozilla is a double-edged sword of worrying proportions.

You can TL;DR to the Solution section at the bottom if you're already tired of hearing about the topic :)

On one hand I commend them for taking these steps to further ensure the privacy of the individual - DNS itself was designed in a time where data scraping, intel and spying were not immediate concerns of the internet (as was), but a way of translating machine-speak (IP addresses) into human-speak (domain names for URIs) was. It was critical to the newly born world wide web at the time and the emphasis was performance and simplicity.

Wind the clocks forward to the current climate some twenty plus years later and we now have our own ISPs hoarding our DNS requests, in order to augment their data pipeline to sell to advertisers. Of course there are many more data points the ISPs collect but this is the key focus on this issue. They'll also redirect you based on whose paid them the most that month, to sites selling wares or other paid-for content.

Now for the majority of people, Mozilla's approach here will drastically improve privacy  with respect to the ISP data collection and censorship. We need this type of approach to drive a change in behaviour within the advertising and data analytics industry.

Mozilla will do this by embedding a DoH client within their Firefox browser, and - apparently although I may have misunderstood - will enable this by default. There is the capability to opt-out and I'm sure the about:config page will inevitably allow a tweak in settings. Their chosen DNS provider is not OpenNIC or similar but Cloudflare, and whilst Cloudflare have pinky-sworn that they'll uphold good and only use the additional DNS data flow to support their resolver services, we should throw caution into the wind.

As I said, for the majority of people with simple connectivity needs who like seeing ads, and are happy being click-jacked to hostile domains this Firefox change will probably slightly improve their privacy. Especially in the US where ISP's openly sell customer data this closes off an entire pipeline for analytics.

An increasing number of people and businesses are running PiHole or similar LAN DNS configurations to exclude malvertising from all their devices on the entire network. The change being enacted by Mozilla has the potential to completely circumvent this anti-ad safe-space capability. "Free" DNS providers offering ad and parental filtering are no strangers to paid relationships with malvertising organisations so custom DNS configurations are really the only solid solution.

Of course DoT and DoH were designed to stop ISPs and other bad-actors doing exactly what PiHole is designed to do - which is why there's such a double edged sword here.

Now add in standard enterprise networks - how will this impact local (enterprise) resolved names for servers and services that are not exposed internally? Well future Firefox users will likely not be able to access these services without some serious per-device configuration by admins, and an additional group policy to disable user configuration to opt-in. The way Mozilla expects a canary domain workaround to operate, which will signal that DoH is not available / appropriate...although it can be overridden in a user-configured setting on the browser.

Some mobile apps embed DNS resolver clients to maliciously use their own HQ DNS, which is why it's often so difficult to block 'invisible' services such as Facebook APIs. We want to bring this back under control too.

Solution 

I've been operating a network design for some time now which takes a caching domain name forwarder, various network security tools, custom scripts to acquire and parse ad-filtered domain rules, firewall rules (shorewall or iptables work) and some denting-of-desks-with head. But it works.

It also means that Firefox's new DoH implementation will work in my favour when I'm on the road - so it's a double bonus.

The aim is not to censor or inhibit but to remove malvertising and ensure no ISP-induced censorship is possible. In all likelihood this is exactly the type of approach your ISP will be using but for their own aims. As a side effect it also eliminates a large portion of tracking without acting like an overly protective parent. You could potentially modify your PiHole & router configuration to adopt this approach too - although I'm unable to test that statement.

During the development of this approach I also did a little research and decided I wasn't happy using Google DNS, Cloudflare, ISPs (e.g. BT / EE, Vodafone or Three) and anything to do with Facebook. So not only did I want the resolver to filter out malvertising but also ensure that no devices or apps were embedding DNSCrypt et al and ignoring this filter list.

What I've not got a full solution for yet is regularly updating what I'm calling the "hostile DNS" list e.g. FB and Google. On with the details.

Ingredients

Components of the solution:

1. Unbound - caching domain forwarding resolver. Good bit of kit and low imprint mem / cpu
2. iptables - rules configured on the routers of your network, ideally in the inner router if you have multiple
3. script to download malvertising domain lists regularly, and parse these into unbound format (example script available here)
4. a list of hostile DNS domain names. For this example I've used:
1. onedotonedotonedotone.cloudflare-dns.com
2. dns.google
3. resolver1-fs.opendns.com
4. resolver2-fs.opendns.com
5. a list of hostile DNS ip addresses. Explanation of why the IPs and DN follows this list
6. A script to resolve the domain names from #4 into a list of IPs on a regular basis, to account for the IP changes (template to work from is available here)
7. (Optional) A VPN. Doesn't matter what else you do the ideal is to ensure that your ISP cannot track the connection to the DoT server in the first place. Whether or not this is necessary is debatable though.

I'm not going to go into detail about how to deploy and configure Unbound with DoT (properly) and DNSSEC, but that's what my baseline is in this example. Plenty of guides elsewhere on the web.

This post is going to focus on the acquisition of hostile DNS domains and IPs, plus the redirection of DNS traffic back to our known (friendly) DNS or resolver.

The basic tech-stack and process involved in delivering regular DNS management

Firewall Rules

In order to make this work we need to bring together a list of IPs that we consider hostile, the IP of our friendly LAN DNS which we've got up-and-running and a sprinkling of knowledge of firewall rule management.

What we're essentially going to do is redirect all traffic on DNS, sDNS and some (known) custom DNS ports back to our friendly DNS server. The DoT - and perhaps DoH - will not be able to authenticate and likely fail for port 853 requests, but embedded DNS in apps always has a downgrade or alternative. DoT & DoH authenticate the endpoint to ensure they're speaking to the DNS they're expecting to. If the hash or certificate does not match it assumes MitM and should return a SERVFAIL - I've seen some clients get NXDOMAIN in some cases, which I don't believe to be appropriate.

I've noticed one - the TSB banking app on Android - doesn't like this at all. But as the app is so s**t to begin with I tend to use the website on my mobile anyway. When I get time I'll take that apart with an EvilTwin on ParrotSec.

Anyway, we want to plug in some firewall rules and the first one is simple; we want to re-route all traffic on our DNS port(s) that isn't originating from our LAN DNS server back to our LAN DNS server. Confused? Here is some crayon work explaining it.

So flow #1 is the original DNS request from the client; the firewall rules on the router determine this to be a DNS request (e.g. plain UDP, TCP, DoT or DoH) and redirect it to the LAN DNS in flow #2; flow #3 is the logical response back to the router - but with the mangle in the firewall rules it'll appear to the client that the response is returned from the IP it requested, the LAN DNS will actually respond.

Breaking it into two parts then, the iptables rules that sort out flows 1 & 2 (one each for tcp and udp):

iptables -t nat -A PREROUTING ! -s LANDNSIP -p tcp --dport 53 -j DNAT --to LANDNSIP:53

iptables -t nat -A PREROUTING ! -s LANDNSIP -p udp --dport 53 -j DNAT --to LANDNSIP:53

And the critical bit following that is to masquerade the response back (again one each for tcp and udp):

iptables -t nat -I POSTROUTING ! -s LANDNSIP -p tcp --dport 53 -d LANDNSIP -j MASQUERADE

iptables -t nat -I POSTROUTING ! -s LANDNSIP -p udp --dport 53 -d LANDNSIP -j MASQUERADE

The above will deal with all plain DNS traffic, and can easily be broken out into a for loop in a shell script - most OpenWrt routers have a firewall script in their admin section, so it's easy to apply to home and SME routers. I decided to block a number of ports I'd tracked for DNS so ended up with the following:

for port in $dnsPorts; do

    iptables -t nat -A PREROUTING ! -s $targetLanDns -p tcp --dport $port -j DNAT --to $targetLanDns:$port    

    iptables -t nat -A PREROUTING ! -s $targetLanDns -p udp --dport $port -j DNAT --to $targetLanDns:$port

    iptables -t nat -I POSTROUTING ! -s $targetLanDns -p tcp --dport $port -d $targetLanDns -j MASQUERADE

    iptables -t nat -I POSTROUTING ! -s $targetLanDns -p udp --dport $port -d $targetLanDns -j MASQUERADE

done

For reference, those DNS ports are currently: 53, 5353, 853 (tcp only), 41895 (tcp only perhaps).

You'll end up with firewall tables full of:

DNAT  udp  -- !LANDNSIP  anywhere   udp dpt:853 to:LANDNSIP:853

and

MASQUERADE  tcp  -- !LANDNSIP       LANDNSIP      tcp dpt:853

We also need to ensure that if hostile DNS services have thought of this approach and decide to use custom ports, we block that route too - by redirecting all traffic to those servers to our LAN DNS port 53 (udp) or 853 (tcp).

Exactly the same type of approach as above but without the port filter, e.g.

## Known bad-actor DoT servers which may be embedded within mobile apps etc, should be redirected too for specific sDNS port
# Need a CA-backed TLS cert to do this properly
for dnsAddress in $dnsOverTlsServers; do
    iptables -t nat -A PREROUTING ! -s $targetLanDns -p tcp -d $dnsAddress -j DNAT --to $targetLanDns:853
    iptables -t nat -I POSTROUTING ! -s $targetLanDns -p tcp -d $targetLanDns -j MASQUERADE
done

Cron Jobs

Forgive the non-Windows parlance but this is job scheduling that can just as easily be done on your scheduled tasks cmdlets and Powershell (and just as well).

So I tend to have a daily reboot policy on routers in most environments in case mem. resident compromises have actually been effected unnoticed, with more frequent reboots on grids in more secure environments - make sure you plan your malvertising list fetches and hostile DNS resolver updates to avoid any high utilisation or downtime.

The latter script - which updates the IPs which are associated with the hostile DNS - doesn't need to be run daily as the IPs may only change once a week. Perhaps on a Friday morning or afternoon would be best before those providers clock-off for the weekend. No-one does releases on Friday, right? :)

Conclusion

So the above has been mostly operational here for almost six months. I enhanced it with some firewall rules back in May this year and I'm now looking at Android and iOS apps which people have reported "misbehaving". Suspect that's DNS related - either directly because private DNS cannot be accessed or the developers tied service calls and web applications into advertising scripts & libraries. Will take a look in more detail when I get time.

In other words, the secured domain name resolution and caching is worked as expected :) 

Insecure Security at the DMA

It's been a while since I've had a chance to write up anything, having been so busy with consultancy work over the last few years.

A number of people have asked what steps I'd take to keep your phone numbers off spam call lists and the answer is simple - don't give it out in the first place! However that's not really a practical approach is it?

Having had to go through the pain of successfully chasing spammers and cold-callers in the courts over the last half a decade (because the regulators for advertising and data protection weren't willing to lift a finger), I've devised more manageable approaches.

More likely what will work is burner numbers from platforms like Hushed, which allow you to create a number (at a price) for a set period of time. I find this really useful for CVs (resumes & business profile documents for tender submissions) with companies I've not worked with before or jobsites I know not to trust; and also email signatures at client site.

Often the level of information security requires that I do not move client information off their own systems necessitating an email address on their platforms - they also usually prefer a signature so I supply my own company details and a VoiP / burner number.

Once I've finished the client visit or project there's no need to get in touch so the number is removed. Same thing with tender documents and resumes - once I have enough clients I close down the entry on the jobsites or notify the companies that those tender documents are out-of-date.

Of course with your own phone number it's a bit different so wherever possible use the Telephone Preference Service. It's a Direct Marketing Association-led initiative to help it's members adhere to PECR and the Data Protection Act. However that's not really true as PECR states that no-one can send you unsolicited messages (section 22) or cold call you (section 21) without your prior consent or purchase of goods. The Data Protection Act states that your data cannot be stored, processed or used without your prior consent either - which means that the DMAs explanation of the TPS mechanism dodges the issue at heart - where did they get your data and what makes them think you want to speak to them in the first place?

You see, if a spammer or cold-call centre had asked you for your permission to acquire (c.f. buy leads database) your data first and you'd said "no", the TPS list would be unnecessary.

The concept of TPS then must focus on the scenario where you've engaged with, for example, a company to buy their products but never specifically stated that they may use your details for marketing purposes. If, in this example, the sale does not complete you should always state that the company may not re-use your personal data for any reason. If they were happy to store your data received verbally they must also accept the notice to destroy that data verbally.

This stops the issue at point although if they later spam call you, you'll need proof of that original conversation - email or support tickets are usually easiest.

Once you're on the TPS lists DMA-linked organisations must make it their priority to ensure that they regularly update the copy of the TPS phone numbers lists they keep - this should ensure that you don't get cold-calls from UK-based or UK-operating organisations.

Every year they'll send you a reminder email to renew your TPS registration - which is ridiculous. If you haven't spoken to a company for over a year why would you suddenly want to start getting cold calls and spam again? It's bad enough we're playing cat-and-mouse with the malvertising platforms that we shouldn't have to deal with the direct approaches too.

This years re-registration was a little more worrying - the email I'd received not only explained why and what... but included the username and password I'd need to log-in and verify re-registration. As an aside this is terrible practise - instead of account details I could register with initially and tidy away into a nice, secure password manager - they're not mentioning any account creation and sending me a username-password combo in a plain-text email! Added to that is the fact that the password is entirely numeric and less than ten characters. It'd take one of my Raspberry Pi's & John The Ripper the grand total of about 30 seconds to brute force that (assuming a hash had been acquired).

Looks like a Perl-based form submission - I hope it's appropriately secured but I'm not going to even think about taking a look without prior engagement with their SOC.

The domain they're using for renewals is "secure.dma.org.uk". Normally I'll use Tor for the unsubscribe / renew links I get to minimise the intrusion - although each link will have an embedded tracking mechanism Tor will prevent OS, screen res, lists of plugins etc. being available for scraping and trend analysis. There's no lawful reason to exclude Tor traffic for a service notification / required intervention.

Before I make the next statement I want to stress that this may be a Tor-specific issue and not necessarily related to the DMA at all, as the CA verification works fine in Firefox: The URL immediately gave me a "Unsecure [sic] site warning" and on closer inspection showed a self-signed certificate with issuer "Digicert Global CA G2". Bit odd. That's usually the middle cert in the chain back to the Digicert Global Root. The self-signed bit is what usually causes that red padlock in the browser address bar if you weren't aware already.

Not sure why but Tor seemed to have missed out the CA repository, but if I didn't know any better this would also look like a MitM attack.

I sparked up Firefox and used the same URL - all fine. Verified CA-issued cert matching the domain and domain name resolved via DoT + DNSSEC. And no, we don't use Google DNS or similar.

Ok, ok so perhaps a bit of click-baiting in the headline but quite a good example of what to look out for. I think it looks like there's some Tor exit nodes which are being proxied / filtered so I tried generating a new Tor circuit and then changing bridges but this didn't change the issue.

The DMA domains are not on the Tor blocking lists and other domains seems to be fine.

Regardless I'm not going to put any personal data into a web page that for some reason arouses suspicions. I used a different browser and checked the domain ownership vs. historic TPS emails and all seemed to check out.

TPS registration renewed via Firefox instead - perhaps one day the DMA will get their acts together and make this a permanent opt-in (on the basis of opt-in-by-default at their member organisations) with TPS as an elective opt-in for categories of products and services you want to hear about. This would even work well for consumers buying a new / previously used number.

I'm sure we'd all race to sign up for cold calls and spam emails after all :)